Bir Türk sigorta şirketinin operasyon odasında her birkaç ayda bir birisi, kulağa basit gelen ama aslında basit olmayan bir soru sorar: "Müşterinin gerçek çekilebilir bakiyesi nedir?"
Eğer o müşteri BES birikimi ya da bir hayat birikim ürünü karşılığında poliçe kredisi kullanmışsa, bu sorunun cevabı, gerçek zamanlı olarak birbirleriyle uyumlu çalışmak üzere hiçbir zaman tasarlanmamış en az üç sistemi bir araya dikmeyi gerektirir. Ve düzenleyici raporları, CRM panolarını ve aktüeryal modelleri beslemek için kurduğunuz veri hattı büyük olasılıkla bunları bir araya dikmiyor. Sadece en son yazılan hangi rakamsa onu alıp ona "gerçek" diyor.
Bu, poliçe kredisi veri sorunudur ve sigorta veri mimarisinde gördüğüm en kalıcı sessiz-başarısızlık örüntülerinden biridir.
Kredi neden yapısal olarak görünmezdir
BES ya da hayat birikim bakiyesi karşılığında verilen bir poliçe kredisi, bireysel bankacılık anlamında bir kredi değildir. Poliçe sahibinin kendi birikmiş paylarına karşı, çekim anındaki fon NAV'ına göre fiyatlanan ve çoğu zaman hem fonun günlük değerlemesinden hem de genel muhasebedeki ay sonu kapanışından bağımsız bir takvimde faiz işleyen, teminatlı bir çekimdir.
Bu durum, aynı ekonomik pozisyonu farklı açılardan tanımlayan üç ayrı defter ortaya çıkarır:
- Emeklilik/birikim defteri payları, NAV'ı, katkıları ve fon dağılımını takip eder. Genellikle bir kredinin var olduğunu bilmez. Paylar hâlâ oradadır.
- Kredi defteri anaparayı, tahakkuk eden faizi ve geri ödemeleri takip eder. Genellikle hangi payların neyi teminatlandırdığını bilmez.
- GL bir alacak ve buna karşılık gelen bir yükümlülük hareketini toplu olarak görür; çoğu zaman bir şeyleri geriye dönük çözebilecek poliçe düzeyinde ayrıntı olmadan.
Her sistem kendi içinde tutarlıdır. Sorun şu ki teminat pozisyonu — belirli bir NAV'daki belirli payların üzerindeki rehin — hiçbirinde birinci sınıf bir varlık değildir. Örtük olarak, talep üzerine hesaplanması gereken bir fark olarak var olur.
Ve talep üzerine hesaplanması gerektiği için, çoğu raporlama hattı bunu hesaplamaz. Emeklilik bakiyesini raporlar. Kredi bakiyesini raporlar. Aynı müşteri ekranında ikisini birlikte gösterir. Birisi gerçekten para hareketi yapmaya çalışana kadar kimse aritmetiğin kapanmadığını fark etmez.
Yalnızca baskı altında yapılan mutabakat
Gerçeğin anı neredeyse her zaman bir para çekme, başka bir kuruma aktarım (BES aktarım), bir iştira ya da bir ölüm tazminatıdır. İşte tam o anda operasyon şu soruyu cevaplamak zorunda kalır: gerçekte ne kadar ödenecek?
O noktada biri bir ticket açar, biri üç ayrı ekstre çeker, biri bir Excel dosyasını çalıştırır ve biri — genellikle bu durumun son yaşandığı zamanı hatırlayacak kadar uzun süredir orada olan kıdemli bir operasyoncu — tutarsızlığı elle çözer. Müşteri sabırlıysa bu günler sürer. Müşteri bir avukatsa haftalar ve yazılı bir açıklama gerektirir.
O Excel dosyasında olan şey, veri modelinin sürekli olarak üretiyor olması gereken bir mutabakattır. Veri hattı krediyi, sorulduğunda kontrol edilen bir durum olarak ele aldı; oysa kredi, tesis edildiği andan itibaren tüm alt bakiyelerin anlamını değiştiren bir olaylar dizisidir.
İşte gölge defter budur. Vardır. Maddi olarak doğrudur. Sadece operasyon personelinin kafasında yaşar ve talep üzerine Excel'e serileştirilir.
Neden yeni bir rapor eklemek sorunu çözmez
Sezgisel tepki — ki bu tepkinin birden çok kez başarısız olduğunu izledim — kredi sistemini emeklilik sistemine bağlayan ve net pozisyonu gösteren bir "kredi risk raporu" sipariş etmektir.
Bu belirli bir nedenle başarısız olur: join zamansaldır ve sistemler ortak bir zaman ekseni paylaşmaz.
- Emeklilik defteri günlük fon NAV kapanışında değerlenir.
- Kredi defteri faizi kendi takviminde, çoğu zaman farklı bir gün sayım yöntemiyle işletir.
- Geri ödemeler, bordro kesinti döngülerinden geldiklerinde geriye dönük etkin tarihlerle kaydedilebilir.
- Kredi tesisinin kendisi bile, paylar kavramsal olarak "rehin edilirken" talep tarihinden iki üç iş günü gecikmeli bir valör tarihine sahip olabilir.
Bu tabloların bir zaman noktasındaki join'i, tam olarak bir an için savunulabilir ve kısa süre sonra yanlış olan bir sayı üretir. Bunu denetleyemezsiniz çünkü gelecek hafta farklı bir gerçeğe mutabık düşecektir. Geçmiş bir rakamı yeniden üretemezsiniz çünkü altındaki tabloların hiçbiri "14 Mart'ta bu nasıl görünüyordu?" sorusuna cevap verecek şekilde tasarlanmamıştır.
Yeniden mimarleştirme: Kredi yaşam döngüsü birinci sınıf olaylar olarak
Çözüm bir rapor değildir. Kredinin yaşam döngüsünün her biri kendi valör tarihi, kayıt tarihi ve versiyonlanabilir yükü olan açık durum geçişlerine ayrıştırıldığı bir olay modelidir:
- Tesis olayı — rehin edilen payları, rehin anındaki NAV'ı, verilen anaparayı, faiz takvimini, valör tarihini ve rehnin uygulandığı belirli fon dağılımını yakalar.
- Tahakkuk olayı — kredinin kendi takviminde üretilir, tesis olayını referans alır ve kendi valör tarihine sahip bir faiz kaydı oluşturur.
- Yeniden değerleme olayı — altında yatan NAV, teminat karşılama oranını değiştirecek kadar önemli ölçüde değiştiğinde üretilir. Bu, raporlama hatlarının neredeyse hiç üretmediği olaydır ve çekilebilir bakiye sorgularını cevaplanabilir kılan da tam olarak budur.
- Geri ödeme olayı — kaynağı (bordro, otomatik ödeme, toplu ödeme), valör tarihi ve anapara ile tahakkuk etmiş faiz arasındaki dağılımı ile birlikte.
- Kapanış olayı — tam geri ödeme, iştiraya karşı mahsup ya da tazminat yoluyla olsun, sonlandırıcı.
Bu olayların her biri, poliçeye göre anahtarlanmış ve valör tarihine göre sıralanmış, yalnızca ekleme yapılabilir bir depoya iner. Herhangi bir zaman noktasındaki bakiyeler — emeklilik, kredi, çekilebilir, rehinli — o zaman damgasına kadar olan olay akışının deterministik fonksiyonları haline gelir.
Pratik sonuçları:
- Çekilebilir bakiye sorusu bir ticket değil, bir sorgu haline gelir.
- BES aktarım talepleri, müşteri telefonda beklerken değil, telefon açılmadan önce fiyatlanabilir.
- Aktüerya ve risk ekipleri, herhangi bir geçmiş tarihte riski yeniden inşa edebilir; bu, düzenleyicinin belirli bir raporlama dönemi hakkında soru sorduğunda önem kazanır.
- Mutabakat bir olay olmaktan çıkar ve sürekli bir özellik haline gelir.
Bunun maliyeti ve rol yapmanın daha yüksek maliyeti
Dürüst karşı argüman şudur: bu, gecelik bir extract-and-join'e göre inşa edilecek ve işletilecek daha fazla altyapı gerektirir. Bu doğrudur. Aynı zamanda şikayet oranlarında, ombudsman başvurularında, gecikmiş aktarımlarda ve bir müşteriye aynı hafta içinde iki farklı kanaldan iki farklı çekilebilir bakiye söylenmesinin yarattığı belirli itibar hasarında ortaya çıkan gizli bir maliyeti olduğu da doğrudur.
Bu senaryonun tam olarak orta-yedi haneli bir düzeltme projesiyle ve düzenleyicinin iç kontroller hakkında yönlendirilmiş sorular sormasıyla sonuçlandığını gördüm. Olay modeli düzeltme çalışmasından daha az maliyetli olurdu ve düzenleyicinin gerçekten görmek istediği denetim izlerini üretirdi.
Poliçe kredisi, Türk BES ve hayat portföylerinde nadir bir uç durum değildir. Bu alanda çalıştığım süre boyunca mimari olarak istisna gibi ele alınmış rutin bir ürün özelliğidir. Onu veri modelinin birinci sınıf bir vatandaşı olarak ele almak gecikmiş bir adımdır ve bu geçişi zaten yapmış olan veri hatları, operasyon ekiplerinin para çekme günlerinde Excel açmayı bıraktığı hatlardır.