Banklar və Maliyyə

Bankçılıqda Real Vaxt Fraud Skorlaması: Gecikmə Büdcəsi və Memarlıq

Kart əməliyyatı təsdiqlənmədən əvvəl fraud skoru 100 millisaniyədə qayıtmalıdır. Bu büdcənin necə xərcləndiyini və memarlığın necə qurulduğunu izah edirik.

BIART Ekibi3 dəq oxu3 baxış
Gerçek zamanlı fraud skorlama mimarisi görseli

POS terminalında kart keçəndə müştəri ən çox bir-iki saniyə gözləyir. Bu müddət ərzində əməliyyat şəbəkə, kart sxemi, core banking və fraud nəzarəti daxil onlarla addımdan keçir. Fraud skorlama servisinə düşən büdcə adətən 100 millisaniyədən azdır. Bu yazı həmin 100 ms-in necə xərcləndiyini və memarlığın necə qurulduğunu ələ alır.

Gecikmə büdcəsi

Real vaxt fraud skorlamada tipik büdcə bölgüsü:

  • Şəbəkə + deserialize: 10 ms
  • Feature lookup (feature store): 20-30 ms
  • Model inference: 20-40 ms
  • Qayda mühərriki + qərar: 10 ms
  • Logging + cavab: 10 ms

Hədəf ~80 ms; p99-da 100 ms aşılmamalıdır. Büdcə aşımı əməliyyatın sinxron rəddi əvəzinə asinxron izləməyə düşməsinə səbəb olur — bu da fraud tutma nisbətini azaldır.

İki qatlı qərar: qayda + model

Yetkin fraud sistemi tək başına ML deyil:

  1. Qayda mühərriki (determinist): qara siyahı, ölkə/limit qaydaları, velocity (son 1 dəqiqədə 5 əməliyyat) kimi sürətli, izah edilə bilən yoxlamalar. Mikrosaniyələr.
  2. ML modeli (ehtimal): gradient boosting (XGBoost/LightGBM) və ya kompakt neyron şəbəkə. Keçmiş davranışdan öyrənir, qaydaların qaçırdığını tutur.

Qərar ikisinin birləşməsidir: qayda kəsin-rət deyirsə model işləmir; əks halda model skoru həddlə birləşir.

Feature store: isti və soyuq

Fraud modelinin ehtiyac duyduğu xüsusiyyətlər iki sürətdə gəlir:

  • İsti (online): 'son 1 dəqiqədəki əməliyyat sayı', 'son 5 dəqiqədəki ümumi məbləğ' kimi real vaxt sayğacları. Redis və ya oxşar aşağı-gecikməli store-da saxlanılır.
  • Soyuq (offline): 'müştərinin 90 günlük orta xərci', 'tipik əməliyyat saatı' kimi batch hesablananlar. Gündəlik/saatlıq yenilənir.

Feast kimi feature store-lar bu iki qatı vahid tərifdən istehsal edir; təlim və serving eyni feature məntiqini istifadə edir (train-serve skew qarşısı alınır).

Stream onurğası

Əməliyyat hadisələri Kafka (və ya oxşar) üzərindən axır. Tipik axın:

  1. Əməliyyat event-i Kafka topic-inə düşür.
  2. Stream processor (Flink/Kafka Streams) isti feature-ları yeniləyir.
  3. Skorlama servisi sinxron çağırışda online feature-ları oxuyur, model işlədir, skor qaytarır.
  4. Qərar və skor audit topic-inə yazılır; downstream hesabatlama və model yenidən-təlimi oradan qidalanır.

Model güncəl qalmalıdır

Fraud paternləri həftələr içində dəyişir. Memarlıqda iki dövr olmalıdır:

  • Online: skor anında qayıdır.
  • Offline: etiketli nəticələr (chargeback, manual inceleme) toplanır; model həftəlik/aylıq yenidən təlim olunur; champion-challenger ilə yeni model kölgədə test edilir, uğurludursa terfi edir.

İzah edilə bilənlik və uyumluluq

BDDK və EU AI Act fraud kimi yüksək-təsirli qərarlarda izah edilə bilənlik istəyir. Hər rət qərarı üçün modelin ən təsirli 3-5 feature-ı (SHAP dəyərləri ilə) qeyd olunmalıdır. 'Əməliyyat normaldan 8 dəfə yüksək məbləğdə və qeyri-adi ölkədə' kimi əsaslandırma həm auditə həm müştəri etirazına cavab verir.

Tipik nəticə

Qayda+model hibrid memarlıqda saha müşahidəsi: tək qayda sisteminə görə fraud tutma 30-45% artarkən, false-positive (real müştərinin rəddi) nisbəti doğru hədd kalibrasiyası ilə 20-30% azalır. False-positive birbaşa müştəri məmnuniyyəti və itirilmiş gəlirdir; ona görə hədd kalibrasiyası ən az model qədər vacibdir.

Yekun

Real vaxt fraud skorlaması model deyil, gecikmə büdcəsi problemidir. 100 ms içində feature lookup, model inference və qayda qərarı sığmalı; model güncəl qalmalı; hər qərar izah edilə bilməlidir. Doğru qurulduqda həm fraud itkisi həm yanlış-rət azalır.

Paylaş