Fon Kapanış Problemi: BES'te Bir Yatırım Seçeneğini Sonlandırmak Neden Pipeline'ınızın Döngü Ortasında Emmek Zorunda Kalacağı En Yıkıcı Olaydır

Devraldığım her BES pipeline'ı, fon yaşam döngüsünü simetrik bir şey olarak ele alır. Yeni bir fon çıkar, ürün master tablosuna bir satır eklersiniz, NAV feed'ini genişletirsiniz, ilk alım emirlerini kabul edersiniz. Fon kaybolduğunda ise aynı işlemin aynadaki karşılığının geçerli olacağını varsayarsınız. Öyle değildir. Kapanış, açılışın tersi değildir — temelde farklı bir olay sınıfıdır ve onboarding'in mutlu senaryosu etrafında tasarlanmış pipeline'lar, genellikle bir HAYMER mutabakatı veya EGM denetimi sırasında haftalar sonra yüzeye çıkacak şekilde çatlar.

Bir Fon Kapandığında Aslında Ne Olur

Portföy yönetim şirketi bir fonu kapatmaya veya birleştirmeye karar verdiğinde — ki bu, ürün ekiplerinin kabul ettiğinden çok daha sık olur, özellikle 50M TL AUM altındaki ölçekaltı fonlarda — pipeline'ınıza asla modellemesi istenmemiş bir olay dizisi tetiklenir:

• Fon, SPK bildiriminden gelen bir kapanış tarihi alır, genellikle 30 gün sonrası.
• Pay tutan her katılımcı, bildirim penceresi sırasında katılımcının seçtiği veya sözleşme kurallarına göre varsayılan olarak atanan bir hedef fona zorunlu olarak geçirilmelidir.
• Son NAV yayınlanır ve ardından ISIN emekliye ayrılır.
• Fon kodu tarihsel tablolarınızda sonsuza kadar kalır, ancak artık hiçbir canlı feed'e karşılık gelmez.
• Kapanan fonun tarihsel pozisyonlarına atıfta bulunan her HAYMER gönderimi, her GEV dosyası, her EGM raporu — yasal olarak artık var olmayan bir ürüne karşı — hâlâ mutabık olmak zorundadır.

Çoğu pipeline'ın sessizce başarısız olduğu nokta işte bu son maddedir.

Dangling Pointer Problemi

NAV tablonuzun fon master tablosuna bir foreign key'i vardır. Pozisyon tablonuzun NAV tablosuna bir foreign key'i vardır. Günlük değerlemeniz her ikisi üzerinde join yapar. Bir fon kapandığında, naif yaklaşım satırı is_active = 0 olarak işaretleyip yola devam etmektir. Ertesi sabah günlük iş çalışır ve o fona bir zamanlar dokunmuş her tarihsel pozisyon, artık ORM'nizin varsayılan olarak filtrelediği bir satıra join yapar.

Bu tam bu bug'ı farklı BES operatörlerinde üç kez production'da gördüm. Semptomlar her seferinde aynıdır:

• Yıllar önce kapanmış fonu tutmuş katılımcılar için tarihsel performans raporlarında ani boşluklar görünür.
• Mutabakat toplamları rastgele görünen tutarlarda sapar; ta ki tek bir emekli ISIN'e kadar izini sürene kadar.
• HAYMER gönderimi format doğrulamasından geçer ama çapraz kontrolde başarısız olur, çünkü toplu pozisyon raporu, düzenleyicinin kendi master'ında artık bulunmayan bir fon kodu altındaki paylara atıfta bulunur.

Düzeltme mimaridir, taktiksel değil. Kapanan fonlar, farklı bir yaşam döngüsü durumuyla — closed_pending_switch, closed_reconciling, closed_archived — birinci sınıf varlıklar olarak sorgulanabilir kalmalıdır ve her downstream join, sorgu tarihinde değil, raporlama tarihinde hangi durumun geçerli olduğunun farkında olmalıdır.

Zorunlu Geçiş: Pozisyon Ledger'ınızın Tasarlanmadığı Olay

Zorunlu geçiş, katılımcı tarafından başlatılan bir işlem değildir. İmzalı bir talimatı, bir menşe kanalı, denetim izinde bir kullanıcı kimliği yoktur. Operatörün binlerce katılımcı adına eş zamanlı olarak yürüttüğü toplu bir işlemdir ve çoğu eski ledger'da bulunmayan bir işlem tipiyle kaydedilmelidir.

Üzerinde çalıştığım bir migrasyonda, kaynak sistem 12 yıllık zorunlu geçişi, SYSTEM sentetik kullanıcı ID'siyle sıradan FON_DEGISIM işlemleri olarak kaydetmişti. Bu, bir şikayet incelemesi için katılımcının gerçek tercih geçmişini yeniden oluşturmaya çalışana kadar zararsız görünüyordu. Katılımcının talep ettiği bir geçişi, fon kapanışının dayattığı bir geçişten ayırt etmenin yolu yoktu. Düzenleyici ayırt eder, arayan katılımcı da ayırt eder.

İşlem tipini birinci günden itibaren tasarlayın:

• Kapanış karar belgesine zorunlu bir referansla FORCED_SWITCH_CLOSURE.
• Hedef fon seçim yöntemi: bildirim penceresi sırasında katılımcı tarafından seçilen, varsayılan olarak uygulanan veya birleşme maddesine göre taşınan.
• Geçiş için kullanılan NAV — ki bu kapanış NAV'ıdır, işlem tarihi NAV'ı değil.

HAYMER ve GEV: Artık Var Olmayan Bir Ürüne Karşı Mutabakat

Pipeline yükünün katlanarak arttığı yer burasıdır. HAYMER gönderimleri kümülatiftir — raporlama tarihlerindeki tarihsel pozisyonlara atıfta bulunur. Bir katılımcı önceki yılın 31 Aralık'ında Fon A'yı tutuyorduysa ve Fon A cari yılın Mart'ında kapandıysa, cari yıl için yıl sonu HAYMER'iniz devir hesaplamalarını, transfer geçmişlerini ve getiri atıflarını hesaplarken hâlâ Fon A'ya referans vermek zorundadır.

GEV raporlaması daha kötüdür çünkü ürün granülaritesinde çalışır. Bir fonun ISIN'i emekliye ayrıldığı an, geçen çeyrek geçerli olan GEV şablonları o satırı reddeder. Artık tarihsel veriyi kullanımdan kaldırılmış bir ürün kodu altında göndermek zorundasınız ve alıcı taraftaki doğrulama mantığı, EGM'nin master'ını en son ne zaman güncellediğine bağlı olarak buna uyum sağlayabilir veya sağlamayabilir.

Gerçekten işe yarayan pratik önlemler:

• Tek bir canlı master yerine, her raporlama dönemine tarihlenmiş paralel bir fon master snapshot'ı tutun.
• HAYMER veya GEV'in dokunduğu her referans tablosunu versiyonlayın ve gönderim işinin raporlama tarihinde geçerli olan versiyona pin'lenmesine izin verin.
• Master'dan asla bir fonu silmeyin. Asla. Kapanış metadata'sı ekleyin ve satırı dondurun.

Katılımcı Düzeyindeki Sonuçlar

Operasyonel başarısızlıklar görünürdür. Katılımcı düzeyindeki başarısızlıklar daha sessizdir ve yüzeye çıkması daha uzun sürer. Altı yıl boyunca kapanmış bir fonu tutmuş bir katılımcı, gelecekte bir noktada o dönemi kapsayan bir hesap özeti isteyecektir. Ekstre motorunuz kapanan fonu tarihsel NAV'ları, kapanış bildirimi ve ardından gelen geçişle birlikte render edemiyorsa, bir çağrı merkezi problemi ve nihayetinde SPK'ya ulaşan bir şikayetle karşı karşıya kalacaksınız.

Ekstre motorunun şunu söyleyebilmesi gerekir: bu tarihte, bu tarihte kapanan bir fondan X pay tutuyordunuz, bu NAV'da şu fona geçirildiniz ve her ikisi boyunca kesintisiz performans hattı burada. Bunu, kapanışı bir delete olarak ele alan bir pipeline'dan sonradan inşa etmek muazzam pahalıdır.

İhtiyaç Duymadan Önce Ne İnşa Etmelisiniz

Bugün bir BES pipeline'ı tasarlıyorsanız veya bir tanesini refactor ediyorsanız, fon kapanışını fon açılışına verdiğiniz aynı tasarım dikkatiyle birinci sınıf bir olay olarak ele alın:

• SPK bildirimini, katılımcı bildirim penceresini, zorunlu geçiş yürütmesini ve kapanış sonrası arşivleme durumunu kapsayan bir kapanış workflow'u.
• Bir soft-delete bayrağının maskelenmesi olarak değil, gerçek yaşam döngüsü durumuna sahip değiştirilemez tarihsel fon kayıtları.
• Canlı master'lara değil, tarih-geçerli referans snapshot'larına pin'lenen regülasyon gönderim işleri.
• Regülasyon menşei olan özel bir zorunlu geçiş işlem tipi.
• Kapanan fonları geçerli tarihsel varlıklar olarak ele alan ekstre render'ı.

Fon açılışı bir satır insert'idir. Fon kapanışı, platformunuzun her katmanına dokunan, aylar süren takvim zamanına yayılan ve göndereceğiniz her regülasyon dosyasında kalıcı izler bırakan dağıtık bir işlemdir. Bunu iyi ele alan pipeline'lar, çok uzun zaman önce simetri varsaymayı bırakmış olanlardır.