Her BES operasyon ekibi eninde sonunda onlarla karşılaşır. İki katılımcı kaydı, farklı sözleşme numaraları, aynı gerçek kişi. Belki TC kimlik 2014'te yanlış girilmiş ve 2019'da düzeltilmiştir. Belki bir kadının soyadı evlilik sonrası değişmiş ve başka bir emeklilik şirketinden gelen transferde mevcut kayıtla eşleştirilmek yerine yeni bir kayıt oluşturulmuştur. Belki katılımcı ilkini unuttuğu için ikinci bir sözleşme açmıştır.
Mühendis buna bakar ve bir veri kalitesi problemi görür. Bir yerlerde bir birleştirme kuyruğu vardır, muhtemelen haftalık gözden geçirilir ve sonunda birisi bir düğmeye basarak ikisini tek kayda konsolide eder. MDM sistemi bunu loglar. Herkes yoluna devam eder.
Bu yanlıştır. Teknik olarak değil — hukuki olarak yanlıştır. Ve EGM sizden ne olduğunu yeniden inşa etmenizi istediğinde bu fark önemlidir.
Bir birleştirme aslında neyi yeniden yazar?
İki EGM kimliğini birine indirgediğinizde satırları tekilleştirmiyorsunuz. Daha önce Kimlik A ve Kimlik B'ye atfedilen her düzenleyici olayın aslında tek bir katılımcının geçmişi olduğunu geriye dönük olarak beyan ediyorsunuz. Bu beyan şunlara dokunur:
- Devlet katkısı hakları. %25 devlet katkısı katılımcı bazında, yıllık ve ömür boyu tavanlarla hesaplanır. İki kimlik paralel katkılar üzerinden bağımsız olarak devlet katkısı biriktirmiş olabilir. Bunları birleştirmek, ayrıyken hiç tetiklenmeyen tavanların üzerine çıkabilir — ya da devletin fazla ödeme yaptığını ortaya çıkarabilir.
- Devlet katkısı için hakediş saatleri. 3/6/10 yıllık merdiven (%15/%35/%60/%100) katılımcının sisteme giriş tarihinden itibaren işler. Kimlik A BES'e 2013'te, Kimlik B ise 2020'de girdiyse, birleştirilmiş katılımcının hakediş konumu ne aşikârdır ne de otomatiktir.
- Çıkışta stopaj hesaplamaları. Ayrılmadaki stopaj vergisi, elde tutma süresine ve çıkış nedenine bağlıdır. Farklı başlangıç tarihlerine sahip iki sözleşme, birleştirildiğinde ayrı tutulduğundan farklı stopaj üretir.
- Her iki kimliğe atıfta bulunan tüm EGM bildirimleri. Aylık katılımcı raporları, devlet katkısı talepleri, transfer bildirimleri — hepsi, artık aynı kişi olduğunu iddia ettiğiniz kimlik anahtarlarına referans veriyordu.
Bir birleştirme, düzenleyiciye şunu beyan etmektir: bu iki kişi hakkında size daha önce söylediğimiz her şey aslında tek bir kişi hakkındaydı. Bu bir veri operasyonu değildir. Bu bir hukuki bildirimdir.
Üç tür mükerrer ve neden aynı olmadıkları
Tüm mükerrerleri aynı şekilde ele almak ilk hatadır. Pratikte üç farklı senaryo vardır ve her birinin hukuki ağırlığı farklıdır:
1. Veri girişi düzeltmesi (TC kimlik yazım hatası, kayıt sırasında ad yanlış yazımı). İki kimlik hiçbir zaman meşru değildi. Biri bir hayalet kayıttır. Burada birleştirme bir düzeltmeye daha yakındır, ancak hayalet kimlik altında talep edilen devlet katkılarını geri sarmak zorundasınızdır çünkü bu talepler var olmayan ya da başka birine ait bir TC altında yapılmıştır.
2. Meşru kimlik değişikliği (soyadı değişikliği, TC yeniden düzenlemesi). Her iki kimlik de var oldukları dönemde geçerliydi. Katılımcının gerçekten iki dönemde iki adı vardı. Birleştirme bir düzeltme değildir — bir süreklilik beyanıdır. Eski ad altındaki düzenleyici geçmiş geçerli kalır; üzerine yazmıyorsunuz, bağlıyorsunuz.
3. Gerçek çift kayıt (transfer-in çakışması, ikinci sözleşme). Katılımcının aynı anda gerçekten iki aktif BES sözleşmesi vardı. Bu veri anlamında bir mükerrer bile değildir. Bunları birleştirmek, katkıları geri sarmadan hukuki olarak imkânsız olabilir çünkü iki sözleşme, her ikisi de hak biriktirmiş iki ayrı hukuki ilişki demektir.
Bu üçünü ayırt etmeyen bir tekilleştirme kuyruğu, hukuki açıdan üç farklı olay için hukuki olarak aynı denetim izini üretecektir. İşte olmayı bekleyen bulgu budur.
Savunulabilir bir birleştirme protokolü neye benzer?
En azından, herhangi iki kimlik birleştirilmeden önce aşağıdakiler bir kayıt olarak var olmalıdır — bir ticket'ta değil, bir Jira yorumunda değil, denetçinin üç yıl sonra okuyabileceği bir sistemde:
- Kanıt. Nüfus cüzdanı kopyası, evlilik cüzdanı, EGM yazışması, katılımcı beyanı. Kimlik A ve Kimlik B'nin aynı kişi olduğunu neyle kanıtladıysanız.
- Sınıflandırma. Yukarıdaki üç türden hangisi. Bu, sonraki her şeyi belirler.
- Birleştirme öncesi anlık görüntü. Birleştirme hemen öncesindeki her iki kimliğin tam durumu: katkı geçmişi, devlet katkısı bakiyesi, hakediş pozisyonu, fon dağılımları, her iki kimliğe temas eden her düzenleyici referans numarası.
- Mutabakat. Varsa devlet katkısı hakkındaki değişiklikler. EGM'ye düzeltme olarak neyin raporlandığı. Hangi stopaj yeniden hesaplamasının uygulandığı.
- Yetkilendirme. Bir veri yöneticisi değil. İsmi eklenmiş bir uyum onayı, çünkü bu bir hukuki işlemdir.
- İleri referans. Bu katılımcıya dokunan her gelecekteki raporun bir birleştirmenin olduğunu bilmesi gerekir, çünkü birleştirme öncesi dönemlerin yeniden inşası artık aktif kayıt olarak var olmayan kimliklere referans verecektir.
Gördüğüm neredeyse hiçbir BES pipeline'ı bunu uçtan uca uygulamıyor. Çoğu 1. ve 6. adımları uyguluyor ve iş bitti diyor. Ortadaki adımlar birinin e-postasında yaşıyor.
Kimsenin hazırlanmadığı denetim senaryosu
EGM denetimi, bir birleştirmeden üç yıl sonra. Denetçi soruyor: 2022 2. çeyrek itibarıyla katılımcı X'in devlet katkısı bakiyesini yeniden inşa edin. 2022'de bu katılımcı iki kimlik olarak vardı. Mevcut sisteminiz birleştirilmiş geçmişe sahip tek bir katılımcı gösteriyor. Denetçi şu anı sormuyor. Denetçi 2022'de ne raporladığınızı ve bunun o zaman doğru olup olmadığını soruyor.
Eğer her iki kimliğin birleştirme öncesi durumunu, EGM'ye o zaman raporladığınız aynı rakamlarla üretemezseniz, soruyu cevaplayamazsınız. Birleştirme süreciniz tarihsel kayıtları birleştirilmiş görünümün yanında korumak yerine üzerine yazdıysa, denetim izi gitmiştir.
İşte bu yüzden birleştirmeler yıkıcı değil, ekleyici olmalıdır. Eski kimlikler birleştirme öncesi durumlarında sonsuza kadar sorgulanabilir kalmalıdır. Birleştirme, geçmişin yeniden yazımı değil, üzerine katmanlanmış yeni bir olgudur.
Rahatsız edici sonuç
Çoğu BES veri platformu, katılımcı kimliğini daha iyi eşleştirme algoritmaları ve bir inceleme kuyruğuyla çözülecek bir veri problemi olarak ele alan ekipler tarafından inşa edildi. İsim ve doğum tarihi üzerinde bulanık eşleştirme, güçlü anahtar olarak TC kimlik, sınır durumlar için insan incelemesi. O mimari bir CRM için yeterlidir. Her kimlik beyanının vergi sonuçları olduğu ve her birleştirmenin devlete yapılmış bir beyan olduğu bir emeklilik sistemi için yeterli değildir.
BES pipeline'ınız bir avukatın imzalayacağı bir belge üretmeden iki katılımcıyı birleştirebiliyorsa, sizin bir tekilleştirme sisteminiz yok. Güzel bir arayüze sahip bir yükümlülük üreteciniz var.