BES Pipeline'larında Mevzuat Yorumu Problemi

Emeklilik şirketleri ve onların sigorta grubu ana ortakları için on yıl boyunca BES (Bireysel Emeklilik Sistemi) veri pipeline'ları kurduktan, gözden geçirdikten ve zaman zaman baştan inşa ettikten sonra, tek doğru çıktı efsanesine inanmayı bıraktım. Aynı ham katkı payı dosyalarıyla, aynı fon NAV'larıyla, aynı devlet katkısı kayıtlarıyla beslenen iki pipeline, katılımcı bakiyelerinde kuruş — bazen daha fazla — farklılık üretebilir ve her ikisi de EGM denetiminden geçebilir. Hiçbiri yanlış değildir. Sadece farklı mevzuat belirsizliklerini farklı biçimlerde çözmüşlerdir.

Satıcı sunumlarında kimsenin sizi uyarmadığı kısım işte budur.

Mevzuat, spesifikasyon değildir

BES ile ilgili mevzuat — Bireysel Emeklilik Tasarruf ve Yatırım Sistemi Kanunu, ilgili yönetmelikler ve EGM'nin dönemsel genelgeleri — size ne olması gerektiğini söyler. Nadiren tam olarak ne zaman, hangi sırayla veya hangi referans değere karşı olması gerektiğini söyler. Çalışan bir pipeline, metnin açık bıraktığı soruları yanıtlamak zorundadır:

• Bir katkı payı iş günü olmayan bir günde geldiğinde, T+0 NAV'ında mı, T+1 NAV'ında mı, yoksa bir sonraki fon değerleme tarihinde mi pay kazanır? Mevzuat "uygulanabilir fon fiyatı" der. Peki. Hangisinin uygulanabilir olduğu bir tasarım kararıdır.
• Bir katılımcının maaş kesintisi ile gönüllü ek katkısı aynı toplu dosyada geldiğinde, devlet katkısı birleşik tutar üzerinden mi yoksa kaynak bazında mı hesaplanır? Her iki okuma da denetimden geçer.
• Bir fon dağılım değişikliği talebi 15:59:30'da gelirse ve kesim saati 16:00 ise, talep bugünün NAV'ına mı yoksa yarınınkine mi uygulanır? Pipeline'ınız birini seçti. Kimse nedenini yazdı mı?
• Bir katılımcı ay ortasında çıkış yaptığında, devlet katkısı tahakkuku takvim günlerine göre mi, iş günlerine göre mi, yoksa katkı ağırlıklı günlere göre mi orantılanır?

Bunların her birinin savunulabilir bir yanıtı vardır. Her birinin en az bir başka savunulabilir yanıtı daha vardır. Ve eğer iki emeklilik şirketi 2015'te farklı seçimler yaptıysa ve bunu bir daha ele almadıysa, aynı varsayımsal veride katılımcı bakiyeleri kalıcı olarak ayrışacaktır.

Ayrışma aslında nereden geliyor

Yaptığım incelemelerde sayısal farklar neredeyse hiç bug'lardan gelmiyor. Bug'lar yakalanıyor. Farklar üç kaynaktan geliyor ve hepsi yorumsal:

Yuvarlama sınırları. Mevzuat, bakiyelerin belirli bir hassasiyette hesaplandığını söyler. Hangi adımda yuvarlanacağını her zaman söylemez. Pay alımında yuvarlayın, günlük değerlemede yuvarlayın, raporlamada yuvarlayın — üç farklı bakiye, hepsi yasal. Alımda payları 6 ondalığa yuvarlayan bir pipeline ile raporlamaya kadar 10 ondalık taşıyan bir pipeline üçüncü ayda ayrışacak ve aradaki fark açılacaktır.

Etkin tarih semantiği. "İşlem tarihi", "valör tarihi" ve "muhasebe tarihi" eş anlamlı değildir, ancak gereksinim dokümanlarında eş anlamlıymış gibi kullanılırlar. Katkı kaydı, fon dağılımı ve devlet katkısı tahakkukunun her biri bu üç tarihten farklı birini çıpa olarak seçtiğinde, iç tutarlılığı olan ama başka bir emsalinden dışsal olarak farklılaşan bir pipeline elde edersiniz.

Aynı gündeki işlem sırası. Bir katılımcı aynı valör tarihinde katkı payı yatırırsa, fon dağılımını değiştirirse ve devlet katkısı kaydı alırsa, sıralama önemlidir. Katkı → dağılım → devlet katkısı sıralaması, devlet katkısı → katkı → dağılım sıralamasından farklı bir pay adedi üretir. Mevzuat sıralama konusunda sessizdir. Pipeline'ınız sessiz değildir — sadece kimseye ne karar verdiğini söylemez.

Neden bu bir bug'dan daha kötü

Bir bug keşfedilebilir. Açıkça yanlış bir şey üretir: negatif bir bakiye, yasal üst sınırı aşan bir devlet katkısı, saklayıcıyla eşleşmeyen bir fon pay adedi. Mutabakat bunu yakalar. Biri bir JIRA ticket'ı açar. Düzeltilir.

Yorumsal bir seçim ise gayet makul bir şey üretir. Mutabakat geçer çünkü saklayıcı beslemesi ve pipeline'ınız uyuşmaktadır — aynı ekip tarafından, aynı varsayımlarla inşa edildiler. EGM'nin dönemsel raporlaması geçer çünkü toplam rakamlar iç tutarlıdır. Şu ana kadar her şey iyi görünür:

• Bir katılımcı başka bir emeklilik şirketine aktarım yapar ve alıcı şirketin pipeline'ı hak edişi kendi yorumuyla yeniden hesaplar. Rakamlar tutmaz. Şimdi birinin bu farkı açıklaması gerekir ve "biz farklı yuvarlıyoruz" 47 TL kaybeden bir müşteri için tatmin edici bir yanıt değildir.
• EGM, bir yorumu doğru olarak adlandıran açıklayıcı bir genelge yayımlar. Siz diğerini seçtiyseniz, artık yeniden ifade edilmesi gereken tarihsel bakiyeleriniz var — bazen yıllar öncesine gidiyor.
• Sigorta grubu ana ortağından bir iç denetçi, BES bakiyelerinizin saklayıcıyla mutabık olduğunu ama ham katkı dosyalarından yapılan basit bir yeniden hesaplamayla mutabık olmadığını sorar. Hiçbir zaman yazılmamış tasarım notu olmadan yanıt veremezsiniz.

Dokümantasyon açığı asıl risktir

Yaptığım her BES pipeline incelemesinde kod iyidir. SQL iyidir. Batch orkestrasyonu iyidir. Sürekli eksik olan şey şunu söyleyen bir dokümandır: "Bu adımda mevzuat A, B ve C yorumlarına izin verir. Biz B'yi seçtik. Nedeni şudur. Onaylayan kişi şudur. Tarih şudur."

Bu doküman olmadan on yıl içinde üç şey olur:

1. Orijinal mimarlar ayrılır. Yorum artık yalnızca kodda, hem de yalnızca örtük olarak gömülüdür.
2. Yeni bir gereksinim — diyelim ki devlet katkısı oranlarında bir değişiklik — orijinal yorumu davranıştan tersine mühendislikle çıkarmak zorunda kalan biri tarafından uygulanır. Yarı yarıya yanlış tahmin ederler.
3. EGM, X bakiyesinin neden o değer olduğunu sorduğunda, yanıt "sistem bunu üretti" olur ki bu bir yanıt değildir.

Gerçekten ne yapmalı

Bir BES pipeline'ına sahipseniz veya onu denetliyorsanız, faydalı egzersiz bir kod incelemesi daha yapmak değildir. Bir yorum denetimidir. Pipeline'ı yazan kişilerle (hâlâ oradalarsa) ve mevcut iş sahipleriyle oturun ve aşağıdakilerin her biri için yazılı bir yanıt zorlayın:

• Katkı tanınmasını hangi tarih alanı yönlendirir ve hangi NAV'a karşı?
• Aynı valör tarihinde birden fazla olay geldiğinde tam işlem sırası nedir?
• Yuvarlama nerede, hangi hassasiyette ve hangi yuvarlama modu ile gerçekleşir?
• Kısmi dönemlerde devlet katkısı tahakkuku nasıl hesaplanır?
• Kesim sınırındaki bir fon değişikliği talebine ne olur — dahil mi, hariç mi?
• Saklayıcının pay adedi ile pipeline'ın pay adedi bir eşiğin altında ayrıştığında hangisi geçerlidir?

Her yanıt için, dayandığınız mevzuat metnini alıntılayın, reddettiğiniz alternatif yorumları not edin ve kimin onayladığını kaydedin. Bu doküman EGM için değildir. Beş yıl sonra var olacak ekibiniz için, biri katılımcı 1057382'nin bakiyesinin neden o değer olduğunu sorduğunda içindir.

On yıllık mevzuat kaymasından sağ çıkan pipeline, en temiz koda sahip olan değildir. Yorumsal seçimleri savunulabilecek kadar okunaklı ve mevzuat sonunda yetiştiğinde değiştirilebilecek kadar spesifik olan pipeline'dır.