Son on yılda incelediğim her BES veri ambarının aynı kör noktası var. Pipeline'lar sürekliliği varsayıyor. Tablolar yerinde güncelleniyor, düzeltmeler önceki durumların üzerine yazıyor, mutabakat kayıtları mutabakatını yaptığı operasyonel veriyle aynı veritabanında yaşıyor ve varsayım şu: eğer bir düzenleyici veya denetçi önümüzdeki salı bir soru sorarsa, operasyondan biri sisteme girip ne olduğunu açıklayacak.
Bu varsayım, iflas resme girdiği anda çöker.
Bir emeklilik şirketi battığında ve BES katılımcı koruması için Güvence Hesabı devreye girdiğinde, garanti fonu batan şirketten verisini açıklamasını istemez. Veriyi alır. Ve bunu, doğruluğun "en iyi çaba" metriği olmadığı — katılımcıların ödeme alıp almayacağının temeli olduğu — yasal koşullar altında alır.
Güvence Hesabı Gerçekte Neye İhtiyaç Duyar
Yükümlülük "bize bir database dump gönderin" değildir. Yükümlülük, her katılımcının pozisyonunun belirli bir zaman noktasındaki yeniden yapılandırılmış halini teslim etmektir; bu şu özelliklere sahip olmalıdır:
- Hukuki olarak savunulabilir — her katılımcı bakiyesi; belirli katkı olaylarına, fon payı tahsislerine, devlet katkısı tahakkuklarına ve kesintilere, mahkemede geçerli olabilecek zaman damgalarıyla izlenebilir olmalıdır
- Kaynak sistemler olmadan yeniden yapılandırılabilir — çünkü tasfiye sırasında bu sistemler donmuş, kısmen erişilebilir veya mahkemece atanmış bir kayyumun kontrolünde olabilir
- Her raporlama çıktısında tutarlı — Güvence Hesabı'na verilen rakam; EGM'ye raporlanan, katılımcının son ekstresinde görünen ve fon saklayıcısının kayıtlarında bulunan rakamla eşleşmelidir
- Talep üzerine tekrarlanabilir — transferden altı ay sonra bir katılımcı ödemesine itiraz ederse, tetikleme tarihindeki hesap durumunun tam olarak ne olduğunu kanıtlayabilmelisiniz
Çoğu pipeline bunların hiçbirini temiz bir şekilde yapamaz.
Mevcut BES Mimarileri Nerede Başarısız Oluyor
Üretimde tipik olarak şunları görüyorum:
Üzerine yazma tabanlı düzeltme mantığı. Bir katkı yanlış tahsis edilip sonra düzeltildiğinde, düzeltme satırı günceller. Önceki hatalı durum ya yok olmuştur ya da hiçbir zaman yasal kayıt olarak tasarlanmamış bir change-log tablosunda yaşar. Bir garanti fonu denetçisine, 15 Mart'taki bakiyenin 20 Mart'ta postalanan katılımcı ekstresi ile bugün ambardan üretilen yeniden yapılandırma arasında neden farklı olduğunu açıklamayı deneyin.
Aslında snapshot olmayan fon pay fiyatı snapshot'ları. Günlük NAV saklanır, ancak bir katkıyı satın alınan birimlere çeviren tahsis mantığı, veride değil uygulama kodunda yaşayan iş kurallarına bağlıdır. Kod değiştiğinde — bir yuvarlama kuralı, bir kesim saati, bir ücret yaklaşımı — geçmişe dönük yeniden yapılandırma sessizce kayar.
Yalnızca mevcut durum olarak saklanan devlet katkısı durumu. Hak ediş takvimleri, hak ediş oranları, önceki çıkış kesintileri — bunlar genellikle değişmez olaylar olarak saklanmak yerine okuma sırasında hesaplanır. Güvence Hesabı verilere ihtiyaç duyduğu anda hesaplama mantığı mevcut değilse, sayılar yeniden üretilemez.
Operasyonel sistemlere bağlı mutabakat kayıtları. Emeklilik şirketinin kayıtları ile portföy yönetim şirketi arasındaki mutabakat, az önce el konulmuş aynı SQL Server üzerinde yaşar. Kimse bunu garanti fonunun ulaşabileceği bir yere kopyalamayı düşünmemiştir.
Mimarinin Gerçekten İhtiyaç Duyduğu Şey
İşte BES veri mühendisliğinin sıradan finansal raporlamadan ayrıştığı yer burasıdır. Daha sonra soruları yanıtlayacağınız mutlu yol için inşa etmiyorsunuz. Sizin olmadığınız ve verinin kendi adına konuşmak zorunda olduğu durum için inşa ediyorsunuz.
Event-sourced katılımcı defterleri. Her katkı, tahsis, ücret kesintisi, transfer, devlet katkısı tahakkuku ve çıkış; iş zaman damgası ve sistem zaman damgası olan değişmez bir olay olmalıdır. Bakiyeler türetilir, asla gerçek olarak saklanmaz. Bu bir tercih değil — sistemler karardıktan sonra rastgele bir geçmiş tarihte pozisyonu yeniden yapılandırmanın tek yolu.
Veri olarak sürümlenen iş kuralları. Ücret tarifesi, hak ediş eğrisi, devlet katkısı hesabı, kesim kuralları — hepsi kodda değil, geçerlilik başlangıç ve bitiş tarihleri olan tablolarda saklanmalıdır. Kod yoksa, kurallar hâlâ olay akışına karşı çalıştırılabilir olmalıdır.
Bağımsız, düzenleyicinin erişebileceği arşivler. Katılımcı defterinin, iş kuralı tablolarının, NAV geçmişinin ve mutabakat durumunun; garanti fonunun batan şirketin altyapısı üzerinden geçmeden erişebileceği depolamaya günlük değişmez ihracatları. WORM depolama, harici saklayıcı veya düzenleyici tarafından zorunlu tutulan bir konum — mevcut EGM rehberliğine bağlıdır, ancak ilke arşivin şirketten daha uzun yaşamasıdır.
Birinci sınıf çıktı olarak mutabakat. Emeklilik şirketi kayıtları, portföy yönetim şirketi kayıtları ve takasbank/saklayıcı kayıtları arasındaki günlük üçlü mutabakat bir iç kontrol belgesi değildir. Delildir. Defterin kendisiyle aynı titizlikle ihraç edilmeli, imzalanmalı ve saklanmalıdır.
Kimsenin Yapmadığı Test
Her BES veri liderine önerdiğim egzersiz şudur: yarın sabahtan itibaren operasyonel sistemlerinizin kullanılamadığını varsayın. Yalnızca bu gece itibarıyla harici arşivlere ihraç edilmiş olana sahipsiniz. Herhangi bir katılımcı için, son on yıldaki herhangi bir tarih itibarıyla tam pozisyonunu; altta yatan olaylara ve iş kurallarına tam izlenebilirlikle üretebilir misiniz?
Cevap "şuraya giriş yapmamız gerekir" veya "BT'den birinin" içeriyorsa, mimari iflas testinden kalmıştır.
Rahatsız edici gerçek şu ki, çoğu BES pipeline'ı günlük operasyonlar ve aylık düzenleyici raporlar için optimize eden kişiler tarafından tasarlanmıştır. İflas raporlaması farklı bir problemdir. Farklı tutarlılık gereksinimleri, farklı kullanılabilirlik gereksinimleri ve farklı bir "doğru" tanımı vardır.
Pratik Başlangıç Noktaları
Bir BES veri platformundan sorumluysanız ve bu yazı sizi rahatsız ediyorsa, buradan başlayın:
- Katılımcıya yönelik bir sayı üreten her hesaplamayı envantere alın ve mevcut uygulama yığını olmadan geçmiş olaylara karşı yeniden yürütülüp yürütülemeyeceğini belirleyin
- Yerinde güncellenen her tabloyu tespit edin ve migration iki yıl sürse bile event-sourced bir yedek tasarlayın
- Katılımcı defterinin birincil altyapınızın dışındaki depolamaya günlük harici ihracatını kurun ve geri yüklemeyi üç ayda bir sistemi hiç görmemiş biriyle test edin
- İş kurallarınızı, finansal modellere uyguladığınız aynı değişiklik kontrolüyle veri olarak sürümlendirin
- Mutabakat çıktısını operasyonel bir kayıt olarak değil, düzenleyici bir çıktı olarak ele alın
Güvence Hesabı koruması, katılımcılar emeklilik şirketleri hayatta kalmasa bile kesinliği hak ettiği için vardır. Bu korumanın arkasındaki veri mimarisi de aynı ciddiyeti hak ediyor. Şu anda, çoğu yerde, bu ciddiyete sahip değil.