Uyum yetkilileri FATCA ve CRS'i genellikle temiz ifadelerle anlatır: raporlanabilir hesapları belirle, hesap sahibini sınıflandır, bir XML dosyası üret, son tarihten önce yerel vergi otoritesine ilet. Tamam. Sunumda üç kutu ve iki ok var.
O XML dosyalarını gerçekten besleyen veri hattı, üç kutu ve iki oka hiç benzemez. Bu hat; eşleşmeyen yargı bölgeleri, yarı dolu TIN alanları ve müşterinin posta adresini yakalamak için 1998'de tasarlanmış —vergi mukimliğini değil— çekirdek sistemlerle dolu bir mezarlık gibidir.
Konuşmak istediğim açık tam da bu. Çünkü uyum kontrol listesi ile veri hattının gerçekliği neredeyse hiç aynı odada bulunmaz ve FATCA/CRS programlarının yıllarca sessizce para sızdırıp düzenleyici risk biriktirmesinin nedeni de tam olarak budur.
Düzenlemenin sahip olduğunuzu varsaydığı veri
FATCA ve CRS raporlama şemaları, kurumun her hesap için tutarlı bir olgular kümesi üretebileceğini varsayar:
- Hesap sahibinin vergi mukimi olduğu ülke (veya ülkeler)
- Her mukimlik için, ilgili yargı bölgesinin doğru formatında TIN
- Hesap sahibi sınıflandırması (bireysel, pasif NFE, aktif NFE, finansal kuruluş vb.)
- Pasif tüzel kişiler için kontrol eden kişiler, kendi mukimlikleri ve TIN'leriyle birlikte
- Yıl sonu hesap bakiyesi ve yıl içinde ödenen brüt tutarlar
- Doğru para birimi, doğru ondalık işleme, doğru tarih semantiği
Düzenleme bunların olgu olduğunu varsayar. Pratikte çoğu türetilmiş değerdir ve birkaçı, akışın aşağısında kimse itiraz etmediği için hayatta kalmış tahminlerden ibarettir.
Veri gerçekte nerede yaşıyor
Tipik bir Türk bankası ya da sigortacısında (ve açıkçası gördüğüm pek çok Avrupa kurumunda), FATCA/CRS hattının girdileri en az altı farklı yerden gelir:
- Çekirdek bankacılık veya poliçe yönetim sistemi: bakiyeler, primler ve hesap tanımlayıcıları için
- CRM: müşteri demografisi için, çoğunlukla farklı bir müşteri anahtarıyla
- KYC/müşteri kabul sistemi: kendini beyan formlarının bulunduğu, kimi zaman taranmış PDF, kimi zaman yapılandırılmış veri
- AML sistemi: zaman zaman KYC ile çelişen risk sınıflandırması için
- Doküman yönetimi: imzalı W-8/W-9/öz-sertifika formları için
- Manuel elektronik tablolar: kimsenin gerçek bir sistemde modellemek istemediği uç durumlar için uyum ekibinin tuttuğu dosyalar
Bunların her birinin kendi "müşteri" tanımı vardır. Çekirdek sistem müşteriyi bir hesap olarak görür. CRM, müşteriyi birden fazla hesabı olabilecek bir kişi olarak düşünür. KYC, müşteriyi belirli bir tarihte açılmış bir dosya olarak ele alır. Veri hattının tüm bunları tek bir raporlanabilir varlığa indirgemesi ve sonra bu mutabakatı, geçmiş raporları bozmadan yıldan yıla taşıması gerekir.
Vergi mukimliği problemi
Herkesi yıkan konu budur. Vergi mukimliği adres değildir. Uyrukluk değildir. Müşterinin telefon faturasını ödediği yer değildir. Kendi beyanına dayanan, kimi zaman belgelerle desteklenen, kimi zaman emarelerden çıkarılan bir statüdür.
Çoğu eski sistemde tek bir adres alanı ve tek bir uyrukluk alanı bulunur. Hiçbiri vergi mukimliğine karşılık gelmez. Bu yüzden kurumlar, genellikle düzenleme yürürlüğe girdikten sonra eklenmiş bir vergi mukimliği tablosu yapıştırır ve sonuçta şunları elde ederler:
- 2016'da vergi mukimliği beyan edilmiş ve bir daha hiç güncellenmemiş müşteriler
- Uyrukluğu değişmiş ama mukimlik kaydı değişmemiş müşteriler
- CRS sisteminde iki mukimliği olan, ancak FATCA sisteminde tek mukimliği olan müşteriler — çünkü iki sistem, iki yıl arayla farklı proje ekiplerince hayata geçirilmiştir
- AML'de US person olarak işaretlenmiş ama FATCA etiketlemesinde işaretlenmemiş müşteriler — çünkü emare kuralları tutarsız uygulanmıştır
Hat çalıştığında, bu tutarsızlıkların her biri ya bir raporlama kararına ya da bir bastırma kararına dönüşür. Her ikisi de denetlenebilir. Her ikisi de yanlış olabilir.
TIN format tuzağı
Her yargı bölgesinin kendi TIN formatı vardır. ABD dokuz haneli SSN, ITIN ya da EIN ister. Türkiye 11 haneli T.C. Kimlik No veya 10 haneli VKN ister. Almanya'nın kendine ait formatı vardır. Birleşik Krallık'ta birbirinden farklı şeyler olan NINO ve UTR vardır. CRS şemaları formatı doğrular ve yerel vergi otoritesinin portalı, tek bir kayıt bile doğrulamadan geçmezse XML dosyasının tamamını reddeder.
Bu nedenle hattın, gönderim öncesinde yargı bölgesi farkındalığı olan bir doğrulama yapması gerekir. Çoğu kurum bunu zor yoldan, ilk gönderim gününde, dosya reddedilip de birinin 40.000 kayıttan hangisinin bozuk olduğunu manuel olarak bulmak zorunda kaldığında öğrenir. Bu deneyimden sonra doğrulama yukarı taşınır. İkinci yılın ardından doğrulama müşteri kabul sürecine itilir. Üçüncü yıldan sonra biri nihayet bunun CRM'de sert bir durdurucu olması gerektiğini savunur ve hesap açmayı yavaşlatacağı gerekçesiyle reddedilir.
Kontrol eden kişiler ve tüzel kişilik çözümlemesi
Pasif finansal olmayan tüzel kişiler için kontrol eden kişileri raporlamak zorundasınız. Bu, hattın bir grafı gezmesi gerektiği anlamına gelir: tüzel kişiden nihai faydalanan kişilere, onların mukimlikleri ve TIN'leri, kendi sınıflandırmalarıyla birlikte. Çoğu KYC sistemi UBO verisini serbest metin alanlarıyla düz bir liste olarak saklar. Bunu CRS XML'inde temiz bir kontrol eden kişiler bloğuna dönüştürmek, hiç de önemsiz olmayan bir dönüşümdür ve tam olarak veri kalitesi sorunlarının katlandığı yerdir; çünkü tüzel kişi kaydındaki hatalar her kontrol eden kişi için çoğalır.
Veri hattının gerçekte yapması gerekenler
Uyum dilini sıyırıp attığınızda, FATCA/CRS hattı şunları yapıyor demektir:
- Müşteri anahtarları çatışan, heterojen kaynak sistemlerden veri al
- Bu anahtarları tek bir raporlanabilir müşteri varlığında çöz
- Öz-sertifikasyon eksik olduğunda emare kurallarını uygulayarak vergi mukimliği, sınıflandırma ve TIN verisiyle zenginleştir
- Yargı bölgesine özgü format kurallarına karşı doğrula
- Doğru yıl sonu semantiği ve döviz çevrimiyle finansal veriyi toplulaştır
- Kontrol eden kişiler için tüzel kişilik yapılarını gez
- Yargı bölgesi başına şemaya uygun bir XML dosyası üret
- Her sınıflandırma kararı için savunulabilir bir denetim izi tut
- Düzeltmeler dahil önceki yıl gönderimlerini en azından yerel saklama süresi boyunca aynen yeniden üret
Sonuncusu, bir denetim kapıya dayanana kadar uyumun hiç sormadığı maddedir. Hat; üst sistemler şema değiştirirken, müşteriler öz-sertifikalarını güncellerken, hatta bankanın kendi tüzel yapısı yeniden örgütlenirken bile yıllar boyunca deterministik ve yeniden üretilebilir olmak zorundadır.
Bu operasyonel olarak neden önemli
FATCA/CRS'i bir raporlama yükümlülüğü olarak ele alan kurumlar, kırılgan bir yıllık proje ile baş başa kalır. Her Ocak ayında bir ekip; çıkartmak, mutabık kılmak, sınıflandırmak, doğrulamak ve göndermek için koşturur. Hatalar uçuş halinde yamanır. Bastırmalar gayrı resmi olarak uygulanır. XML çıkar, düzenleyici kabul eder ve gelecek yıla kadar herkes unutur.
Bunu bir veri kalitesi problemi olarak ele alan kurumlar farklı yatırım yapar. Vergi mukimliği yakalamayı müşteri kabul sürecine, yapılandırılmış ve doğrulanmış bir alan olarak iter. Müşteri anahtarlarını yıllık değil sürekli mutabık kılar. TIN format doğrulamasını bir raporlama meselesi olarak değil bir CRM meselesi olarak ele alır. Hattı her ay gölge modda çalıştırırlar; böylece yıllık gönderim, on bir aydır sessizce çalışan kod yolunun aynısıdır.
Bu iki yaklaşım arasındaki fark uyum sunumunda görünmez. Düzeltmelerin maliyetinde, denetim bulgularında, operasyonel risk sermayesinde ve Ocak ayında nöbette kaç kişiye ihtiyacınız olduğunda görünür.
Bunu kuran ekiplere söylediklerim
Sürekli karşılığını gördüğüm birkaç pratik nokta:
- Vergi mukimliğini kaynak sistemde müşteri kaydına iliştirilmiş bir öznitelik değil, birinci sınıf bir alan haline getirin
- TIN formatını yakalama noktasında, yargı bölgesine özgü kurallarla doğrulayın ve doğrulama hatasını geçerli veri değil eksik veri olarak ele alın
- Emareye dayalı sınıflandırmayı bir ETL işine gömülü mantık değil, ayrı ve sürümlenmiş bir kural seti olarak ele alın
- Kontrol eden kişiler grafını müşteri tablosuna düzleştirmek yerine gerçek bir graf modelinde ya da en azından düzgün normalize edilmiş bir ilişkisel yapıda tutun
- Hattın tamamını yıllık değil aylık çalıştırın ve çıktıyı diff'leyin; böylece kayma erken görünür
- Her raporlama dönemi için gönderilen XML'in tam halini, şema sürümünü ve sınıflandırma mantığı sürümünü saklayın; yeniden üretmek zorunda kalacaksınız
FATCA ve CRS daha basit hale gelmeyecek. CRS'e yeni yargı bölgeleri katılmaya devam ediyor. OECD şemayı sürekli rafine ediyor. Tüm bunların üstüne, aynı yapısal sorunlar ve bir kucak dolusu yeni tanımlayıcı baş ağrısıyla birlikte CARF kapsamındaki kripto raporlaması geliyor. Düzgün hat kuran kurumlar CARF'ı artımlı bir değişiklik olarak soğuracak. Yıllık koşturma projeleri kuran kurumlar ise koşturmayı sıfırdan baştan yaşayacak.
Kontrol listesi ile veri hattı aynı konuşmanın parçası. Sadece bu konuşmayı henüz yapmıyorlar.