Üzerinde çalıştığım her BES platformu, fon değişikliğini rutin bir özellik olarak ele alır. Katılımcı yeni bir dağılım seçer, onaylar tuşuna basar ve arayüz "talebiniz alınmıştır" der. Bu onayın altında, tüm emeklilik ürününün en kırılgan boru hatlarından biri yatar ve çoğu operasyon ekibi bu kırılganlığı ancak düzenleyiciye açıklayamayacakları bir tutar için mutabakat bozulduğunda fark eder.
Bu bir hesaplama sorunu değildir. Fon değişikliği matematiği basittir: A fonundaki birimleri NAV_A üzerinden sat, B fonundaki birimleri NAV_B üzerinden al, yuvarlamaya dikkat et. Sorun sıralamadadır — ve sıralama tam olarak canlıya alındıktan sonra kimsenin tekrar gözden geçirmediği şeydir.
Üretim ortamında fon değişikliği gerçekte nedir
Katılımcı tarafından başlatılan tek bir fon değişikliği tek bir işlem değildir. Genellikle şunlara dokunan bir zincirdir:
- Katılımcı portalı (talep)
- Poliçe yönetim sistemi (sözleşme durumu)
- Portföy şirketindeki fon muhasebe sistemi (EGM)
- Birim takası için Takasbank
- NAV yayın döngüsü (uygulamada çoğu fon için T+1)
- Günü kapatan mutabakat motoru
Her birinin kendi kesim saati, kendi saati ve kendi "bugün" tanımı vardır. Fon değişikliği yalnızca altısı da hemfikir olduğunda çalışır. Nadiren hemfikir olurlar.
Sessizce başarısız olan üç sıralama varsayımı
Bu boru hattının yıllarca sahibi olduktan sonra, aynı üç varsayım defalarca başarısız oluyor ve hiçbiri herhangi bir tasarım belgesinde yok.
Varsayım 1: Katkı payı ile değişiklik çakışmayacak.
Klasik kırılma. Bir katılımcı saat 14:30'da fon değişikliği gönderir. İşverenin bordro dosyasından bir katkı payı, 17:00 NAV kesim saatinden önce, 15:10'da düşer. Değişiklik, katkı öncesi birim bakiyesine karşı kuyruğa alınmıştı. Katkı payı eski dağılımda birim satın alır. Şimdi değişiklik, katılımcının gördüğüyle artık eşleşmeyen bir bakiyeye karşı yürütülür ve yeni katkı, katılımcının kırk dakika önce açıkça uzaklaştığı bir fonda kalır.
Temiz bir geri alma yoktur. Dünkü NAV üzerinden birimleri "geri alamazsınız". Ya spread'i yutarsınız, ya yarın farklı bir NAV üzerinden düzeltici bir değişiklik yaparsınız (ikinci bir tutarsızlık yaratarak) ya da katılımcıyla çok rahatsız edici bir konuşma yaparsınız.
Varsayım 2: NAV kesim saatleri fonlar arasında uyumludur.
Değildirler. Aynı BES planı içindeki yurt içi hisse senedi fonu, Eurobond fonu ve altın fonu farklı etkili kesim saatlerine sahip olabilir çünkü altta yatan enstrümanlar farklı borsalarda ve zaman dilimlerinde fiyatlanır. 16:45'te gönderilen TRY para piyasası fonundan USD cinsi bir fona yapılan bir değişiklik, satış bacağını bugün ve alış bacağını yarın yürütebilir. Bir iş günü boyunca katılımcı nakitte kalır, FX hareketine maruz kalır ve seçtiği hiçbir şeye yatırım yapmamış olur.
Bu, ön uçta hiçbir yerde belgelenmez. Arayüz tek bir onay gösterir.
Varsayım 3: EGM mutabakat penceresi, hatalar birikmeden yakalayacaktır.
Mutabakat gün sonudur. Fon değişiklikleri gün içidir. Değişiklik 14:30'da kırılırsa ve mutabakat 22:00'da çalışırsa, katılımcıya yedi buçuk saat boyunca B fonunda olduğu söylenmiş olur ancak birimleri hâlâ A fonundadır — ya da daha kötüsü, satışın yürütüldüğü ama alışın yürütülmediği yarı durumda kalır. Bu pencere sırasında herhangi bir şey bakiyeyi sorgularsa (bir bakiye sorgusu, kısmi çekim talebi, başka bir değişiklik), tutarsız veriler üzerinde çalışır ve tutarsız veriler geri yazar.
Standart geri alma neden işe yaramaz
Çoğu kurumsal sistemde, başarısız çok adımlı bir işlem telafi edici bir eylemi tetikler. Bu model, adımların geri alınabilir olduğunu varsayar. Fon değişiklikleri geri alınabilir değildir. Birimler bugünün NAV'ı üzerinden satıldığında ve bu NAV yayınlandığında, olmamış gibi davranamazsınız. Portföy şirketi piyasada işlem yapmıştır. Takasbank takas etmiştir. Mevcut tek "geri alma", yeni bir NAV üzerinden yeni bir ileri işlemdir; bu da fiyat farkını garanti eder, bu da bir yere — genellikle emeklilik şirketine, bazen katılımcıya, her zaman rahatsız edici biçimde — yansıması gereken bir P&L etkisini garanti eder.
Mimarlar fon değişikliği akışını "nihai tutarlı" olarak tanımladığında bu yüzden itiraz ederim. Nihai tutarlı değildir. Herhangi bir bacak izole olarak yürütüldüğü anda kalıcı olarak tutarsızdır.
Gerçekte ne için tasarım yapılmalı
Deneyimden işe yarayan kontroller:
- Bir değişiklik gönderildiği anda katılımcı bakiyesinde sert dondurma. Birinci değişiklik tam olarak temizlenene kadar bu bakiyeye karşı hiçbir katkı, çekim veya ikinci değişiklik yürütülemez. Bu, bordro ekiplerini hayal kırıklığına uğratır. Yine de yapın.
- Fon başına değil, değişiklik başına tek bir etkili kesim saati. Değişikliğin herhangi bir bacağı bugünün NAV'ı üzerinden yürütülemiyorsa, tüm değişiklik bir sonraki iş gününe ertelenir. Fon düzeyinde değil, katılımcı düzeyinde atomik.
- Gün içi mutabakat kontrol noktaları, gün sonu değil. En azından aktif değişikliklere dahil her fonun NAV kesim saatinden sonra.
- Arayüzde açık bir bekleyen durum. Değişiklik kuyruğa alındığında katılımcılara bittiğini söylemeyi bırakın. "Gönderildi, [tarih] NAV'ında yürütülecek" daha kötü bir kullanıcı deneyimi değildir. Dürüst bir deneyimdir ve bir şey kaydığında şikayet hacmini önemli ölçüde azaltır.
- Belgelenmiş bir tutarsızlık emilim politikası, lansman öncesinde finans tarafından imzalanmış olmalı, ilk olay sırasında operasyon tarafından doğaçlama yapılmamalı.
Gözden kaçan kısım
Bunların hiçbiri teknik olarak zor değildir. Mühendislik düz ileridir. Zor olan, ürün ve operasyon paydaşlarını rutin olarak gördükleri bir özelliğin, üretim ortamında, paylaşılan bir saati ve küresel bir geri alması olmayan dört kurum arasında dağıtılmış bir işlem olduğuna ikna etmektir. Bu konuşma tasarım zamanında olmalıdır. Neredeyse hiç olmaz, çünkü fon değişikliği ekranı maketinde çok basit görünür.
BES'teki operasyonel risk karmaşık görünen ürünlerde değildir. Basit görünen ve günde binlerce kez, kimsenin uçtan uca sahibi olmadığı bir boru hattı üzerinde çalışanlardadır.