Üzerinde çalıştığım her BES boru hattı aynı sessiz izi taşıyor. Bordro dosyasının SFTP dizinine düşmesi ile katılımcının hesabında pay birimlerini görmesi arasında bir yerde, kimsenin yazıya dökmediği bir karar var: İşverenin dosyası kesim saatinden sonra geldiğinde hangi NAV üzerinden tahsis yapıyoruz?
Dürüst cevap, çoğu kurumun bunu bilmediğidir. Pragmatik cevap ise, yıllar önce bir seçim yapıp bunu bir stored procedure içine sabit kodladıkları ve o gün bugündür sonuçlarıyla yaşadıklarıdır.
İki Doğru Sistem, Bir Yapısal Boşluk
Bordro sistemleri işveren yükümlülükleri etrafında kurgulanmıştır. Ayın 25'inde döngüsünü işleten bir şirket, dosyayı İK bordroyu kapattığında keser; emeklilik fonunun saklama kuruluşu NAV vurduğunda değil. O dosya cuma günü 19:47'de düşebilir, bir batch retry'ın ardından pazartesi sabahı 04:12'de gelebilir ya da SAP job'ı kilitli bir tabloya takıldığı için salı öğleden sonrasını bulabilir.
Fon değerlemesi portföy fiyatlaması etrafında kurgulanmıştır. NAV sabit bir kesim saatinde vurulur — tipik olarak T iş günü sonu, saklama kuruluşu fiyatları teyit ettikten sonra T+1 sabahı yayımlanır. Esneklik yoktur. Kesim saati, birim fiyatını savunulabilir kılan şeydir.
Her iki sistem de kendi içinde doğrudur. Hiçbiri diğeri düşünülerek tasarlanmamıştır. Ve aralarındaki köprü — belirli bir ödemenin hangi değerleme tarihine ait olduğuna karar veren katkı yükleme katmanı — katılımcı hesabının bütünlüğünün tümüyle üzerinde durduğu noktadır.
Sessiz Varsayım
Denetlediğim uygulamaların çoğunda kural şu varyasyonların biridir:
- Dosya T gününde kesim saatinden önce ulaşırsa NAV(T) üzerinden tahsis edilir
- Kesim saatinden sonra ulaşırsa NAV(T+1) üzerinden tahsis edilir
Bu, "ulaşmak" kelimesinin ne anlama geldiğine bakana kadar makul görünür. SFTP'ye mi ulaşıyor? Staging tablosuna mı? Doğrulamayı mı geçiyor? Operasyon ekibinin, kayıtların %3'ü TCKN doğrulamasında başarısız olduğu için işlettiği manuel onay kuyruğunu mu temizliyor?
Bu kontrol noktalarının her biri, efektif tahsis tarihini bir ila üç iş günü kaydırabilir. Ve her kayma gerçek bir finansal olaydır: Katılımcı, pay birimi aldığını düşündüğü tarih ile gerçekten aldığı tarih arasındaki piyasa hareketini ya kazanır ya kaybeder.
Yükselen bir piyasada katılımcılar sessizce dezavantajlı duruma düşer. Düşen bir piyasada ise fon, üstlenmemesi gereken bir zararı emer. Bir yıl içinde bu, kimsenin açıklamak istemediği bir mutabakat satırına dönüşür.
Borcun Katlandığı Yer
Katlanma, uyumsuzluğun hiçbir zaman tam olarak giderilmemesinden kaynaklanır. Aylık katkı yatıran 4.000 çalışanı olan orta ölçekli bir işvereni düşünün:
-
- Ay: Bordro dosyası kesim saatinden 2 saat sonra ulaşır. T+1 NAV üzerinden tahsis edilir. Piyasa gecede +%0,4 hareket etmiştir. Katılımcılar taze bir katkı partisinde toplu olarak o %0,4'ün karşılığını "kaybederler".
-
- Ay: Dosya zamanında gelir, ancak 180 kayıt doğrulamada başarısız olur ve beklemeye alınır. Üç gün sonra farklı bir NAV üzerinden temizlenirler. Artık tek bir bordro döngüsü için iki tahsis tarihi vardır.
-
- Ay: Devlet katkısı orijinal katkı tarihi üzerinden hesaplanır, ancak pay birimleri daha sonraki bir tarihte tahsis edilmiştir. Devlet katkısı tahsis tarihi ile katkı tahsis tarihi artık örtüşmez.
Altıncı aya gelindiğinde operasyon ekibi manuel düzeltme scriptleri çalıştırıyordur. On ikinci ayda ise, kimsenin kapatmak istemediği bir suspense hesabı vardır; çünkü onu kapatmak bir rakam seçmek ve o rakamı savunmak demektir.
Kimsenin Belgelemediği Şeyler
Neredeyse her kurumda belgelenmemiş bulduğum konular:
- Tahsis motorunun kullandığı "ulaşma zamanı"nın kesin tanımı
- Tek bir bordro dosyasının birden fazla ödeme dönemine ait katkı içerdiğinde ortaya çıkan davranış
- Zaten vurulmuş NAV'lara karşı yapılan düzeltmelerin ve reversal işlemlerinin ele alınışı
- Katkı defteri ile pay birimi defteri arasında ayrışma olduğunda uygulanan mutabakat mantığı
- Manuel incelemenin tetiklendiği tolerans eşiği — ve bu eşiğin sahibinin kim olduğu
Bunların her biri bir politika kararıdır. Her biri şu anda üç yıl önce ayrılan biri tarafından yazılmış bir kod satırıdır.
Çözüm Teknik Değil
Mühendisler teknik çözümlere sarılır: daha iyi SLA izleme, daha sıkı kesim saati uygulaması, otomatik retry mantığı. Bunlar marjda yardımcı olur, ancak altta yatan sorunu çözmezler: Kimse tahsis politikasının ne olduğuna resmi olarak karar vermemiştir.
Çözüm şunları gerektirir:
- Finans, operasyon ve compliance tarafından imzalanmış — IT tarafından değil — yazılı bir katkı tahsis politikası
- Tahsisi yöneten timestamp'in açık bir tanımı ve kayıt sisteminin (system of record) spesifik olarak adlandırılması
- Geç ulaşan dosyalar, başarısız doğrulamalar ve çok dönemli dosyalar için belgelenmiş bir işleyiş prosedürü
- Takvim kolaylığına değil, riske uygun bir mutabakat kadansı
- Tahsis edilmemiş bir katkının azami yaşını tanımlayan bir suspense hesabı politikası
Bunlar var olduğunda teknik uygulama basit hale gelir. Bunlar olmadan her kod değişikliği, birinin tahminini yeniden kodlamaktan öteye geçmez.
Denetçi Sorusu
Müşterilerimle kullandığım test basit. Onlardan altı ay öncesinden rastgele bir katkı seçmelerini ve şunları benimle birlikte adım adım gözden geçirmelerini istiyorum:
- Ne zaman ulaştığını
- Hangi NAV üzerinden tahsis edildiğini
- Yazılı politikaya göre o NAV'ın neden doğru NAV olduğunu
- Devlet katkısı tahsis tarihinin nasıl belirlendiğini
- Katkı defteri ile pay birimi defteri arasındaki mutabakatın nerede durduğunu
Bu cevaplardan herhangi biri belirli bir kişiye telefon açmayı gerektiriyorsa, boru hattının bir mutabakat borcu vardır. Henüz yüzeye çıkmamış olabilir. Çıkacaktır.
Bunu iyi yöneten kurumlar, en iyi teknolojiye sahip olanlar değildir. Onlar, bordro-NAV köprüsünü önce bir politika problemi, sonra bir mühendislik problemi olarak ele alanlardır. Geri kalan herkes, artık savunmak için orada olmayan birinin SQL'e yazdığı varsayımların üzerinde ilerlemektedir.