Sınır Ötesi Transfer Problemi: Yurt Dışına Taşınan Bir BES Katılımcısı Raporlama Yığınınızdaki Her Varsayımı Nasıl Bozar

Bir BES katılımcısı çağrı merkezinize Münih'e taşındığını bildirir. Müşteri temsilcisi adres alanını günceller. Poliçe yönetim sistemi kabul eder. Hiçbir şey bozulmaz. Hiçbir uyarı tetiklenmez. Aylık EGM beslemesi ertesi hafta hiçbir şikayet olmadan gönderilir.

On sekiz ay sonra, vergi operasyonlarındaki biri Bundeszentralamt für Steuern için CRS XML'ini oluşturmaya çalıştığında, katılımcının Türk TCKN'si olduğu ama Alman vergi mukimliği bulunduğu ve şemanın gerektirdiği alanda TIN'i olmadığı için hat bir istisna fırlatır. Bir başkası, katılımcının kişisel verilerinin bir buçuk yıldır KVKK Madde 9 dayanağı olmadan İrlanda'daki bir reasürans analitik ortamına akmakta olduğunu fark eder. Peki ya EGM bildirimleri? Onlar da bu süre boyunca katılımcıyı yurt içi olarak etiketleyerek gitti.

Bu bir uç durum değildir. Türk emeklilik ve sigorta veri yığınlarındaki en yaygın yapısal başarısızlıktır ve üç düzenleyici rejimin, katılımcıların yerinden kıpırdamayacağını varsayan sistemlere sonradan cıvatalanmış olması nedeniyle yaşanır.

Üç Efendi

Bir BES katılımcısı yurt dışında vergi mukimi olduğunda, aynı sözleşme satırı eş zamanlı olarak şu yükümlülükleri taşır:

• EGM (Emeklilik Gözetim Merkezi) — Türkiye mukimi katılımcı raporlamasını belirli bir şemada, yerel kimlik numaralarıyla bekler ve yabancı vergi mukimliği mantığınızı özellikle önemsemez.
• FATCA/CRS — TIN yakalama, öz beyan (self-certification), indicia incelemesi ve EGM'nin veri modeliyle neredeyse hiçbir ortak yönü olmayan yargı yetkisine özgü raporlama formatları gerektirir.
• KVKK — kişisel veri bir sınırı geçtiği anda (Türkiye dışındaki bir DR sahasına rutin yedekleme replikasyonu veya bir SaaS satıcısının AB işleme bölgesi dahil), açık rıza, Kurul onaylı taahhütname veya Madde 9'daki dar istisnalardan birini gerektirir.

Üç rejimin tetikleyici olayları farklı, kimlik numaraları farklı, saklama kuralları farklı ve alt tüketicileri farklıdır. Hattınız neredeyse kesinlikle bunlardan birine iyi hizmet edecek, ikisine kötü hizmet edecek ve üçüncüsüne kazara hizmet edecek şekilde inşa edilmiştir.

Kırılma Aslında Nerede Gerçekleşiyor

İlgi çekici olan başarısızlık, bu rejimlerin ilke olarak çatışması değil. Katılımcı yaşam döngüsünün farklı noktalarında çatışmalarıdır ve bu noktaların hiçbiri CRM'inizin adres değişikliğini yakaladığı an değildir.

Tipik bir Türk emeklilik operatörünün yığınının nasıl göründüğünü düşünün:

• Tek bir country_of_residence alanı olan, varsayılan olarak TR'ye ayarlı poliçe yönetim sistemi.
• Uyruğu yakalayan ancak vergi mukimliğini onboarding sonrası nadiren yeniden doğrulayan ayrı bir KYC modülü.
• Yurt içi katılımcılar hakkında sabit kodlanmış varsayımlarla poliçe yönetiminden zamanlanmış ekstre olarak inşa edilmiş bir EGM beslemesi.
• Bir FATCA/CRS modülü — genellikle 2016-2017'den kalma bir eklenti — dünkü anlık görüntü üzerinde indicia aramaları çalıştırır ve istisnaları küçük bir operasyon ekibine bildirir.
• İşleme amaçlarını sistem düzeyinde belgeleyen ancak katılımcı düzeyinde belgelemeyen bir KVKK envanteri (VERBIS).

Adres değişikliği birinci alanı günceller. Bu mimaride hiçbir şey bu değişikliği CRS indicia motoruna, EGM sınıflandırma mantığına veya KVKK sınır ötesi transfer kaydına yaymaz. Her alt sistem değişikliği kendi programına göre keşfeder — keşfederse.

Tespit Mekanizması Olarak CRS Bildirimi

Çoğu şirket çatışmayı CRS raporlama döngüsünde öğrenir; operasyon ekibi ekstreyi çalıştırdığında ve şema doğrulayıcı eksik TIN'ler, belirsiz mukimlik veya katılımcının dosyadaki ülkesiyle uyuşmayan raporlanabilir yargı yetkileri nedeniyle kayıtları reddettiğinde.

O noktada:

• Geçmiş N ay için EGM bildirimleri zaten yanlıştır.
• KVKK transfer sicilinde gerçekleşen sınır ötesi işlemenin hiçbir kaydı yoktur.
• CRS rejiminin gerektirdiği öz beyan formu hiç gönderilmemiştir, çünkü hiçbir şey onu tetiklememiştir.
• Katılımcı zaten sözleşmesini iptal etmiş veya transfer etmiş olabilir; bu da artık kolayca yeniden toplayamayacağınız verilerle kapalı bir sözleşme hakkında rapor verdiğiniz anlamına gelir.

Ve iyileştirme maliyeti bildirim düzeltmesi değildir. Geriye dönük KVKK riski, EGM'nin yeniden düzenlenmesi ve denetçilerinizin şimdi kaç başka katılımcının aynı sessiz durumda olduğunu öğrenmek istemesidir.

Bariz Çözümler Neden İşe Yaramaz

"Bir vergi mukimliği alanı ekleriz." Peki. Kim doldurur? Hangi tetikleyiciyle? Adres değişikliğini alan CSR, OECD mukimlik denkliği kurallarında (tie-breaker) eğitimli değildir. Vergi mukimliği; adres değildir, uyruk değildir ve katılımcının taşındığını söylediği ülke değildir.

"Adres değişikliklerinde indicia kontrolleri çalıştırırız." Daha iyi, ancak indicia bir tarama mekanizmasıdır, bir belirleme değildir. Öz beyana ihtiyaç duyan katılımcıları işaretler. Öz beyanı gerçekten talep etmek, almak ve doğrulamak için — sıkı bir SLA ve raporlanabilir-yargı yetkisi varsayılanlarına bir geri düşüş ile — bir iş akışınız yoksa, kontrol değil gürültü eklemişsinizdir.

"Yurt dışı mukim katılımcıları ayrı bir veri alanında ayrıştırırız." Şimdi iki poliçe yönetim örneği arasında bir senkronizasyon probleminiz ve her ikisini de mutabık kılması gereken bir EGM beslemeniz var. Ayrıca KVKK'yı da çözmediniz, çünkü ayrıştırmanın kendisi kendi hukuki dayanağını gerektiren bir işleme faaliyetidir.

Aslında Neyin Değişmesi Gerekiyor

Çözüm bir alan değildir. Katılımcı mukimlik durumunu, tıpkı bir hasar olayı veya bir katkı payı gibi, aşağı akış yayılımı olan birinci sınıf bir olay olarak ele almaktır.

Somut olarak:

• Eski ülke, yeni ülke, yürürlük tarihi, kaynak (katılımcı beyanı vs. sistem çıkarımı) ve kanıt türünü taşıyan bir mukimlik değişikliği olay şeması. Aşağı akış her sistem buna abone olur.
• CRS tarafında engelleyici bir iş akışı — eğer olay olası bir yurt dışı mukimliği gösteriyorsa, tanımlı bir pencere içinde öz beyan talep edilmeli ve ya alınmalı ya da katılımcı raporlanabilir statüsüne varsayılan olarak atanmalıdır. Birinin kuyruğundaki bir tikettn ibaret olmamalıdır.
• Mukimlik olay akışından okuyan EGM sınıflandırma mantığı, adres alanından değil. Bunlar farklı sorulardır ve aynı kaynağı paylaşmamalıdırlar.
• Bir katılımcının verisi Türkiye dışındaki bir işleme ortamına akmaya başladığında otomatik olarak oluşturulan KVKK transfer sicili kayıtları. Bu, sıkıcı vakaları da içerir: bulut DR bölgeniz, reasürörünüzün analitik platformu, e-posta sağlayıcınızın yabancı sunucuları.
• Bir mutabakat raporu — yıllık değil, aylık — EGM'nin yurt içi olarak düşündüğü nüfus, CRS'nin raporlanabilir olarak düşündüğü nüfus ve KVKK'nın sınır ötesi dayanağını belgelediği nüfusu karşılaştırır. Üç kümenin tutarlı olması gerekir. Neredeyse hiçbir zaman değildir.

Rahatsız Edici Kısım

Bunu düzgün inşa etmek, FATCA Türkiye'de bağlayıcı hale geldiğinden beri emeklilik katılımcı veri modelinizin yanlış olduğunu ve CRS eklentisinin durumu daha iyi değil daha kötü hale getirdiğini kabul etmek anlamına gelir. Ayrıca her yıl CRS ekstrelerini elle temizleyen operasyon ekibinin, kimsenin düzeltmeyi finanse etmek istemediği yapısal bir kusur için telafi edici iş yaptığı anlamına gelir.

Teknik iş zor değildir. Politik iş — işletmeyi bir katılımcının yurt dışına taşınmasının, sözleşme iptali veya lehdar değişikliği ile eş değer bir yaşam döngüsü olayı olduğuna ve buna göre kadro tahsis edilmesi gerektiğine ikna etmek — bu programların öldüğü yerdir.

Bunu iyi ele aldığını gördüğüm her şirket aynı şekilde başladı: bir veri modeli değişikliğini yetkilendirecek kadar kıdemli biri; vergi, uyum, KVKK ve BT ile bir odada oturdu ve tek bir olay tanımı üzerinde anlaşmadan çıkmayı reddetti. Aşağı akış her şey bunu takip etti. Bunu tek bir fonksiyon içinde çözmeye çalışan şirketler — genellikle vergi, ara sıra BT — hâlâ elle CRS düzeltmeleri üretiyor ve Kurum'un son üç yıllık transferler için KVKK dayanaklarının ne olduğunu sormamasını umuyor.