Bankacılıktan sigorta analitiğine geçenler, iş tarafında daha dik bir öğrenme eğrisi bekler. Onları asıl çökerten şey ise veridir. Bankacılık verisi büyük ölçüde işlemseldir — bir borç, bir alacak, bir zaman damgası, bir bakiye. Türev ürünler ve FX bile, tüm karmaşıklıklarıyla birlikte, sonunda bir defterle mutabık kılınabilen satırlara indirgenir. Sigorta ise farklı bir türdür. Veri; gömülü belirsizlik, çok dönemli durum ve perakende bankacılıkta sorunsuz çalışan temiz yıldız şemalarına sığmayı reddeden ürün yapıları taşır.
Türk sigorta şirketleri ve reasürörleri için hayat, emeklilik ve sağlık ürünlerine yönelik pipeline'lar inşa ettikten sonra, sigorta verisini artık "bankacılık verisinin daha zor bir versiyonu" olarak görmeyi bıraktım. Yapısal olarak farklıdır ve hazır veri kalitesi çerçevelerinin çoğu bu veride sessizce başarısız olur.
Bankacılık Verisi Gerçekte Neye Benzer
Bir çekirdek bankacılık sistemini soyduğunuzda, az sayıda iyi davranışlı örüntü bulursunuz:
- Bir işlemin tutarı, valör tarihi, iki hesabı ve durumu vardır.
- Bir bakiye kümülatif bir toplamdır ve kuruşuna kadar mutabık kılınabilir.
- Bir kredi deterministik bir takvimde amortize olur. Temerrüde düşse bile olaylar ayrık ve zaman damgalıdır.
- Bir müşteri ya vardır ya yoktur. Bir ürün ya satılmıştır ya satılmamıştır.
Disiplin, mutabakattır. Gün sonunda rakamlarınız GL ile uyuşmuyorsa, bir hatanız vardır. Gerçek bilinebilirdir ve gerçek şimdidir.
Sigorta Verisi Gerçekte Neye Benzer
Sigorta verisi, bu varsayımların neredeyse hepsini ihlal eder.
1. Temel olgu bir işlem değil, bir olasılıktır. Bir poliçe, gelecekteki olası bir olay üzerine kurulu bir sözleşmedir. O poliçenin herhangi bir andaki "değeri", kendisi de üç ayda bir değişen varsayımlar altındaki nakit akışlarının beklenen bugünkü değeridir — mortalite tabloları, iptal oranları, iskonto eğrileri, morbidite varsayımları. 10 yıllık seviye-vadeli bir poliçenin bugün ne ettiğini söyleyen bir GL satırı yoktur. Bir model çıktısı vardır ve yapısı gereği yanlıştır. Siz nasıl yanlış olacağını seçiyorsunuz.
2. Durum çok boyutlu ve zaman katmanlıdır. Türkiye'de bir emeklilik sözleşmesi aktif, ödenmiş, kısmen iade edilmiş, prim tatilinde, başka bir şirkete transferde veya devlet katkısı geri alım penceresinde olabilir — bazen farklı fon dağılımlarında bunların birkaçı aynı anda. Bir sağlık poliçesi, altındaki belirli bir sigortalı askıdayken poliçe düzeyinde yürürlükte olabilir. Her durumun kendi geçerli geçişleri, yürürlük tarihleri ve muhasebe sonuçları vardır.
3. Geriye dönük değişiklikler kural dışılık değil, normaldir. Mart'ta raporlanan bir hasar, önceki yılın Kasım ayındaki bir olayla ilgili olabilir. Bir tıbbi underwriting kararı, başlangıcına geri tarihlenmiş şekilde teminatı geçersiz kılabilir. Acentelerden ve bancassurance partnerlerinden gelen prim mutabakatları 30–90 gün geç gelir ve geçmişi yeniden yazar. Bankacılıkta geriye dönük bir kayıt denetim tetikler. Sigortada bu sıradan bir Salıdır.
4. Ürün yapıları iç içe geçmiş ve koşulludur. Bir unit-linked emeklilik sözleşmesi; katkılar içeren, fonlar arasında dağıtılan, her birinin kendi birim fiyatları olan, farklı sıklıklarda kesinti yapılan, paralel bir takvimde hesaplanan devlet katkılarına sahip, çıkış nedeni ve süreye bağlı bir vergi rejimine tabi bir poliçedir. Tek bir tanecik (grain) yoktur. Bir tanecik seçerseniz bilgi kaybedersiniz; her taneciği taşırsanız warehouse'unuz kullanılamaz hale gelir.
5. Aynı varlık aynı anda birden fazla rejim altında ölçülür. Bir poliçe; yerel yasal muhasebe, IFRS 17, Solvency II (veya yerel eşdeğeri), vergi ve yönetim raporlaması altında rakamlar üretir — ve bunlar uyuşmayacaktır, uyuşmamalıdır da. Bankacılık anlamındaki "mutabakat" amaç değildir; kontrollü ıraksama amaçtır.
Standart Veri Kalitesi Çerçeveleri Burada Neden Başarısız Olur
Çoğu DQ çerçevesi — Great Expectations, dbt testleri, alışılmış kural kütüphaneleri — bir kaydın doğru bir değeri olduğunu ve sizin işinizin sapmayı tespit etmek olduğunu varsayar. Eksiksizlik, benzersizlik, referans bütünlüğü için iyi çalışırlar. Sigortada gerçekten önemli olan başarısızlık modlarında ise büyük ölçüde işe yaramazlar:
- Bir karşılık, çeyrekten çeyreğe %12 değiştiği için "yanlış" değildir. Yanlış olabilir ya da mortalite varsayımı değişmiştir ya da bir kohort farklı bir banda geçmiştir.
- Bir prim, bu ay gelmediği için "eksik" değildir. Poliçe üç aylık modda, ödemesiz dönemde veya ödenmiş statüde olabilir.
- Bir hasar tutarı, sigorta bedelini aştığı için "geçersiz" değildir. Bir rider, bir faiz bileşeni veya bir hukuki uzlaşma olabilir.
Sigorta verisi üzerinde saf null kontrolleri ve aralık kontrolleri çalıştırmak, ekiplerin görmezden gelmeyi öğrendiği binlerce yanlış pozitif üretir — bu da gerçek sorunların da göz ardı edilmesi anlamına gelir.
Mimarinin Gerçekte Neye İhtiyacı Var
Bir aktüerle temasta ne yaşayacağını bilecek kadar yeniden inşadan sonra şu noktada yakınsadım.
1. Her şey bi-temporal olmalı
Her fact tablosunun iki zaman boyutuna ihtiyacı vardır: yürürlük tarihi (iş olayının doğru olduğu zaman) ve bilgi tarihi (sistemin bunu öğrendiği zaman). Sahip olunması iyi bir özellik olarak değil. Tanecik (grain) olarak. Geçen Ekim'deki bir kaza için bugün kaydedilen bir hasar ödemesi, bugün gerçekleşen bir kaza için bugün kaydedilen hasar ödemesinden iki farklı satırdır ve karşılık modelinizin bunları ayırt etmesi gerekir. Bankacılık çoğunlukla tek bir zaman damgasıyla idare edebilir. Sigorta edemez.
2. Yalnızca akıtmayın, snapshot alın
CDC ve event stream'leri gereklidir ama yetersizdir. Poliçe durumunun periyodik tam snapshot'larına ihtiyacınız vardır — aktif kitaplar için günlük, en azından aylık — çünkü yeterince düzeltme biriktiğinde geriye dönük değişikliklerin kümülatif etkisi yalnızca event log'larından geri kazanılamaz. Depolama ucuzdur. Geçen yılın IFRS 17 CSM'sini bozuk bir event stream'den yeniden türetmek değil.
3. Poliçe yönetiminin gerçeğini aktüeryal gerçekten ayırın
Poliçe yönetim sistemi, sözleşmenin ne dediğini bilir. Aktüeryal sistem, sözleşmenin bir varsayımlar kümesi altında ne ettiğini bilir. Bunlar farklı yaşam döngülerine sahip farklı olgulardır. Bunları tek bir warehouse katmanında birleştirmek, gördüğüm en yaygın mimari hatadır. İki katmanı açıkça inşa edin ve aralarında varsayım versiyonlarını birinci sınıf veri olarak izleyen bir mutabakat katmanı kurun.
4. Varsayım setlerini config değil, versiyonlu veri yapın
Mortalite tabloları, iptal eğrileri, iskonto oranları, gider varsayımları — bunlar konfigürasyon değildir. Maddi finansal çıktıları yönlendiren ve bir takvimde değişen girdilerdir. Bunları warehouse'da yürürlük tarihleri, sahipleri ve onay kayıtlarıyla versiyonlayın. Birisi gömülü değerin neden değiştiğini sorduğunda, bir toplantıda değil SQL'de cevap vermeniz gerekir.
5. Ürün durumunu anlayan DQ kuralları inşa edin
Prim modunu, ödemesiz dönemi, prim tatilini ve ödenmiş statüyü bilmeyen bir prim DQ kuralı gürültü üretecektir. Her ürün hattının durum makinesini DQ katmanının kendisinde kodlayın. Evet, bu daha fazla iştir. Aynı zamanda aktüerlerin güvendiği bir DQ sistemiyle etrafından dolaştıkları bir sistem arasındaki farktır.
6. Reasüransı paralel bir defter olarak ele alın
Devredilen veri, brüt kaydın üzerindeki bir sütun değildir. Kendi geriye dönük düzeltmeleri, kendi tasfiye döngüleri ve kendi raporlama rejimi olan kendi sözleşmesel yapısıdır. Bunu, iyi tanımlanmış mutabakat noktalarında brüte birleşen paralel bir olgu akışı olarak modelleyin.
Altta Yatan Nokta
Bankacılık veri mühendisliği, bilinen bir gerçeğe karşı kesinliği ödüllendirir. Sigorta veri mühendisliği, bilinemez bir gerçek karşısında disiplini ödüllendirir. Çalışan sistemler; sigortanın yalnızca daha uzun zaman ufukları olan bir bankacılık olduğunu varsaymayı bırakan ve belirsizliği, geriye dönüklüğü ve varsayım bağımlılığını temizlenip atılacak istisnalar olarak değil, temel tanecik olarak ele almaya başlayan sistemlerdir.
Sigorta warehouse'unuz daha fazla sütunu olan bir bankacılık warehouse'una benziyorsa, zaten bozuktur. Sadece henüz çeyreği kapatmamışsınızdır.