Emeklilik operasyonlarında herkes, NAV hesaplamasını günün en yüksek riskli olayı olarak görür. Fon muhasebesi ekibi fiyatlamayı iki kez kontrol eder, saklamacı pozisyonları teyit eder, denetçi metodolojiyi onaylar. Saat 18:00'de NAV yayımlanır ve oda bir nefes alır.
O nefes erkendir. NAV doğrudur. Asıl risk bundan sonra olanda yaşar — tek bir fon seviyesindeki sayının milyonlarca katılımcı bakiyesine çevrilmesinde — ve bu süreç neredeyse hiçbir zaman aynı titizlikle denetlenmez.
Milyonlarca katılımcısı olan bireysel emeklilik sistemlerinde bu hattı üretimde yıllarca işlettim. Gördüğüm hatalar neredeyse hiç NAV'ın kendisinde değildi. Fon ile defter arasındaki katmandaydı.
Sahibi Olmayan Çeviri Katmanı
NAV'ın sahibi fon muhasebesidir. Bakiyelerin sahibi katılımcı yönetimidir. Aralarındaki hat ise IT'ye aittir, kimse tarafından yönetilmez ve yalnızca istisna durumlarda test edilir.
Bu hat, sırasıyla birkaç iş yapar:
- Fon muhasebesinden günlük birim NAV'ı alır
- Bir kesim saati itibarıyla her katılımcının birim varlığına uygular
- Gün içinde gelen katkı ve çıkışları işler
- Yuvarlama kurallarına göre kesirli birimleri tahsis eder
- Ortaya çıkan bakiyeyi katılımcı defterine yazar
- Aşağı akış sistemlerini besler: web portalı, SMS bildirimleri, mevzuat raporları, vergi kesintisi
Her adımın varsayımları vardır. Her varsayım kayabilir. Ve toplamlar genellikle birkaç kuruş içinde mutabık kaldığı için hiçbir uyarı tetiklenmez.
Sapma Nerede Saklanır
Zamanlama kesim saatleri. Fon muhasebesi, NAV'ı T+0 değerleme görüntüsüne dayanarak hesaplar. Katılımcı yönetimi ise bunu farklı bir kesim saatine göre birim bakiyelerine uygular — bazen T+0 23:59, bazen T-1 iş günü kapanışı, bazen toplu işin ne zaman çalıştığına bağlı olarak. 17:45'te kaydedilen bir katkı, bir sistemde bugünkü NAV'la, diğerinde yarınki NAV'la değerlenebilir. Sakin bir piyasada kimse fark etmez. Fonun %3 hareket ettiği bir günde ise elinizde bir şikayet kuyruğu olur.
Yuvarlama asimetrisi. NAV dört veya altı ondalık basamağa yayımlanır. Katılımcı birimleri farklı bir hassasiyette saklanır. Bakiyeler iki ondalıkla gösterilir. Yuvarlama kuralınız bir adımda "yarıyı yukarı yuvarla", başka bir adımda "bankacı yuvarlaması" ise artıklar birikir. Katılımcı bakiyeleri toplamının, fon NAV × toplam birim değerinden bir çeyrekte on binlerce lira saptığı fonlar gördüm — tamamen uygulama sırasında "onaylanmış" ve bir daha hiç gözden geçirilmemiş yuvarlama mantığı yüzünden.
Tahsis sırası. Bir katkı, bir fon kurumsal aksiyonuyla aynı gün gelirse — bir komisyon tahakkuku, bir dağıtım, bir fon bölünmesi — bu olayları bir katılımcıya uygulama sırası, nihai birim sayısını belirler. Fon muhasebesi bunları fon seviyesinde bir sırayla uygular. Katılımcı motoru ise katılımcı seviyesinde, çoğu zaman farklı bir sırayla uygular.
Geriye dönük düzeltmeler. Saklamacı T-3 için bir fiyat düzeltmesi gönderir. Fon muhasebesi NAV'ı yeniden yayımlar. Artık T-3, T-2, T-1 ve T'de o fona dokunan her katılımcı işleminin yeniden değerlenmesi gerekir. Çoğu sistem bunu yapar. Bazıları sessizce yapar. Bazıları kısmen yapar. Bazıları defterler için yapar ama düzenleyicilere gönderilmiş ya da portalda katılımcıya gösterilmiş veri için yapmaz.
Sessiz Hata Modu
Hata neredeyse hiçbir zaman "rakamlar yanlış" değildir. Hata, "rakamlar kime sorulduğuna göre farklı hikayeler anlatır" şeklindedir.
Bir katılımcı çağrı merkezini arar: bakiye X'tir. Temsilci yönetim sistemine bakar: bakiye X + 0,42'dir. Mobil uygulama X - 1,15 gösterir. Bir anlık görüntüden üretilen yıllık ekstre başka bir şey gösterir. Her sayı kendi içinde tutarlıdır. Hiçbiri gerçek zamanlı olarak birbiriyle mutabakat içinde değildir.
Bir projede, katılımcı portalının kaynak veritabanını takip eden bir replika veritabanından okuduğunu, bunun da yoğun toplu iş pencerelerinde 90 dakikaya kadar geciktiğini tespit ettik. Normal günlerde önemsiz. NAV hesaplama gününde, 19:30'da giriş yapan bir katılımcı dünün bakiyesini bugünün tarih damgasıyla görüyordu. Hukuki açıdan tartışmalı. Operasyonel olarak görünmez.
Aslında İşe Yarayan Şeyler
Yeterince olay yaşandıktan sonra, geceleri rahat uyuyabilen emeklilik operasyonlarını uyuyamayanlardan ayıran birkaç uygulama vardır:
- Her gün üç seviyede mutabakat yapın. Fon NAV × toplam birim, tanımlı bir tolerans dahilinde katılımcı bakiyeleri toplamına her gün eşit olmalı. Aylık değil. Yıl sonu değil. Her gün, tolerans aşıldığında otomatik uyarı ile ve bunu bir insanın onaylamak zorunda kalmasıyla.
- Yuvarlama ve tahsis kurallarını dokümanlarda değil, kodda sürümleyin. Tahsis mantığınız 2014'ten kalma bir Word dosyasında yaşıyorsa, sisteminizin ne yaptığını bilmiyorsunuz demektir. Ne yapması gerektiğini biliyorsunuz.
- Çeviri katmanını düzenlenmiş bir sistem olarak ele alın. NAV hesaplamasıyla aynı değişiklik kontrolü. Aynı test titizliği. Aynı denetim izi. Şu anda genellikle bunların hiçbiri yok.
- Herhangi bir zaman damgası itibarıyla katılımcı bakiyesi için tek bir doğruluk kaynağı oluşturun. Her aşağı akış sistemi oradan okur. Replika yok, sapan önbellek yok, "portalın kendi mantığı var" yok.
- Geriye dönük düzeltme yolunu üç ayda bir test edin. Üretim dışı bir ortama geriye dönük bir fiyat düzeltmesi enjekte edin ve aşağı akıştaki her çıktının doğru güncellendiğini doğrulayın. Gördüğüm en yaygın üretim olayı budur ve en az test edilen kod yolu da budur.
Rahatsız Edici Kısım
Piyasadaki çoğu emeklilik yönetim platformu — ölçekli olarak çalıştığım bazıları dahil — günlük NAV'ın bir lüks olduğu ve katılımcıların bakiyeyi üç ayda bir posta ile kontrol ettiği dönemde tasarlandı. Çeviri katmanı, on yıl boyunca farklı ekipler tarafından parça parça eklendi. Çalışıyor, çünkü matematik çoğunlukla çalışıyor; tasarlandığı için değil.
Düzenleyiciler daha iyi sorular sormaya başlıyor. Katılımcıların artık uygulamaları var ve tutarsızlıkları saatler içinde fark ediyorlar. "Genellikle mutabık kalıyor" toleransı hızla daralıyor.
NAV hesaplama günü, NAV yanlış olabilir diye tehlikeli değildir. Tehlikelidir, çünkü ondan sonra olan her şey, kimsenin yıllardır denetlemediği varsayımlar üzerinde çalışır.