Lehtar Atama Sorunu: Hayat Sigortası Verilerini Doğru Tutmak Neden Diğer Tüm Kayıtlardan Daha Zordur

Sigorta şirketlerindeki çoğu veri ekibi, lehtar tablosunu bir müşteri adres tablosuyla aynı şekilde ele alır: poliçe başına bir satır, birkaç sütun, belki bir last_updated_at. Sıkıcı görünür. Sıkıcı değildir. Tüm poliçe yönetim sisteminin yasal açıdan en çok ifşa olmuş tek veri parçasıdır ve Türkiye'de ve yurt dışında birlikte çalıştığım hemen her sigorta şirketi, modellemeyi aynı şekilde yanlış yapar.

Hata biçimi her zaman aynıdır. Bir tazminat talebi gelir. Hasar eksperi mevcut lehtar kaydını çeker. Vefat edenin ailesi, farklı bir kişiyi belirten 2014 tarihli imzalı bir form sunar. Hukuk birimi veri ekibine sorar: Sistem 11 Mart 2014'te ne diyordu ve 12 Mart'ta bunu ne değiştirdi? Veri ekibi de yanıtın kurtarılamaz olduğunu keşfeder, çünkü 2017'de birisi şemayı taşımış ve eski lehtar versiyonları tek bir "güncel" satıra indirgenmiştir.

Bu veri neden yapısal olarak farklıdır

Bir banka hesabı bakiyesi türetilmiş bir değerdir. Onu işlem günlüğünden yeniden oluşturabilirsiniz. Kimse bakiye sütununu kaybetmekten endişe etmez, çünkü gerçek defteri kebirde yaşar.

Lehtar atamalarının varsayılan olarak eşdeğer bir defteri kebiri yoktur. İncelediğim çoğu poliçe yönetim sisteminde lehtar, mevcut durum olarak saklanır — bir isim, bir akrabalık kodu, bir yüzde. Değişiklik geçmişi, varsa eğer, şu yerlerde yaşar:

• Şanslıysanız poliçe numarasına göre dizinlenmiş, bir belge yönetim sistemindeki taranmış bir PDF
• old_value ve new_value yakalayan ancak değişikliği yetkilendiren yasal belgeyi yakalamayan bir denetim tablosu
• Bir acente ile arka ofis çalışanı arasındaki bir e-posta yazışması
• Hiçbir şey, çünkü acente telefonla güncelledi ve çalışan satırın üzerine yazdı

Bir lehtar uyuşmazlığı mahkemeye taşındığında, sigorta şirketinin üç şeyi kanıtlaması gerekir: kim lehtar olarak atanmıştı, atama ne zaman yürürlüğe girdi ve hangi belge bunu yetkilendirdi. Bir last_updated_at zaman damgası bu soruların hiçbirini yanıtlamaz.

Gayri resmi güncelleme sorunu

Özellikle Türkiye pazarında — ve sanırım bu evrenseldir — lehtar değişikliklerinin önemli bir kısmı asla resmi imzalı bir formdan geçmez. Yaygın örüntüler:

• Poliçe sahibi acenteyi arar. Acente arka ofisi arar. Çalışan alanı günceller. İmza yok, belge yok, değişiklik için yasal dayanak yok.
• Poliçe sahibi bir mektup yazar, mektup taranır ancak poliçe kaydına hiçbir zaman bağlanmaz. Değişiklik uygulanır, mektup ayrı bir belge arşivinde kaybolur.
• Bir bankasürans kanalı, daha geniş bir müşteri kayıt akışının parçası olarak lehtarı günceller ve değişiklik, ilgisiz bir ürünün rıza kapsamını devralır.

Bunların her biri, veritabanında uygun şekilde yetkilendirilmiş bir değişiklikle aynı görünen bir satır oluşturur. Veri katmanı bunları ayırt edemez. Hukuk birimi ayırt etmesi gerektiğinde, orijinal bağlam çoktan kaybolmuştur.

Şema göçleri kanıtları sessizce yok eder

En çok canımı sıkan kısım budur. En az üç sigorta şirketinde, iyi niyetli bir göçün — tek lehtar alanından çoklu lehtar tablosuna geçiş, akrabalık kodlarını normalleştirme veya yüzde paylaşımları ekleme — geçmiş versiyonları sessizce düşürdüğünü gördüm.

Göç betiği şöyle okunur: "her poliçe için, mevcut lehtarı al ve yeni tabloya ekle." Farklı bir şemaya sahip bir denetim günlüğünde yaşayan önceki versiyonlar, göç ekibinden kimse onları canlı veri modelinin bir parçası olarak düşünmediği için taşınmaz. Bir yerlerde bir yedek kasette dururlar, teknik olarak kurtarılabilir, ancak 30 günlük bir tazminat uyuşmazlığı penceresinde pratik olarak erişilemez.

Ders: Lehtar verilerine dokunan herhangi bir göç, tam versiyon geçmişini mevcut durumla aynı hukuki sadakatle taşımak zorundadır. Bunu yapamıyorsanız, eski depoyu göç öncesi herhangi bir soru için hukuki olarak otoriter kabul edip dondurmanız ve bunu açıkça belgelemeniz gerekir.

Lehtar durumu bir olay günlüğüdür

Doğru zihinsel model, müşteri profilleri için kullanılan değil, finansal işlemler için kullanılandır. Bir lehtar ataması şunları içeren bir olaydır:

• Bir yürürlük tarihi (sistem ekleme tarihiyle aynı değil)
• Bir yasal belge referansı (form ID, belge hash'i, noter kaydı)
• Bir yetkilendirme kanalı (imzalı form, mahkeme kararı, vekaletname)
• Yetkilendiren taraf (poliçe sahibi, vasi, düzenleyici)
• Önceki atamayla bir ardıllık ilişkisi

Mevcut lehtar, bu günlüğün belirli bir tarihe göre hesaplanmış bir izdüşümüdür. "11 Mart 2014'te lehtar kimdi?" sorusunu denetim tablosunun hayatta kalmış olmasını umarak değil, günlüğü sorgulayarak yanıtlayabilmelisiniz.

Somut olarak bu şu anlama gelir:

• Poliçe yönetim sistemindeki lehtar tablosu, bir gerçek kaynağı değil, bir görünümdür
• Her değişiklik, değiştirilemez bir belge kaydına yabancı anahtar taşır ve belge kaydı bir içerik hash'i taşır
• Geçerli bir yasal belge olmayan değişiklikler, daha sonra incelenmek üzere işaretlenmek yerine yazma sırasında reddedilir
• Olay günlüğü yalnızca ekleme yapılabilir niteliktedir ve poliçe yönetim veritabanı dışında çoğaltılır

Bunun maliyeti ve neye değdiği

Sigorta şirketleri bu tasarıma direnir çünkü basit işlemleri pahalı hale getirir. Bir arka ofis çalışanı artık üç tıklamayla lehtarı güncelleyemez. Acente telefonla değişiklik yapamaz. Bankasürans akışları, başvurunun geri kalanından ayrı olarak lehtar alanları için açık imzalı rıza yakalamak zorundadır.

Maliyet gerçektir. Alternatifin maliyeti daha yüksektir. Yetersiz belgeye sahip tek bir itiraz edilen tazminat talebi, yıllarca süren operasyonel tasarrufu aşan yasal ücretlere, düzenleyici dikkate ve itibar zararına mal olabilir. Daha da önemlisi, sigorta şirketinin aktüeryal karşılıkları bilinebilir bir lehtar dağılımı varsayar. Lehtar verileriniz yapısal olarak güvenilmezse, karşılık hesaplamalarınız kum üzerine kuruludur.

Pratik başlangıç noktası

Bir sigorta şirketi işletiyorsanız ve lehtar verilerinizde bu sorunun olduğundan şüpheleniyorsanız — ki neredeyse kesinlikle vardır — ilk hamle şemayı yeniden tasarlamak değildir. İlk hamle denetlemektir:

• Son beş yılda kaç lehtar değişikliğinin bağlanabilir imzalı bir belgesi var?
• Kaç göç lehtar tablolarına dokundu ve her seferinde versiyon geçmişi korundu mu?
• Lehtar güncellemelerinin hangi kısmı yasal belge üretemeyen kanallardan kaynaklanıyor?

Yanıtlar rahatsız edici olacaktır. Ayrıca size, veri kataloğunuzun muhtemelen düşük hassasiyetli referans verisi olarak etiketlediği bir tabloda tam olarak ne kadar yasal ifşa biriktiğini söyleyeceklerdir.

Lehtar durumu bir alan değildir. Onu öyle modellemeyi bırakın.