Eşleştirme Problemi: EGM Katılımcı Kimliği Neden Türkiye'deki Diğer Tüm Finansal Kimliklerden Daha Zor Çözülür

Bir Türk emeklilik operasyonunda gördüğüm her pipeline aynı yanlış varsayımla başlar: katılımcının TC kimlik numarası ile tekil olarak tanımlandığı ve bu kolon üzerinde bir LEFT JOIN'in "bu kişi kim" sorusunu çözdüğü varsayımı. Çözmez. BES'te katılımcı kimliği, Türk finansal verilerindeki en zor eşleştirme problemidir — perakende bankacılıktaki müşteri tekilleştirmesinden daha zor, genel sigortadaki poliçe sahibi çözümlemesinden daha zor ve vergi idaresinin yaptığı mükellef eşleştirmesinden belirgin biçimde daha zordur.

Bunun nedeni teknik değil, tarihseldir. BES sistemi; işveren bordro dosyalarının, şirketten şirkete aktarılan sözleşmelerin, 2013'te dönüştürülen eski sigorta portföylerinin ve EGM'nin (bugünkü adıyla Emeklilik Gözetim Merkezi) hiçbir zaman mutabık kılınmak üzere tasarlanmamış kayıtlar karşısında günlük mutabakat yaptığı bir düzenleyici ortamın üzerine inşa edildi.

TC Kimlik Neden Sandığınız Temiz Anahtar Değil

Kağıt üzerinde TC kimlik numarası, checksum'ı olan 11 haneli benzersiz bir ulusal tanımlayıcıdır. Pratikte, 20+ yıl boyunca oluşmuş bir emeklilik portföyünde şunları bulursunuz:

• Yabancı katılımcılar: yabancı kimlik numarası (99 ile başlayan) standartlaşmadan önce sisteme giren, pasaport numaraları 11 haneye tamamlanarak ya da 11111111111 gibi yer tutucu değerlerle kaydedilmiş kişiler.
• Küçükler: OKS'ye (Otomatik Katılım Sistemi) dahil edilen ve TC'si işverenin bordro sistemi tarafından yanlış girilen katılımcılar — tek bir rakam yer değiştirdiğinde checksum başka bir gerçek kişi için hâlâ geçerli olabiliyor.
• Vefat etmiş katılımcılar: TC'si bir lehtar talebi sırasında aile üyesinin dosyasına yeniden atanmış ve aynı anahtarla iki katılımcı yaratılmış olanlar.
• Kurumsal aktarımlar: Gelen şirketin dosyasındaki Nüfus doğrulamasını geçemeyen TC değerlerinin, satırı düşüren ya da daha kötüsü değeri varsayılana çeken bir ETL işi tarafından "temizlenmiş" olması.
• Sadece isimle kayıtlı katılımcılar: 2001 öncesi bireysel emeklilik sözleşmelerinden BES'e taşınan ve TC'si sonradan Nüfus kayıtlarına isim eşleştirmesiyle doldurulan katılımcılar — yapıldığı anda bile olasılıksal olan bir eşleşme.

Kimlik modeliniz TC'yi birincil anahtar olarak varsayıyorsa, bu vakaların her biri bir MASAK sorgusu ya da lehtar ödemesi sırasında ortaya çıkacak sessiz bir veri kalitesi bombası hâline gelir.

İşveren Gönderim Problemi

OKS bu durumu iyileştirmedi, kötüleştirdi. İşverenler her ay katılımcı tanımlayıcıları içeren katkı dosyaları gönderiyor ve master katılımcı kaydına karşı uyuşmazlık oranı sıfır değil. Yaygın örüntüler:

• İşverenin İK sistemi katılımcının kızlık soyadını tutuyor; emeklilik şirketinde Nüfus güncellemesi sonrası evlilik soyadı var.
• İşveren, vatandaşlık düzeltmesi sonrası yeniden atanmış eski bir TC ile gönderim yapıyor (nadir ama vatandaşlığa geçen katılımcılarda oluyor).
• İşverenin dosyasında, bordro dışa aktarımındaki bir eşleme hatası yüzünden TC kolonunda katılımcının IBAN'ı ya da SGK numarası bulunuyor.
• Aynı firmadaki iki çalışan dosyada yer değiştirmiş — aynı işveren, aynı katkı tutarı, yanlış katılımcılar.

Bunların her biri bir sorgu değil, bir eşleştirme kararı gerektirir. Ve bu karar savunulabilir olmak zorundadır: işveren katkısı X'i katılımcı Y ile %87 güvenle eşleştirirseniz ve fon dağılımı yanlış çıkarsa, bu bir veri mühendisliği zahmeti değil, emeklilik mevzuatı kapsamında yasal bir risktir.

Aktarım Kayıtları: En Kötü Kategori

Bir katılımcı bir emeklilik şirketinden diğerine aktarıldığında (aktarım), alıcı şirket şunları içeren bir dosya alır:

• Katılımcının, gönderen şirket tarafından kaydedilmiş kimlik bilgileri
• Katkı geçmişi
• Fon dağılımı
• Lehtar verileri

Bunların hiçbirinin alıcı şirketin o kişi hakkında zaten bildikleriyle eşleşeceği garanti değildir — çünkü o kişi, alıcı şirkette hafifçe farklı bir kimlik kaydı altında zaten katılımcı olabilir. Şahsen, başka bir firmadan aktarılan bir katılımcının, gelen isimde "Ş" varken mevcut kayıtta "S" olduğu için ya da eski kayıtlardaki Hicri takvim girişlerinden kaynaklı bir dönüşüm hatasıyla doğum tarihi bir gün kaymış olduğu için yeni katılımcı olarak açıldığı vakalar gördüm.

Doğru davranış şudur: mevcut katılımcılara karşı fuzzy eşleştirme çalıştır, bir güven skoru üret ve bir eşiğin altındaki her şeyi insan inceleme kuyruğuna yönlendir. Çoğu sistemin gerçekte yaptığı şey: mükerrer katılımcı yaratmak — ve bunun üç yıl sonra katılımcı arayıp birikiminin neden olması gerekenin yarısı göründüğünü sorduğunda elle birleştirilmesi gerekiyor.

Kimlik Çözümlemesi Bir Güven Skorudur

Mimari hata, katılımcı kimliğini bir boolean olarak ele almaktır — bu kayıt ya katılımcıdır ya da değildir. Gerçekte, gelen her kayıt (işveren dosyası, aktarım dosyası, acente gönderimi, kurumsal kayıt) master katılımcı sicili karşısında şunlardan oluşan bir eşleşme skoru üretmelidir:

• TC kimlik tam eşleşmesi (ağırlıklı ama mutlak değil)
• Ad + soyad normalize edilmiş eşleşme (Türkçe karakter katlama, yaygın varyant işleme: Mehmet/Mehmed, Ayşe/Ayse)
• Bilinen dönüşüm hatalarına tolerans içeren doğum tarihi eşleşmesi
• Mevcutsa anne adı, baba adı (yaygın isimler için hâlâ en güçlü ayrıştırıcılar)
• Geçmiş işveren örtüşmesi
• Adres ve iletişim geçmişi

Çıktı bir olasılıktır ve pipeline'ın açık eşikleri olmalıdır: 0.95 üzeri otomatik eşleştirme, 0.75–0.95 arası manuel inceleme, 0.75 altı otomatik reddetme. Her karar; skor, özellikler ve varsa inceleyen kişi ile birlikte loglanır. SPK ya da EGM katkı X'in katılımcı Y'ye ait olduğuna nasıl karar verdiğinizi sorduğunda ürettiğiniz şey işte bu logdur.

Bunun Veri Katmanı İçin Anlamı

Bir BES veri platformu inşa eden ya da bakımını yapan herkes için birkaç somut sonuç:

• Katılımcı tablosunda hem iş anahtarı (TC) hem de sentetik surrogate key bulunmalıdır. Sistemler arasında asla yalnızca TC üzerinden join yapmayın.
• Gelen her dosya için eşleştirmenin insert öncesinde yapıldığı bir staging katmanı gereklidir, sonrasında değil.
• Eşleşme skorları her ilişki üzerinde birinci sınıf alan olarak kalıcılaştırılmalıdır — katkı-katılımcı, aktarım-katılımcı, lehtar-katılımcı. Saklanmadıysa, denetim perspektifinden hiç olmamış demektir.
• Mükerrer tespiti aylık bir batch işi olamaz. Her ingest sırasında çalışmak zorundadır; çünkü üç yıl sonra birleştirilen bir mükerrer, tüm elde tutma dönemi boyunca fon getirisinin yeniden hesaplanması demektir.
• Manuel inceleme kuyrukları bir başarısızlık modu değildir. Zorunlu bir kontroldür. Pipeline'ınızda sıfır manuel eşleşme varsa, eşikleriniz yanlıştır.

Hukuki Boyut

Emeklilik sistemlerinde kimlik hataları, örneğin pazarlama veritabanlarındaki gibi tolere edilmez. Yanlış tahsis edilmiş bir katkı fon değerini etkiler, bu da katılımcının gelecekteki emekli maaşını etkiler, bu da emeklilikte ya da vefat halinde ödeme hesaplamalarını etkiler. Düzenleyiciler, emeklilik şirketinin her kuruşun neden bulunduğu hesapta bulunduğunu — kanıtla — ispatlayabilmesini bekler.

İşte bu yüzden eşleştirme problemi bir sorgu olarak ele alınamaz. Yanlış satırı döndüren bir sorgu, 20 yıllık bir elde tutma dönemi boyunca sessizce büyüyen bir finansal hata üretir. Güven skorlu bir eşleşme ise savunulabilen, düzeltilebilen ve iyileştirilebilen denetlenebilir kararlar üretir.

Türkiye'deki emeklilik veri ekiplerinin çoğu hâlâ sorgu modelini çalıştırıyor. Olgunlaşmış olanlar ise güven modeline çoktan geçti — genellikle ilk ciddi mutabakat hatası aradaki farkı öğrettikten sonra.