Her sigorta veri mühendisi eninde sonunda aynı rahatsız edici gerçekle karşılaşır: kapatılmış olarak işaretlenen bir hasar, finansal olarak kapatılmış bir hasarla aynı şey değildir. Rücu, bu boşluğun görmezden gelinemez hale geldiği yerdir.
Bir sağlık veya hayat sigortacısı bir hasarı ödedikten sonra bu ödemenin bir kısmını sorumlu üçüncü bir taraftan — ihmalkâr bir sürücüden, bir işverenden, bir üreticiden, başka bir sigortacıdan — tahsil ettiğinde, tahsilat orijinal hasarın kaydedilmesinden, rezervlenmesinden, serbest bırakılmasından ve raporlanmasından haftalar, aylar, bazen yıllar sonra gelir. Tahsil edilen tutar, muhasebe açısından anlamlı bir yeni işlem değildir. Pipeline'ınızın çoktan mezara koyduğu bir hasarın net maliyet pozisyonunu geriye dönük olarak değiştirir.
Ve sorun tam da burada başlar.
Kapatılmış, Kapanmış Anlamına Gelmez
Birlikte çalıştığım çoğu hasar veri pipeline'ı — ve Türkiye'deki hayat ve emeklilik şirketlerinde birkaçının sahibi oldum — hasar yaşam döngüsünü yalnızca ileri yönlü bir durum makinesi olarak ele alır. Hasar açıldı, rezervlendi, ayarlandı, ödendi, kapatıldı. Bir kez kapatıldığında kayıt, aşağı akış tüketiciler için dondurulur: aktüeryal küp, IFRS 17 ölçüm modeli, düzenleyiciye gönderilen raporlar, reasürans devir dosyaları, yönetim P&L'i.
Pipeline, beyaz tahtada makul görünen bir varsayım üzerine tasarlandı: kapatılma olayları terminaldir. Değildirler. Rücu, bu varsayımı paramparça eder çünkü:
- Tahsilat, bağımsız bir olaya değil, hukuki olarak orijinal hasara bağlıdır.
- Net hasar oranı, hasar gelişim üçgeni ve dava rezerv geçmişi — hepsi tahsilat geldiğinde değişir.
- Reasürans tahsilatları ve devir muhasebesi brüt hasara değil, net hasara bağlıdır.
- Düzenleyici raporlama dönemleri, brüt rakam üzerinden çoktan kapanmıştır.
Yani şimdi elinizde, tüm aşağı akış yığınınızın değişmezliğine bağımlı olduğu bir hasar kaydına mantıken ait olan bir tahsilat tutarı var.
Kimsenin Tasarlamadığı Paralel Defter
Pratikte olan şey, rücunun bir paralel deftere itilmesidir. Bazen bu, tahsilat biriminin tuttuğu bir Excel dosyasıdır. Bazen hasar sisteminde, veri ambarında kimsenin birleştirmediği bir yabancı anahtara sahip ayrı bir tablodur. Bazen hasar başına hiçbir izlenebilirlik olmadan portföy düzeyinde kaydedilen bir muhasebe düzeltmesidir.
Üçünü de üretimde gördüm, zaman zaman aynı şirkette. Sonuçlar tahmin edilebilir:
- Aktüeryal modeller tahsilat örüntülerini olduğundan az gösterir çünkü tahsilat verisi hasar üçgeninin kaynak sistemi dışında yaşar.
- IFRS 17 CSM hesaplamaları manuel katmanlar alır çünkü ölçüm modeli, denetim izini bozmadan kapatılmış kohortlar için ifa nakit akışlarını yeniden açamaz.
- Reasürans anlaşmazlıkları çoğalır çünkü devir hesaplaması, reasürörün kendi net görüşüne karşı itiraz ettiği brüt rakamları kullanır.
- Düzenleyici bildirimler ile iç yönetim hesapları aynı hasar üzerinde uyuşmazlığa düşer ve teknik olarak hiçbir taraf haksız değildir.
Tahsilat birimi ise tahsil edilen nakit üzerinden ölçülür. Dünyalarını tekrar hasar kaydına bağlayan bir veri modeli için savaşmak için hiçbir teşvikleri yoktur. Onların elektronik tablosu kendileri için gayet iyi çalışır.
Neden Hasarı Yeniden Açmak Cevap Değil
Saf mühendislik yanıtı şudur: tahsilat geldiğinde hasar kaydını yeniden aç, net maliyeti yeniden düzenle ve pipeline'ın değişikliği yaymasına izin ver. Bunun üç kez başarısız olduğunu izledim.
Başarısız olur çünkü aşağı akış sistemleri, yeniden düzenlenmiş geçmiş açısından idempotent değildir. 2023 Q1'deki kapatılmış bir hasarı 2024 Q4'te yeniden açmak şunları tetikler:
- Hasar konusuna abone olan her tüketiciye hasarın yeniden yayınlanması — ki çoğunun yeni bir olay karşısında yeniden ifadeyi ele alacak mantığı yoktur.
- Rezervlerin girdisi olan ve halihazırda kaydedilip denetlenmiş hasar üçgenlerinin yeniden hesaplanması.
- Önceki bildiriminin CFO tarafından onaylandığı ve düzenleyiciye sunulduğu düzenleyici raporlama katmanında sürüm çakışmaları.
- Aylar önce ödenmiş kâr paylaşımı ve acente komisyon tahakkuklarında zincirleme değişiklikler.
Sadece bir sayıyı değiştirmiyorsunuz. Tüm finans yığınından, muhasebe standartlarının bu itirafı tamamen önlemek için size mükemmel derecede meşru mekanizmalar — sonraki olay tanıma, cari dönemde kaydedilen tahsilat geliri — sunduğu bir noktada, önceki dönemin yanlış olduğunu kabul etmesini istiyorsunuz.
Gerçekten İşe Yarayan Nedir
Yeterince yara aldıktan sonra güvendiğim örüntü şu:
- Rücuyu hasarın bir mutasyonu olarak değil, hasara bağlı birinci sınıf bir olay olarak modelleyin. Hasar kaydı, kapatılmada değişmez kalır. Tahsilat, güçlü bir geri referansa sahip ayrı bir gerçektir.
- Aşağı akışta iki görünüm sunun: brüt-kapatılmış ve net-tahsilat sonrası. Her tüketicinin ihtiyaç duyduğu semantiği seçmesine izin verin. Aktüerya gelişim dönemi boyunca net-tahsilat sonrasını ister. Düzenleyici raporlama brüt-bildirildiği-gibi ister. Reasürans, anlaşmaya bağlı olarak her ikisini de ister.
- Tahsilatları, başlangıç dönemine bir bağlantı ile cari muhasebe döneminde kaydedin. Bu, analitik bağlantıyı kaybetmeden muhasebe kapanış disiplinine saygı gösterir.
- Tahsilat birimine bir elektronik tablo değil, gerçek bir sistem verin. Tahsilatlar Excel'de yaşadığı sürece, paralel defter hasar ambarından sürüklenmeye devam edecek ve her çeyrek kapanışında birisi bunu elle mutabakat yapıyor olacak.
- Sadece tahsilat gerçekleşmesini değil, tahsilat beklentisini de izleyin. Bir rücu davası tahsilat avukatları tarafından açıldığı an, bu bir sinyaldir. Beklenen tahsilatı yakalamak, aktüerin tahsilat gecikmesini bir sürpriz nakit girişi olarak değil, uygun bir stokastik süreç olarak modellemesine olanak tanır.
Daha Geniş Ders
Rücu en temiz örnektir ama tek örnek değildir. Dava sonrası yeniden açılan hasarlar, daha önce reddedilmiş hasarlara karşı kaydedilen ex gratia ödemeler, geriye dönük prim düzeltmeleri, portföy geçişleri altında kohort transferleri — sigorta finansal verisi, kapalı-kapalı-demektir varsayımını ihlal eden olaylarla doludur.
Eğer pipeline'ınız bu varsayım üzerine kurulduysa, bir sigorta veri platformu işletmiyorsunuz demektir. Çoğu zaman çalışan bir anlık görüntü üreticisi işletiyorsunuz. Rücu vakası, aslında hangisini inşa ettiğinizi öğrendiğiniz yerdir.
İlk günden itibaren yeniden ifadeye göre tasarlayın ya da finans ekibinizin sonsuza kadar paralel defterleri mutabakat yapacağını kabul edin. Üçüncü bir seçenek yok.