Chargeback, Fraud ve Account Takeover Sinyalleri Neden Aynı Masada İncelenmeli?

Chargeback çoğu ekipte finans operasyonunun konusu olarak kalır. Oysa dispute artışı; çalınan kart bilgisi, account takeover (ATO), checkout sürtünmesi, belirsiz ödeme açıklaması, kötü iade deneyimi veya zayıf teslimat kanıtı gibi farklı kök nedenlerin geç sinyali olabilir.

Doğru soru "kaç chargeback aldık?" değil, hangi sinyal hangi müşteri yolculuğunda, hangi kayıpla tekrar ediyor? sorusudur.

Terimleri birbirinden ayırın

Ödeme risk programlarında aynı kelimeler farklı ekipler tarafından farklı anlamlarda kullanılabiliyor:

• Chargeback/dispute: Kart sahibinin işlemine itiraz etmesiyle başlayan ödeme uyuşmazlığıdır. Sonuç, işlem kanıtına ve ödeme sağlayıcısının kurallarına göre değişir.
• Transaction fraud: Kartın veya ödeme bilgisinin yetkisiz kullanılmasıdır.
• Account takeover (ATO): Saldırganın meşru kullanıcının hesabını ele geçirip ödeme yöntemi, adres, kupon veya sipariş üzerinde işlem yapmasıdır.
• Friendly fraud / first-party misuse: Gerçek kullanıcı işlemi inkâr edebilir, teslimatı yanlış tanımlayabilir veya iade politikasını kötüye kullanabilir.

Stripe, dispute ile transaction fraud ve ATO’yu ayrı risk türleri olarak ele alır. Bu ayrım, tek bir “fraud oranı” metriğinin neden yetersiz olduğunu gösterir. Stripe fraud tanımları

Ödeme yolculuğunda hangi sinyaller toplanmalı?

Chargeback olayını yalnızca processor panelinden okumak geç kalmış bir görünüm üretir. Risk ekibi aşağıdaki olayları ortak bir customer/account/session/payment ID ile ilişkilendirmelidir:

Aşama	Sinyal	Güvenlik sorusu
Login	Yeni cihaz, imkânsız seyahat, MFA başarısızlığı, parola sıfırlama	Hesaba giriş gerçekten kullanıcıya mı ait?
Checkout	Kart denemesi, hız, IP/ASN, cihaz ve adres uyuşmazlığı	Aynı aktör kaç hesap veya kartı deniyor?
Authentication	3DS sonucu, step-up, risk kararı	Kimlik doğrulama sinyali işlemle tutarlı mı?
Fulfilment	Teslimat adresi, dijital erişim, kargo kanıtı	Ürün gerçekten doğru hesaba mı gitti?
Support/refund	İptal, iade, temsilci değişikliği, açıklama	Dispute’tan önce müşteri hangi temasları yaptı?
Dispute	Reason code, tarih, tutar, temsil dosyası	Hangi kök neden tekrar ediyor?

Bu korelasyon, müşteri deneyimini cezalandırmak için değil, doğru müdahale seviyesini seçmek içindir. Düşük riskli bir uyumsuzlukta ek doğrulama yeterli olabilir; yüksek güvenli ATO sinyalinde oturum iptali, ödeme yöntemi kilidi ve manuel inceleme gerekebilir.

Sinyal korelasyonu nasıl tasarlanır?

İyi bir risk modeli tek bir cihaz veya IP sinyaline güvenmez. Aşağıdaki katmanlar birlikte değerlendirilir:

1. Kimlik: Hesap yaşı, MFA, parola sıfırlama, e-posta/telefon değişikliği ve oturum geçmişi.
2. Cihaz ve ağ: Cihaz parmak izi, IP/ASN, proxy/TOR göstergesi, aynı cihazdaki hesap sayısı.
3. Davranış: Deneme hızı, sepet tutarı, ürün/kupon paterni, checkout süresi ve navigation akışı.
4. Ödeme: Kart ülke/issuer uyuşmazlığı, 3DS sonucu, decline geçmişi ve ödeme yöntemi değişimi.
5. Operasyon: Teslimat, iade, destek, abonelik yenileme ve dispute kayıtları.

Bu katmanları puanlamak kadar, hangi kararın hangi kanıta dayandığını kaydetmek de önemlidir. Model veya kural “yüksek risk” dediğinde; kullanılan sinyaller, karar zamanı, uygulanan aksiyon ve sonucun ne olduğu daha sonra denetlenebilmelidir.

Kontrol seçimi: block yerine kademeli müdahale

Yanlış pozitif oranı yüksek bir sistem, fraud kaybını azaltırken iyi müşteriyi de durdurur. Bu yüzden aksiyonlar risk seviyesine göre kademelendirilmelidir:

• Düşük risk: görünmez izleme ve sonradan analiz.
• Orta risk: 3DS/step-up authentication, ek cihaz doğrulaması veya sınırlı tutar.
• Yüksek risk: manuel inceleme, ödeme yöntemi kilidi, oturum sonlandırma veya siparişin bekletilmesi.
• Doğrulanmış ATO: token revoke, parola/MFA reseti, ödeme yöntemlerinin yeniden doğrulanması ve etkilenen hesapların taranması.

Her aksiyon için kullanıcıya açıklanabilir bir neden ve destek ekibine erişilebilir kanıt sağlanmalıdır. Aksi halde chargeback ve müşteri şikâyeti riski, güvenlik kontrolünün yan etkisi olarak büyür.

Metrikler: yalnızca chargeback oranına bakmayın

Metrik	Ne anlatır?
Chargeback rate	İtirazların toplam işlem veya ciroya oranı
Fraud loss rate	Doğrulanmış fraud kaynaklı net kayıp
ATO detection rate	Ele geçirilen hesap olaylarında yakalama oranı
False-positive rate	Meşru müşterinin gereksiz bloklanma oranı
Step-up completion	Ek doğrulamadan başarıyla geçen kullanıcı oranı
Dispute win rate	Kanıt dosyasının ve operasyon sürecinin başarısı
Mean time to contain	ATO/fraud sinyalinden containment’a kadar geçen süre

Bu metrikleri kanal, ülke, ürün, ödeme yöntemi, hesap yaşı ve müşteri segmentine göre ayırın. Toplam oran, tek bir ürün veya koridor içindeki kümelenmeyi gizleyebilir.

30 günlük uygulama planı

İlk hafta: Son üç aylık dispute’ları reason code, ürün, ülke, ödeme yöntemi, yeni/eski hesap ve destek temasıyla sınıflandırın.

İkinci hafta: Login, checkout, 3DS, fulfilment, refund ve dispute olaylarını ortak kimliklerle birleştirin. Veri sahiplerini ve saklama sürelerini belirleyin.

Üçüncü hafta: En sık görülen iki kök neden için step-up, manuel inceleme veya operasyonel düzeltme tasarlayın. Aksiyonun yanlış pozitif etkisini ölçün.

Dördüncü hafta: Kontrollü ATO ve ödeme suistimali senaryolarıyla retest yapın. Kuralın hangi sinyalle tetiklendiğini, operatörün hangi kanıtı gördüğünü ve containment süresini kaydedin.

Sık sorulan sorular

Her chargeback fraud mudur?

Hayır. Chargeback; kart dolandırıcılığı, ATO, hizmet/teslimat anlaşmazlığı, abonelik iletişimi veya müşteri deneyimi sorunu gibi farklı nedenlerden kaynaklanabilir. Reason code ve işlem kanıtı incelenmeden fraud kararı verilmemelidir.

ATO’yu yalnızca login ekranında mı aramalıyız?

Hayır. ATO çoğu zaman login’den sonra görünür: parola/MFA değişikliği, yeni ödeme yöntemi, adres güncellemesi, yüksek değerli sipariş veya hızlı iade talebi gibi zincir sinyaller önemlidir.

En iyi fraud kuralı tek bir bloklama kuralı mıdır?

Hayır. Risk seviyesine göre izleme, step-up, manuel inceleme ve containment seçenekleri birlikte tasarlanmalıdır. Başarı, yüksek fraud yakalama ile düşük yanlış pozitif arasındaki dengedir.

Ödeme güvenliği için kanıt kartı

Her yüksek riskli işlem veya dispute için analistin aynı alanları görebilmesi gerekir:

Alan	Örnek kanıt
Kimlik	Login zamanı, MFA durumu, parola/MFA değişikliği
Cihaz ve ağ	Cihaz ID, IP/ASN, ülke ve önceki oturumlar
İşlem	Tutar, ürün, hız, kart/ödeme yöntemi, 3DS sonucu
Teslimat	Adres, kargo veya dijital erişim kaydı, teslim zamanı
Müşteri teması	İptal, iade, destek görüşmesi ve açıklama
Karar	Kural/model sinyalleri, aksiyon, operatör ve zaman damgası

Bu alanlar değiştirilemez veya sonradan denetlenebilir biçimde saklanmalıdır. Dispute temsil dosyasını hazırlayan ekip ile fraud kuralını yöneten ekip aynı kanıt sözlüğünü kullanmıyorsa, bir ekip için “ATO”, diğer ekip için “müşteri itirazı” olan olaylar ayrı silolarda kalır.

API ve mobil uygulama katmanı

Ödeme riski yalnızca ödeme sağlayıcısının ekranında çözülmez. Mobil uygulama ve API akışlarında hesap kurtarma, ödeme yöntemi ekleme, adres değişikliği, kupon uygulama, iade ve sipariş iptali aynı risk bağlamıyla korunmalıdır. Özellikle şu kontroller incelenmelidir:

• Kullanıcının erişemediği hesaba ait ödeme veya sipariş nesnesi API’den okunabiliyor mu?
• Parola sıfırlama sonrası eski token’lar ve cihaz oturumları iptal ediliyor mu?
• Ödeme yöntemi değişimi ile yüksek değerli sipariş arasında ek doğrulama var mı?
• İade endpoint’i hız, tutar, rol ve sipariş durumu bakımından sınırlandırılmış mı?
• Mobil istemciye güvenmek yerine kritik kararlar sunucu tarafında yeniden doğrulanıyor mu?

Bu akışları değerlendirirken mobil uygulama pentest kapsamı ve API erişim kontrolü kontrolleriyle birlikte düşünün. ATO sinyali çoğu zaman tek bir login hatasında değil, login sonrası yetkili görünen işlemler zincirinde ortaya çıkar.

Fraud operasyonunda sahiplik modeli

Risk kuralını güvenlik ekibi yazıp müşteri operasyonuna bırakmak veya dispute dosyasını yalnızca finans ekibine devretmek sürdürülebilir değildir. Her sinyal için owner, karar süresi, aksiyon, kanıt kaynağı ve retest tarihi yazılı olmalıdır.

Sinyal	Birincil owner	İkinci doğrulama
Credential stuffing / bot	Güvenlik	Fraud ve platform ekipleri
Yeni cihaz + ödeme yöntemi değişimi	Fraud	Hesap/ürün ekibi
Teslimat sonrası dispute	Ödeme operasyonu	Fulfilment ve destek
Abonelik yenileme itirazı	Ürün/finans	Müşteri operasyonu
Yüksek tutarlı ATO	Incident response	Hukuk, ödeme sağlayıcısı ve destek

Bu model hem containment süresini kısaltır hem de iyi müşteriyi gereksiz yere engelleyen kuralların daha hızlı düzeltilmesini sağlar.

Sonuç olarak chargeback oranı tek başına bir güvenlik metriği değildir. Login, cihaz, işlem, teslimat, müşteri teması ve dispute verisi aynı zaman çizelgesinde birleştiğinde ekip; kaybın nerede başladığını, hangi kontrolün işe yaradığını ve hangi kararın müşteri deneyimini bozduğunu ölçebilir.

Ortak Risk Görünümü

Sinyal	Olası kök neden	İncelenecek kanıt
Aynı cihazdan çoklu hesap ve başarısız deneme	Bot veya ATO	Device, IP, login ve ödeme denemesi ilişkisi
Teslimattan sonra "tanımıyorum" dispute'u	Kart dolandırıcılığı veya hesap ele geçirme	3DS, oturum, cihaz, fulfilment kaydı
Yenileme sonrası dispute artışı	Belirsiz billing descriptor veya iptal deneyimi	Abonelik onayı, bildirim, destek kayıtları
Aynı ürün kategorisinde kümelenme	Promosyon/iadeye kötüye kullanım veya fraud	Sipariş hızı, kupon, iade ve chargeback nedeni

Cyber Management Alliance'ın payment risk yazısı, fraud ve dispute verisinin ayrı silolarda tutulmaması gerektiğini vurguluyor. Bu yaklaşım doğrudur; fakat her eşleşme fraud kanıtı değildir. Kaynak yazı

Dört Ekibin Ortak Ritmi

• Risk/fraud: Anomali kuralı, cihaz/kimlik sinyali ve false-positive oranı.
• Güvenlik: ATO, bot, credential stuffing ve API kötüye kullanımı bulguları.
• Ödeme operasyonu: Dispute reason code, temsil dosyası ve processor etkisi.
• Müşteri operasyonu: Billing açıklaması, iptal/iade deneyimi ve çözüm süresi.

Bu ekipler haftada bir kez aynı örnek kümesini incelemelidir. Hedef, yalnızca kayıp işlem sayısını azaltmak değil; gerçek fraud'u yakalarken iyi müşteriyi yanlışlıkla engellememektir.

Uygulanabilir Kontroller

1. Login, ödeme denemesi, checkout, iade ve dispute olaylarını aynı müşteri/oturum zaman çizelgesine bağlayın.
2. Risk kurallarında cihaz, davranış ve işlem hızını tek bir sinyale indirgemeyin; tek sinyal bloklama yerine step-up authentication veya manuel inceleme kullanın.
3. Subscription ve dijital ürün akışlarında açık ödeme açıklaması, yenileme bildirimi ve kolay iptal yolunu doğrulayın.
4. Teslimat, iade ve müşteri destek kanıtlarını dispute dosyası için erişilebilir ve değiştirilemez biçimde saklayın.
5. ATO senaryosunu düzenli test edin: yeni cihaz, parola sıfırlama, ödeme yöntemi değişimi ve yüksek değerli sipariş zinciri.

30 Günlük Başlangıç

İlk ayda son üç aylık chargeback'leri reason code, ürün tipi, cihaz, ödeme yöntemi, yeni/eski hesap ve destek temasıyla sınıflandırın. Bu tabloyu fraud alert'leri ve login anormallikleriyle eşleştirin. Ardından en çok tekrar eden iki kök neden için bir kontrol değişikliği ve ölçüm tanımlayın.

Fintek veya e-ticaret sistemlerinde bu veri akışı API, kimlik ve ödeme entegrasyonlarıyla birleşir. Bu nedenle risk programı; checkout ve hesap akışlarını kapsayan uygulama güvenliği testiyle doğrulanmalıdır.