Bir katılımcı çağrı merkezini arar. Evlenmiş, soyadı değişmiştir ve kayıtlarının güncellenmesini ister. Temsilci CRM'i açar, yeni soyadını yazar, kaydeder. İki dakika.
O iki dakika içinde, sessizce dört düzenleyici yükümlülüğü ihlal ettiniz, bir lehtar atamasını geçersiz kıldınız ve altı ay sonra kimsenin planlamadığı bir denetim sırasında yüzeye çıkacak olan bir EGM mutabakat kırılması yarattınız.
Türkiye emeklilik operasyonlarında sürekli gördüğüm örüntü budur: yasal kimlik değişikliği bir UPDATE participants SET last_name = ? WHERE tckn = ? işlemi olarak ele alınıyor. Veri hijyeni gibi görünüyor. Aslında bir uyum olayıdır ve bu şekilde modellenmesi gerekir.
İsim Değişikliği Aslında Nedir
Bir katılımcının yasal ismi, katılımcının bir niteliği değildir. Bu, katılımcının belirli bir zaman noktasındaki niteliğidir ve yasal bir belgeye bağlıdır: evlilik cüzdanı, boşanma kararı, cinsiyet uyum ismi değişikliği için mahkeme kararı ya da Nüfus'tan gelen idari bir düzeltme.
Soyad alanının üzerine yazdığınızda, katılımcının her zaman bu isme sahip olduğunu ileri sürmüş olursunuz. Eski ismi tüketen aşağı akış her sistem artık ana kaydınızla çelişir ve eski isim altında ürettiğiniz her tarihsel belge, referans verdiği kimlikten kopmuş olur.
TCKN aynı kalır. Sabit olan tek şey odur. Vergi otoritelerinin, düzenleyicilerin ve lehtarların bu kişiyi nasıl tanıdığı da dahil olmak üzere diğer her şey artık tutarsızdır.
EGM Mutabakat Kırılması
EGM (Emeklilik Gözetim Merkezi), BES ekosistemi için yetkili katılımcı sicilini tutar. Günlük dosyalarınız katılımcının mevcut yasal ismini taşır. CRM'inizi güncellediğiniz an — doğru kanal üzerinden ve doğru destekleyici belge referansıyla ilgili EGM bildirimini tetiklemeden — iki sorununuz vardır:
- Bir sonraki günlük dosyanız, o TCKN için EGM kaydıyla eşleşmeyen bir isim gösterir
- Mutabakat raporlarınız uyuşmazlığı işaretler, ancak uyuşmazlık, önce kime bildirim yapıldığına bağlı olarak sizin sisteminizin doğru ve EGM'nin bayat olduğu ya da tam tersi durumdur
Ekiplerin, aslında cevap "altta yatan yasal belge her iki tarafta aynı yürürlük tarihiyle işlenene kadar hiçbiri" iken, hangi tarafın yetkili olduğunu bir hafta tartıştıklarını gördüm. Yürürlük tarihi olmayan bir isim değişikliği, isim değişikliği değildir. Veri bozulmasıdır.
FATCA ve CRS: Rapordaki İsim
Katılımcı bir ABD kişisi ise ya da CRS raporlanabilir bir yargı bölgesinin vergi mukimiyse, ismi vergi otoritesine sunulan yıllık raporlarda görünür. Bu raporların gönderim geçmişi vardır. Eski isim altında dosyalanmışlardır.
Şimdi düşünün: katılımcının 2023 CRS raporunda "Ayşe Yılmaz" görünüyor. Sisteminiz bugün "Ayşe Demir" gösteriyor. Vergi otoritesinin Ayşe Demir sorgusu hiçbir tarihsel dosyalama döndürmez. Ayşe Yılmaz sorgusu, mevcut kaydınıza göre var olmayan bir kişiye karşı dosyalamalar döndürür.
Doğru model, yürürlük tarihleriyle bir isim geçmişi tablosudur ve katılımcının yasal ismini bugüne göre değil, raporlama dönemine göre çözen bir raporlama mantığıdır. Gördüğüm çoğu uygulama bunu bugüne göre çözer. Bu, yalnızca bir vergi otoritesi soruşturması sırasında görünür hale gelen bir şekilde yanlıştır ve bu, keşfetmek için tam olarak yanlış andır.
KVKK Onay Zincirleri
Katılımcının verdiği her onay — pazarlama için, veri işleme için, üçüncü taraflarla paylaşım için — belirli bir yasal isim altında imzalanmıştır. KVKK, onayı belirli bir veri sahibi tarafından yapılan belirli bir eylem olarak ele alır.
Ayşe Yılmaz tarafından imzalanan bir onay otomatik olarak Ayşe Demir'e geçer mi? Yasal olarak evet, çünkü TCKN kimlik sürekliliğini kurar. Operasyonel olarak, bir DPO denetimi belirli bir işleme faaliyeti için onay eserini üretmenizi isterse, imzalama sırasında yasal olan isim altında imzalanmış bir belgeyi mevcut kimlikle bağlantılı olarak üretmeniz gerekir.
Onay yönetim sisteminiz isim alanının üzerine yazdıysa, o bağlantı gitmiştir. Arşivde canlı sistemlerinizin hiçbir yerinde görünmeyen isimler altında onaylarınız vardır. Bunu açıklarken bol şans.
Lehtar Problemi
Beni uykusuz bırakan da budur. BES'te lehtar atamaları yasal belgelerdir. Katılımcı beş yıl önce eşini lehtar olarak atadığında bir form imzalamıştır. O formun içinde:
- İmzalama sırasındaki yasal ismi
- Lehtarın imzalama sırasındaki yasal ismi
- Bu isimlere bağlı ıslak imza ya da nitelikli elektronik imza
Şimdi boşanır. Soyadını eski haline döndürür. Lehtar ataması hâlâ eski eşini isimlendirir. Bunu güncellememiştir, çünkü açtığı isim değişikliği talebinin "her şeyi hallettiğini" düşünür.
Yarın ölürse, lehtar formu geçerlidir. Eski eşi birikimi alır. Aile, boşanma ve isim değişikliğinin zımni bir iptal oluşturduğunu iddia edecektir. Kaybedecekler, çünkü Türk medeni hukuku idari isim değişikliklerini lehtar atamalarının iptali olarak ele almaz.
Bir isim değişikliği talebi en azından şunları tetiklemelidir:
- Aktif lehtar atamalarının zorunlu incelenmesi
- Katılımcıya, lehtarların otomatik olarak güncellenmediğini teyit eden yazılı bildirim
- Katılımcı lehtarları olumlu şekilde teyit edene veya güncelleyene kadar kapanmayan bir iş akışı kuyruk öğesi
Çoğu sistem bunların hiçbirini yapmaz. Soyadını günceller ve talebi kapatır.
Veri Modeli Nasıl Görünmeli
participant.last_name'i değiştirilebilir bir alan olarak modellemeyi bırakın. Şöyle modelleyin:
tckn,legal_name,effective_from,effective_to,source_document_type,source_document_referenceiçerenparticipant_identitytablosu- "Katılımcının ismi"nin her tüketicisi hangi tarihe göre olduğunu belirtmelidir
- Düzenleyici raporlar raporlama dönemine göre çözülür
- Lehtar formları imzalama tarihine göre çözülür
- Müşteriye dönük iletişimler bugüne göre çözülür
- Mevcut isim bir sütun değil, bir görünümdür
Ve her isim değişikliği işlemi bir işlem değil, bir iş akışıdır:
- Yasal belge alımı ve doğrulaması
- Yürürlük tarihi belirlenmesi
- Belge referansıyla EGM bildirimi
- Lehtar inceleme tetiklemesi
- Onay bağlantısının korunması
- Aynı yürürlük tarihiyle aşağı akış sistem yayılımı
- Tam öncesi/sonrası ve tetikleyici belge ile denetim günlüğü kaydı
Bu Neden Sürekli Gözden Kaçıyor
İsim değişiklikleri katılımcı başına nadirdir ancak toplamda yaygındır. KPI'ları talepleri hızlı kapatmayı ödüllendiren çağrı merkezi veya operasyon personeli tarafından işlenirler. Uyum sonuçları, bir denetim, bir ölüm ya da bir vergi soruşturması onları yüzeye çıkarana kadar görünmezdir — ki o noktada güncellemeyi yapan kişi çoktan gitmiştir ve denetim izinde "rutin veri düzeltmesi" yazar.
Çözüm eğitim değildir. Eğitim personel değişimini aşamaz. Çözüm, ismi operasyonel sistemlerde doğrudan düzenlenebilir bir alan olarak açığa çıkarmayı reddetmektir. İsmi değiştirmenin tek yolu, tam iş akışını tetikleyen bir yasal belge sunmak olursa, sorun kendi kendini çözer.
Bir isim değişikliği bir uyum olayıdır. Onu böyle ele alan sistemi kurun ya da neden önemli olduğunu keşfetmenize bir denetimlik mesafede olduğunuzu kabul edin.