Data Department, bayi ve üye işyeri ağına ödeme limiti tanımlayan bir ödeme hizmetleri şirketiyle çalıştı. Çalışmanın odağı bayi temerrüdünü tahmin etmek ve bir bayi risk skoru oluşturmaktı; amaç limit artırım taleplerinin otomatik karara bağlanabilmesiydi.
Karar neydi?
Şirket her bayiye bir ödeme limiti tanımlıyor. Bayiler bu limitin artırılmasını düzenli olarak talep ediyor. Her talep küçük bir kredi kararıdır: tamamen onaylamak, kısmen onaylamak ya da reddetmek.
Bu talepleri elle değerlendirmek yavaştır ve tutarsız sonuçlar doğurabilir. Fazla kolay onay vermek, bayinin ödeme yapamama riskini artırır. Fazla sık reddetmek ise iyi bayilerin ve sağladıkları iş hacminin büyümesini sınırlar. Yanıtlamaya çalıştığımız soru şuydu: her talep için bayinin temerrüde düşme olasılığı tahmin edilebilir ve böylece güvenli talepler otomatik olarak onaylanabilir mi?
Ne geliştirdik?
| Bileşen | Yanıtladığı soru | Karardaki rolü |
|---|---|---|
| Temerrüt tahmin modeli | Bu bayinin ödeme yapamama olasılığı nedir? | Her limit kararının temel girdisi |
| Bayi risk skoru | Bu bayi basit bir risk ölçeğinde hangi konumda yer alıyor? | Kuralların talebi onaylamasını, sınırlamasını ya da incelemeye göndermesini sağlar |
| Limit geçmişinin yeniden kurulması | Her bayi zaman içinde hangi limiti istedi, hangisini aldı? | İki bileşen için eğitim verisi |
Model neyden öğrendi? Risk skoru üç tür veriye dayanıyordu:
- Limit talep geçmişi: talep edilen ve onaylanan limitler, tam ya da kısmi retler.
- İşlem geçmişi: her bayinin ödeme limitini gerçekte nasıl kullandığı.
- Ters ibraz ve itiraz verisi: ters ibrazlar (müşteri itirazı sonrasında geri alınan ödemeler) ve bayiyle ilişkili diğer itirazlar.
Veri hazırlığı neden işin büyük bir bölümünü oluşturdu?
Şirketin sistemleri limit değişikliklerini, talep ve kararların düzenli bir geçmişi olarak değil, bir değişiklik kaydı (log) olarak tutuyordu. Model eğitebilmek için önce her bayinin limit geçmişini bu değişiklik kayıtlarından yeniden kurmamız gerekti: ne talep edildi, ne onaylandı ve ne zaman.
Bu, kredi çalışmalarında sık karşılaşılan bir durumdur. Genel olarak, bir modelin ihtiyaç duyduğu karar geçmişi çoğu zaman yalnızca operasyonel sistemlerin bir yan ürünü olarak bulunur; bu geçmişi özenle yeniden kurmak, sonraki modellemeyi güvenilir kılan adımdır.
Sonuçlar
- Bayi temerrüt modeli ve bayi risk skoru: limit talebi, işlem ve ters ibraz verisinden oluşturuldu.
- Yeniden kurulan limit geçmişi: daha önce kullanılabilir biçimde mevcut değildi.
Bu proje için performans rakamı yayımlamıyoruz.
Ne öğrendik?
Karardan başlayın. Amaç hiçbir zaman soyut bir "kredi modeli" değildi. Amaç, limit artırım taleplerine daha hızlı ve tutarlı yanıt verebilmekti.
Veri çalışması, projenin asıl gövdesini oluşturur. Limit geçmişini yeniden kurmak emeğin büyük bir kısmını aldı ve sonraki modelleme çalışmalarında da yeniden kullanılabilir.
Skoru kurallara göre tasarlayın. Bir risk skoru, onaylamak, sınırlamak ya da incelemeye göndermek gibi aksiyonlara açıkça bağlandığında işe yarar. Skoru bu kuralları gözeterek kurmak, çıktının limit kararlarını veren kişiler tarafından kullanılabilmesini sağlar.
İlgili çalışmalar için finans ve sigorta sektörü sayfamıza, tahsilat tahmini projemize ve yapay zekâ stratejisi danışmanlığı hizmetimize bakabilirsiniz.
Sık sorulan sorular
Bayi risk skoru nedir?
Bayi risk skoru, bir bayinin ya da üye işyerinin borcunu ödeyememe olasılığını özetleyen bir sayıdır. Ödeme şirketinin limit taleplerine tutarlı kurallar uygulamasını sağlar.
Limit artırım kararları tamamen otomatikleştirilebilir mi?
Genel olarak en güvenli yaklaşım, net durumları otomatikleştirmek ve sınırdaki talepleri bir uzmana yönlendirmektir. Risk skoru bu ayrımı açık hâle getirir: Düşük riskli talepler onaylanır, daha yüksek riskli olanlar sınırlanır ya da incelemeye gönderilir.
Bayi kredi riski skorlaması için hangi veriler gerekir?
Bu projede limit talep geçmişi, işlem geçmişi ve ters ibraz ile itiraz verisi kullanıldı. Genel olarak, geçmiş kredi kararlarının kaydını bir araya getirmek işin en zor kısmıdır.