Uzun Ömürlü Finansal Sözleşmelerde Şema Versiyonlama Sorunu

2005'te imzalanan bir emeklilik sözleşmesi; ona dokunan her sistemden, her mimardan ve her veri sözlüğünden daha uzun ömürlü olan bir taahhüttür. Poliçe 2026'da hâlâ defterlerdedir. Doğduğu şema ise değildir.

Veri ekiplerinin küçümsediği kısım tam da budur. E-ticaret veya SaaS'ta bir şema migrasyonu, cuma öğleden sonrası çalıştırılan bir Liquibase script'idir. Emeklilik ve hayat sigortasında ise bir poliçeyi düzenlemek için kullandığınız şema, sözleşmesel ve düzenleyici kaydın bir parçasıdır. Düzenleyici size 2011'deki teknik karşılığı nasıl hesapladığınızı sorduğunda ya da bir lehtar 2014'teki bir ödeme hesaplamasına itiraz ettiğinde, bugünkü modelle cevap verme lüksünüz yoktur.

Uzun vadeli sözleşmeler şema disiplinini neden bozar

Bir vadeli hayat veya birikimli emeklilik ürününün, şema versiyonlamayı benzersiz biçimde zorlaştıran üç yapısal özelliği vardır:

• Süre: 20 ila 50 yıl aktif durum. Sözleşmeyi düzenleyen sistem, sözleşme vadesini doldurmadan büyük olasılıkla devreden çıkarılmıştır.
• Düzenleyici katmanlar: Solvency II, IFRS 17, FATCA, CRS, yerel emeklilik otoritesi genelgeleri, Türkiye'de MASAK, Almanya'da BaFin — her biri "prim" veya "karşılık"ın anlamını değiştiren alanlar, yeniden hesaplamalar veya yeniden sınıflandırmalar getirir.
• Geriye dönük uygulama: Pek çok düzenleme, geçmiş pozisyonları yeni çerçeve altında yeniden ifade etmenizi gerektirir. IFRS 17 geçişi bunun bariz örneğiydi; çok az ekip bu egzersizi tekrar yapacaklarının farkında.

Bileşik etki şudur: Veri modeli bir anlık görüntü değildir. Zamanın her noktasında hukuki ağırlığı olan, hareket halindeki bir hedeftir.

Sessiz birikim

Çoğu sigortacı şema değişikliğini aynı şekilde yönetir:

1. Düzenleyici istediğinde yeni bir kolon eklenir.
2. Mevcut poliçeler için en iyi tahmine dayalı bir varsayılan değerle doldurulur.
3. Değişiklik, kimsenin okumadığı bir Confluence sayfasında belgelenir.
4. Yola devam edilir.

Bu adımların her biri tek başına savunulabilir. Ancak bileşik etkisi savunulamaz. On yıl sonra, elinizde şöyle bir policy tablosu olur:

• tax_residency_country 2014'te FATCA için eklenmiş ve herkes için TR olarak doldurulmuştur; 2016'da raporlanabilir hale gelen Almanya'daki vatandaş dahil.
• product_category 2018'de emeklilik otoritesi iki ürün sınıfını birleştirdiğinde yeniden tanımlanmıştır, ancak eski kodlar geçiş öncesi düzenlenen poliçelerde hâlâ görünmektedir.
• surrender_value_method bir string alan olarak vardır ve üç farklı ekip ona yazdığı için aynı algoritmanın yedi farklı yazılışını içerir.
• Referans tablolarındaki valid_from / valid_to kolonları 2020'de eklenmiştir, dolayısıyla 2020 öncesinin hiçbir zamansal sınırı yoktur.

Bunların hiçbiri, bir FATCA denetimi sizden 31 Aralık 2017 itibarıyla raporlanabilir popülasyonu o tarihte yürürlükte olan kurallar ve veri modeliyle yeniden üretmenizi isteyene kadar görünmez.

"Modeli yeniden inşa etmek" gerçekte ne demek

Sınır ötesi bir denetimde — FATCA, CRS veya düzenleyici kaynaklı bir yeniden ifade — size üç şey sorulur:

• X tarihinde ne biliyordunuz? Bugün sistemde ne olduğu değil, o tarihte operasyonel sistemlerin neyi içerdiği.
• Hangi kurallar altında sınıflandırdınız? Şema versiyonu, kod listeleri, hesaplama motorları.
• Çıktıyı yeniden üretebilir misiniz? İdealde bit bit. En azından yaklaşık olarak.

Tek cevabınız "2017'den bir yedek teyp bir yerlerde var" ise, zaten kaybetmişsiniz demektir. Bir teybi geri yüklemek size veri verir, çalıştırılabilir bir model değil. Size DDL gerekir, o tarihteki referans verisi gerekir, hesaplama mantığının versiyonu gerekir ve o günkü alanlardan bugünkü alanlara eşleme gerekir.

Gördüğüm sigortacıların çoğu bunu üç yıldan daha geriye yapamıyor. Bazıları bir yıldan bile.

Asıl işe yarayan

Bu, daha şık bir veritabanı seçerek çözülmez. Bu, şemayı birinci sınıf, versiyonlanmış, zaman bağlı bir varlık olarak ele alarak çözülür. Somut olarak:

• Sözleşmeyle ilgili her tabloda bitemporal depolama. İki zaman ekseni: valid_time (gerçeğin dünyada ne zaman doğru olduğu) ve system_time (bizim ne zaman kaydettiğimiz). Sadece policy tablosunda değil — bir hesaplamayı besleyen her referans tablosunda, kod listesinde ve oran tablosunda.
• Veri olarak şema. Her düzenleyici rejim için DDL ve kod listesi değerleri sorgulanabilir olmalıdır. IFRS 17 geçişi altında karşılık hesaplarken, "2015-06-30 tarihinde yürürlükte olan ürün taksonomisi neydi" sorusunu, başka herhangi bir soruyu sorduğunuz gibi sorabilmelisiniz.
• Şema versiyonlamasıyla bağlantılı hesaplama motoru versiyonlaması. 2011'deki karşılık hesabı, 2011'de var olan alanlara ve kod listelerine referans veriyordu. Motor versiyonu, şema versiyonu ve düzenleyici rejim bir üçlüdür. Birlikte saklayın, birlikte deploy edin, birlikte emekliye ayırın.
• Sessiz backfill yok. 2014'te tax_residency_country eklediğinizde, 2005 poliçesi için değer TR değil, unknown olmalıdır. Onu topladığınız gün, poliçe başlangıç tarihiyle değil, toplama tarihiyle bir valid_from ile kaydedersiniz. En çok zararı önleyen tek değişiklik budur.
• Migrasyon script'leri değil, migrasyon kayıtları. Bir migrasyon tarihsel bir olaydır. Saklayın: ne değişti, ne zaman, neden, kim onayladı, geri alma nasıl görünürdü. Liquibase changelog gereklidir ama yeterli değildir.

Dürüst kısım

Bunların hiçbiri sıfırdan iş değildir. 1990'lardan kalma poliçeleri olan bir portföyü, iki kez modernize edilmiş bir çekirdek sistemde çalıştırıyorsanız, bitemporal depolamayı her yere geriye dönük olarak uygulayamayacaksınız. 2008 kod listesini hafızadan yeniden inşa edemeyeceksiniz.

Yapabileceğiniz şey, birikimi durdurmaktır. Bir sonraki düzenleyici değişikliği seçin — on iki ay içinde mutlaka bir tane olacak — ve onu, düzgün versiyonlanmış bir şema kayıt defterinin ilk girdisi olarak ele alın. Savunabildiğinizi backfill edin. Geri kalanı bilinmeyen olarak işaretleyin. Hedef mükemmel bir geçmiş değildir. Hedef, beş yıl sonra denetim geldiğinde, bugünden sonraki dönemin yeniden inşa edilebilir olmasıdır.

Bugünden önceki dönem bir müzakeredir. Bugünden sonraki dönem bir tercihtir.