Regülasyon Bildirim Gecikmesi Sorunu: BES Pipeline'ları Neden Sürekli Değişmekte Olan Kurallara Göre Kalibre Ediliyor?

Türkiye'deki her BES ekibi bu ayın bir versiyonunu yaşamıştır. Cuma günü EGM veya SEDDK'dan bir sirküler düşer. Devlet katkısı uygunluk kuralını netleştirir, bir raporlama alanını düzenler ya da belirli bir katılımcı statüsünün aylık kesim için nasıl sınıflandırılması gerektiğini yeniden yorumlar. Yürürlük tarihi bir sonraki raporlama dönemidir. Bildirimin içine gömülü varsayım şudur: küçük bir yapılandırma değişikliği yapıp yolunuza devam edeceksiniz.

Ama değişiklik bir yapılandırma değişikliği değildir. Bir pipeline değişikliğidir. Ve bu boşluk — regülatörün uygulamayı nasıl hayal ettiği ile gerçek bir veri platformu işleten bir firmada uygulamanın nasıl çalıştığı arasındaki boşluk — Türk emeklilik operasyonlarındaki operasyonel acının çoğunun geldiği yerdir.

Gecikme İdari Değil, Yapısaldır

Sektör dışındaki insanlar regülasyon gecikmesinin yavaş hukuki inceleme veya bürokratik onay meselesi olduğunu düşünme eğilimindedir. İlginç kısım bu değil. İlginç kısım şu: BES pipeline'larının çoğu, regülasyon mantığı doğrudan dönüşüm koduna, saklı yordamlara ya da daha kötüsü, beş yıl önce şu anda firmadan ayrılmış biri tarafından yazılmış ETL işlerinin içindeki sabit kodlanmış eşiklere gömülü şekilde inşa edildi.

Bir sirküler, uygun katkı penceresinin tanımını 30 günden 45 güne değiştirdiğinde, tipik bir pipeline'da üç şey olur:

• Bir saklı yordamın içine gömülmüş uygunluk kontrolünün bulunup değiştirilmesi gerekir
• Eski kural altında çalışmış geçmiş hesaplamalar, denetimlerin patlamaması için artık bir sürümleme hikâyesine ihtiyaç duyar
• Eski mantıkla toplulaştırılmış aşağı akış raporları, geçiş dönemi için mutabakat gerektirir

Bunların hiçbiri yapılandırma değil. Bu; kod, test, deployment ve mutabakat. Ve tüm bunları, ay sonu raporlaması hâlâ çalışırken iki haftalık bir pencerede yapmanız isteniyor.

Başa Çıkabilen Firmalardaki Örüntü

Sigorta ve emeklilik operasyonlarında bu döngülerin onlarcasını izledikten sonra, kriz moduna girmeyen firmaların tek bir mimari kararı paylaştığını görüyorum: her regülasyon varsayımını, mantığın içindeki bir sabit olarak değil, pipeline'a açık ve sürümlenmiş bir girdi olarak ele alıyorlar.

Somut olarak bu şöyle görünür:

• Her eşik, pencere, oran ve sınıflandırma kuralının effective_from ve effective_to tarihleriyle bir satır olarak yaşadığı bir regulatory_parameters tablosu (veya config deposu)
• Bu parametreleri güncel tarihe göre değil, işlenen raporlama dönemine göre çalışma zamanında okuyan pipeline mantığı
• Parametre olarak ifade edilemeyecek kadar karmaşık mantık için ayrı bir regulatory_rulesets sürümleme katmanı — uygunluk ağaçları, devlet katkısı hesaplama formülleri, çıkış nedeni sınıflandırmaları
• Herhangi bir geçmiş dönemi, o dönemde geçerli olan ruleset altında yeniden çalıştırabilecek reprocessing yeteneği

Yazıya döküldüğünde apaçık görünüyor. BES pipeline'larının çoğu böyle görünmüyor.

Somut Bir Örnek

Devlet katkısı uygunluğunu ele alalım. Temel kural basittir: çalışan katkılarına %25 eşleşme, yıllık üst sınırlara ve katılım süresine bağlı hak ediş takvimlerine tabi. Yıllar içinde parametreler değişti — üst sınır tutarları, hak ediş aralıkları, aktif katkı ayı olarak neyin sayılacağının tanımları, kısmi yıl çıkışlarının işlenişi.

Kötü tasarlanmış bir pipeline'da şunu bulursunuz:

CASE WHEN participation_months >= 36 THEN contribution * 0.25 ...

yedi farklı prosedüre serpiştirilmiş halde. Hak ediş aralığı tanımı değiştiğinde arkeoloji yapıyorsunuz demektir.

İyi tasarlanmış bir pipeline'da aynı mantık şöyle görünür:

JOIN vesting_rules v ON v.effective_from <= reporting_period 
  AND v.effective_to > reporting_period
  AND participation_months BETWEEN v.min_months AND v.max_months

Sirküler geldiğinde yeni satırlar eklersiniz. Koda dokunmazsınız. Yeniden deploy etmezsiniz. Dönüşüm mantığını yeniden test etmezsiniz — parametre yükleyicisini bir kez test edip sonsuza dek güvenirsiniz.

Bu Neden Baştan İnşa Edilmiyor

Pipeline'ların çoğunun bu şekilde inşa edilmemesinin nedeni şu: bir BES platformuna başlarken regülasyon çerçevesi stabil hissettirir. Mevcut kurallara sahipsiniz. Onları kodlarsınız. Yayına alırsınız. Dört yıl içinde yirmi üç sirküler, altı parametre revizyonu ve iki yapısal yeniden yorumlama sindirmiş olacağınız fikri, gerçekleşene kadar gerçek hissettirmez.

O noktaya geldiğinizde, eski mantıkla hesaplanmış üretim veriniz, o hesaplamaları tüketen aşağı akış sistemleriniz ve geçmiş sonuçları birebir yeniden üretme yönünde denetim yükümlülükleriniz vardır. Sürümlenmiş parametre mimarisine refactor etmek, feature çalışmasıyla rekabet eden ve asla kazanamayan çok çeyreklik bir projeye dönüşür.

Sonuç: pipeline kırılgan kalır ve her sirküler bir yangın tatbikatına döner.

Aslında Ne Yapmalı

Hâlâ inşa aşamasındaysanız, aşırı mühendislik gibi hissetse bile regülasyon varsayımlarını şimdi izole edin. Her eşik bir config girdisi alır. Her sınıflandırma kuralı, yürürlük tarihleriyle bir lookup tablosu alır. Her hesaplama, parametrelerini işlenen döneme göre okur.

Zaten kırılgan durumdaysanız, her şeyi bir kerede refactor etmeye çalışmayın. En sık değişen parametreleri — genellikle uygunluk pencereleri, katkı üst sınırları ve raporlama alan tanımları — seçin ve önce onları çıkarın. Çalışmanın ilk %20'sinden faydanın çoğunu alacaksınız.

Ve regülasyon yanıt kapasitenizi bir hotfix'i ne kadar hızlı gönderebildiğinizle ölçmeyi bırakın. Döngü ortasındaki bir değişikliği pipeline koduna hiç dokunmadan sindirip sindiremediğinizle ölçün. Gerçek çıta budur. Bu çıtaya ulaşan firmalar, sirkülerler düştüğünde kriz yaşamaz. Sıradan bir Salı günü geçirirler.