Çoğu BES (Bireysel Emeklilik Sistemi) veri pipeline'ı hakkındaki rahatsız edici gerçek şudur: sayıyı üretebilirler, ama sayıyı kanıtlayamazlar. Bildirim EGM'ye zamanında gider, toplam rakamlar mutabık kalır, regülatör dosyayı kabul eder. Herkes tesisatın anlaşıldığını varsayar. Sonra bir gün belirli bir soru gelir — genellikle belirli bir katılımcı hakkında, belirli bir tarihte, belirli bir bakiye ile — ve tüm varsayım zinciri çöker.
Bunun birden fazla emeklilik şirketinde yaşandığını gördüm. Örüntü hep aynıdır. Pipeline'ı üç yıl önce kuran ekibin bir kısmı artık orada değildir. Ara tablolar iki kez refactor edilmiştir. Informatica veya SSIS işleri Python'da yeniden yazılmıştır. Referans veri lookup'ları artık farklı bir kaynağa gitmektedir. Bir katılımcı hesap ekstresindeki 47.823,14 TL bakiyenin ham katkı kayıtlarından, birim fiyatlardan, devlet katkısı tahakkuklarından ve fon dönüşümlerinden nasıl türetildiğini kimse güvenle yeniden inşa edemez.
Soyağacı Dokümantasyon Değildir
Çoğu firma veri soyağacını bir dokümantasyon problemi olarak ele alır. Bir katalog aracı satın alırlar, bir tarayıcı çalıştırırlar ve A tablosunun B tablosunu, B tablosunun C tablosunu beslediğini gösteren diyagramlar üretirler. Bu, denetim kontrol listelerini tatmin eder. Regülatörün asıl sorusunu cevaplamaz.
Regülatör "hangi tablolar dahildi" diye sormaz. Regülatör şunu sorar:
- Bu katılımcının 15 Mart'taki fon dağılımı, imzalı tercih formundan çıkarılan dağılımdan neden farklı?
- Bu hesap için devlet katkısı tahakkuku, neden önceki bir döneme ait görünen bir oran kullanıyor?
- EGM'ye fon dağılımı için sunulan toplam, neden büyük deftere mutabık kalıyor ama bireysel katılımcı kayıtlarının toplamına mutabık kalmıyor?
Bunları cevaplamak, çıktıları açığa çıkarmak için tasarlanmış — bu çıktıları üreten muhakemeyi değil — sistemler arasında, satır seviyesinde, belirli bir zamanda dönüşüm mantığını yeniden inşa etmeyi gerektirir.
BES Pipeline'ları Neden Yapısal Olarak Kördür
Türkiye'deki emeklilik pipeline'ları, on beş yıllık regülatif değişim boyunca organik olarak büyüdü. Her yeni EGM genelgesi veya SEDDK gereksinimi mevcut yapının üzerine cıvatalandı. Sonuç, birlikte çalıştığım hemen hemen her firmada aynı mimari başarısızlıkları içeriyor:
- Üzerine yazılan durum. Katılımcı bakiyeleri yerinde güncellenir. Önceki değer gitmiştir. Biri dünkü bakiyenin bugünkü bakiyeye nasıl dönüştüğünü sorduğunda, pipeline bunu hâlâ eksiksiz olabilecek ya da olmayabilecek olay loglarından yeniden türetmek zorundadır.
- Yürürlük tarihi olmayan referans veriler. Fon kodları, katkı oranları ve devlet katkısı parametreleri güncel değerler olarak saklanır. 2022'de yapılan bir hesaplama 2025'te yeniden üretilemez çünkü parametre satırı o zamandan beri üç kez güncellenmiştir.
- Kimsenin okumadığı stored procedure'lere gömülü dönüşüm mantığı. Asıl iş kuralı — katılımcının birden fazla aktif planı olduğunda kısmi bir katkının fonlar arasında nasıl dağıtılacağı — 2021'de ayrılmış birinin son kez değiştirdiği 400 satırlık T-SQL içinde yaşar.
- Sadece toplam seviyesinde mutabakat. Günlük kontroller toplamların eşleştiğini kontrol eder. Toplamın kompozisyonunun açıklanabilir olup olmadığını kontrol etmezler. Bir pipeline, bireysel kayıtlar sessizce yanlışken yıllarca her mutabakattan geçebilir.
Regülatörün Aslında İstediği Şey
EGM veya SEDDK bir veri talebi gönderdiğinde, veri kataloğunuz olup olmadığını test etmiyorlar. Operasyonel gerçekliğinizin sunduğunuz gerçeklikle eşleşip eşleşmediğini test ediyorlar. Bu ikisi arasındaki boşluk, yaptırımın yaşadığı yerdir.
Somut bir örnek: bir firma aylık fon bazında katılımcı sayısı rakamlarını sunar. Sayı 128.400'dür. Regülatör, bu sayıyı üreten katılımcı seviyesindeki listeyi ister. Liste, yeniden oluşturulduğunda 128.412 içerir. On iki hesaplık fark dolandırıcılık değildir. Zamanlamadır — bildirim 23:47'de üretildi, o zaman ile gece yarısı arasında on iki hesap durum değiştirdi ve pipeline sunulan tam durumu korumuyor. Snapshot yok. Firma, sunduğu şeyin sunum anında doğru olduğunu kanıtlayamaz çünkü o anı yeniden üretemez.
Bu bir soyağacı başarısızlığıdır. Aynı zamanda mimari bir başarısızlıktır. Bunu dokümantasyonla yamalayamazsınız.
Birinci Sınıf Mimari Kısıt Olarak Soyağacı
Regülatif soruları iyi ele alan firmalar, genellikle bir kez yandıktan sonra, belirli yapısal seçimler yapmıştır:
- Gerçeğin kaynağı olarak değiştirilemez olay logları. Katılımcı bakiyeleri türetilir, asla ground truth olarak saklanmaz. Olay logu yalnızca ekleme yapılır. Herhangi bir tarihsel bakiye, belirli bir zamana kadar olayları yeniden oynatarak yeniden inşa edilebilir.
- Bi-temporal referans verileri. Her parametre tablosu hem iş yürürlük tarihi hem de sistem kayıt tarihi taşır. Geçen yıl yapılan bir hesaplama, o zaman yürürlükte olan parametrelerle, o zaman bilindikleri şekliyle yeniden üretilebilir.
- Bildirim snapshot'ları. EGM'ye gönderilen her dosya, onu üreten tam kayıt setinin bildirim ID'sine anahtarlanmış kalıcı bir snapshot'ı ile birlikte gelir. Bu opsiyonel değildir. Aylar sonra "gerçekten ne sundunuz" sorusunu cevaplamanın tek yolu budur.
- Dönüşüm kodundan dışsallaştırılmış iş kuralları. Devlet katkısı hesaplaması, fon değişimi ve kısmi çekim mantığı, stored procedure'ler, ETL adımları ve raporlama sorguları arasında dağıtılmış değil — bir kural motorunda veya iyi versiyonlanmış bir kod artifact'ında yaşar.
- Tablo seviyesi değil, satır seviyesi soyağacı. Pipeline, her türetilmiş değer için hangi girdi satırlarının ve hangi kural versiyonunun onu ürettiğini kaydeder. Bu pahalıdır. Aynı zamanda regülatör sorularını gerçekten cevaplayan tek şeydir.
Bunu Geç Keşfetmenin Maliyeti
Soyağacını düzgün inşa ettiğini gördüğüm her firma, bunu acı verici bir regülatif olaydan sonra yaptı. Örüntü şudur: belirli bir soru gelir, ekip cevabı yeniden inşa etmek için altı hafta harcar, cevap çekincelerle teslim edilir, regülatör tam olarak tatmin olmaz ve yönetim nihayet yıllar önce yapılması gereken mimari çalışmayı yetkilendirir.
Olgun bir BES pipeline'ına soyağacını sonradan eklemenin maliyeti, en baştan inşa etmenin maliyetinin kabaca on katıdır. Teknoloji pahalı olduğu için değil — event sourcing ve bi-temporal modelleme iyi anlaşılmıştır — kritik hesaplamaları üretimde çalışırken, regülatif gözetim altında, geçiş sırasında yanlış olma iznine sahip olmadan yeniden yazdığınız için.
Soru Gelmeden Önce Ne Yapmalı
Eğer bir BES veri pipeline'ı yönetiyorsanız ve belirli bir katılımcının bakiyesini her dönüşüm boyunca kaynağa kadar şahsen izlememişseniz, bunu bu hafta yapın. Bir hesap seçin. Bakiyeyi yeniden inşa edin. Kendinizi süre tutun. Bir saatten fazla sürüyorsa veya üç kişiye sormak zorunda kalıyorsanız veya sonunda "yaklaşık olarak bu olmalı" diyorsanız, birisi sorduğu anda regülatif probleme dönüşecek bir soyağacı probleminiz var demektir.
Regülatör pipeline'ınızı size gösterdiğiniz çıktılara dayanarak onayladı. O çıktıları açıklayamamanızı onaylamadı. Bu ayrım oyunun tamamıdır.