Tipik bir orta-büyük bankanın izlemesi gereken KPI sayısı 150-250 civarındadır: çağrı merkezi yanıt süresi, fraud bildirim oranı, kart aktivasyon hızı, kredi onay süresi, mobil uygulamada hata oranı, ATM doluluk... Bu KPI'ların her birinin 'düştü', 'fırladı', 'sapıyor' uyarısı doğru zamanda doğru kişiye gitmek zorundadır. Yanlış uyarı ekibi yorar, geç uyarı ise para kaybettirir.
İki saf yaklaşımın eksiği
Saf threshold (eşik) yaklaşımı: KPI < X ya da > Y olunca uyar. Hızlı, açıklanabilir; ama mevsimsellik ve trendi yakalamaz. Bayram öncesi yükselen kart kullanımı her yıl aynı saatte 'anomali' alarmı çıkarır.
Saf ML yaklaşımı: Time-series anomaly detection (Prophet, isolation forest, LSTM) modelle. Mevsimselliği yakalar; ama açıklanabilir değildir, yeni KPI için soğuk başlangıç sorunu yaşar, modelin kendisi de bakım ister.
CentraQL ikisini bir arada kullanır.
Hibrit model
for kpi in active_kpis: val = current_value(kpi) if hard_threshold_violated(kpi, val): emit(severity="critical", reason="hard threshold") continue z = rolling_z_score(kpi, window=28d) if abs(z) > kpi.z_threshold: baseline_pred = seasonal_baseline(kpi) if outside_band(val, baseline_pred, kpi.band): emit(severity="warning", reason="z-score+seasonal")
Üç katman: hard threshold, z-score, seasonal baseline.
1. Hard threshold (kural)
İş tarafı için sözleşmesel limitler buradadır. Örnek: kredi onay servisi p95 latency > 5 sn, fraud bildirim oranı saatlik > 0.8%. Kuralı analist yazar, owner onaylar, SLA bağlanır.
2. Z-score (istatistiksel)
KPI'nın son 28 günlük penceresinde mean ve std hesaplanır. Anlık değer için |z| > eşik (genelde 3.0) ise sinyal oluşur. Z-score açıklanabilirdir; '28 günlük ortalamadan 3.4 sigma uzakta' cümlesi her CFO'nun anladığı bir cümledir.
3. Seasonal baseline (CentraQL özel)
Z-score tek başına bayram, hafta sonu ve gün-içi ritmi yakalayamaz. Seasonal baseline aynı saat aynı haftagünü için 8 haftalık ortalama bandını üretir. Sinyal z-score AND seasonal koşuluyla tetiklenir; iki testten geçemeyen değer alarm yaratmaz. Bu yaklaşım false-positive'leri 3-5 kat azaltır.
Eşik konfigürasyonu
KPI bazlı, profil bazlı ve domain pack bazlı eşik kademe kademe override edilebilir:
- Sistem default: |z| > 3.0
- KPI 'fraud_rate_hourly' override: |z| > 2.5 (daha duyarlı)
- ComplianceProfile 'RegulatedFinance' tightens: |z| > 2.0 + seasonal AND
Bu kademeli yapı eşik tartışmalarını politikaya çevirir; her KPI için ayrı kavga olmaz.
Anomali açıklaması
CentraQL anomali tespit ettiğinde Copilot pipeline'ı tetiklenir; açıklama narrator LLM tarafından üretilir: 'Saat 14:00, ATM doluluk oranı %38; son 8 hafta aynı saatte %52 ± 4. Sinyal z=-3.6, mevsimsel band dışında. Geçen Salı saat 14:00'te %50.' Açıklama PromptAuditLog'a yazılır; ekip 'neden alarm geldi' sorusuna cevap arama gerekmez.
Operasyonel çıktı
Bir bankada test pilotunda 180 KPI üstünde:
- Saf threshold: ayda 240 alarm, %72'si false-positive.
- Saf z-score: ayda 380 alarm, %58'i false-positive.
- CentraQL hibrit: ayda 110 alarm, %18'i false-positive.
False-positive azalması = ekip alarm yorgunluğunda azalma = gerçek olaya tepki süresinde 4 kat hızlanma.
Sonuç
KPI anomali tespiti tek başına ne kural ne ML işidir. Hard threshold sözleşmeyi, z-score sapmayı, seasonal baseline ritmi yakalar. CentraQL üçünü tek panelde birleştirir, alarmı Copilot'a anlattırır, audit'e yazar. Bankanın izlediği 200 KPI ile başlamak için tipik kurulum süresi: 1 gün domain pack ekleme, 3 gün owner ile eşik tuning, sonrasında otomatik.
