Katılımcı İletişim Verisi Sorunu: BES Bilgilendirme Yükümlülükleri, Veri Hattınızın Kanıtlamak Üzere Tasarlanmadığı Bir Raporlama Katmanını Neden Zorunlu Kılıyor?

Türkiye'deki her emeklilik şirketi aynı bilgilendirme mekanizmasını işletiyor: yıllık katılımcı ekstreleri, komisyon değişikliği bildirimleri, fon performans raporları, tahsis onayları, vergi belgeleri. Mevzuat, neyin ne zaman gönderilmesi gerektiği konusunda net. Ancak mevzuatın açıkça belirtmediği — ve neredeyse hiçbir şirketin inşa etmediği — şey şu: üç yıl sonra, belirli bir katılımcının belirli bir tarihte tam olarak ne gördüğünü, bu iletişimi tetikleyen belirli hukuki veya operasyonel olaya bağlı olarak yeniden oluşturabilme kabiliyeti.

İşte bir katılımcı SEDDK'ya şikâyette bulunduğu veya tahkim komisyonunda dava açtığı anda soruna dönüşen boşluk budur.

Tipik BES bilgilendirme yığını ve nerede kırıldığı

Birlikte çalıştığım veya incelediğim şirketlerin çoğunda bilgilendirme katmanı aşağı yukarı şöyle görünür:

• Bir poliçe yönetim sistemi katılımcının güncel durumunu tutar (fon tahsisleri, biriken paylar, komisyon çizelgesi).
• Bir batch iş gecelik, aylık veya yıllık olarak PDF'ler, e-postalar veya SMS içerikleri üretir.
• Bir iletişim ağ geçidi (kurum içi bir dağıtıcı ya da İleti Merkezi, RelateLabs veya bir banka SMS sağlayıcısı gibi bir üçüncü taraf) mesajı gönderir.
• Bir log tablosu şunları kaydeder: katılımcı ID, kanal, zaman damgası, teslimat durumu.

Çoğu şirkette denetim izinin tamamı budur. Eksik olanlara dikkat edin:

• Gönderilen içerik çoğunlukla saklanmaz — yalnızca bir şeyin gönderildiği bilgisi vardır.
• İçeriği üreten girdi verisi anlık görüntüsü her gece bir sonraki batch tarafından üzerine yazılır.
• Düzenleyici veya sözleşmesel tetikleyici (belirli bir yönetim kurulu tarihinde onaylanmış bir komisyon değişikliği, bir fon birleşmesi, belirli bir SEDDK genelgesi kapsamında hukuki bildirim gerekliliği) hiçbir yerde gönderim kaydına bağlanmamıştır.
• O anda kullanılan şablon versiyonu sabitlenmemiştir.

Dolayısıyla bir katılımcı "üç yıl önce bana TEFAS'a bağlı fonumun yönetim ücretinin %1,75 olduğunu söylemiştiniz, şimdi %1,95 kestiğinizi görüyorum" dediğinde, şirket orijinal belgeyi yeniden üretemez. Yalnızca bugünün verisi ve bugünün şablonuyla o geçmiş tarih için ne üretileceğini yeniden üretebilir — ki bu aynı şey değildir ve her denetçi bunu bilir.

Aslında ihtiyaç duyduğunuz üç yeniden yapılandırma

Bir uyuşmazlıktan sağ çıkabilecek bir bilgilendirme katmanının üç soruyu bağımsız olarak yanıtlaması gerekir:

1. Ne gönderdik? Teslim edildiği haliyle bayt-bayt aynı, tam olarak render edilmiş çıktı — PDF, HTML e-posta gövdesi, SMS metni.
2. Neye dayandırdık? Üretim anındaki katılımcının fon pozisyonları, komisyon çizelgesi, katkı geçmişi ve hesaplanan tüm değerlerin anlık görüntüsü.
3. Neden gönderdik? Tetikleyici olay — yıllık döngü, komisyon değişikliği, fon kapanışı, katılımcı kaynaklı tahsis değişikliği, düzenleyici genelge — ilgili kurala veya onaya referansla birlikte.

Çoğu şirket, PDF'i sakladıysa 1. soruyu kısmen yanıtlayabilir. Çok azı adli bir veritabanı geri yüklemesi olmadan 2. soruyu yanıtlayabilir. Neredeyse hiçbiri 3. soruyu yapılandırılmış biçimde yanıtlayamaz.

Veri hattı bunun için neden hiç tasarlanmadı

Sigorta ve emeklilik şirketlerindeki veri mühendisliği ekipleri, tek bir iş için optimize edilmiş ETL veri hatlarını devralır: yarının operasyonları için güncel durumu doğru tutmak. Tarihsel doğruluk bir raporlama sorunu olarak ele alınır, bir iletişim sorunu olarak değil. Bilgilendirme batch'i, ertesi gün güncellenen aynı ambar tablolarından okur ve iletişim ekibi ambarın sonsuza kadar tek doğru kaynak olacağını varsayar.

Öyle değil. İki hafta sonra kaydedilen bir fon NAV düzeltmesi, dünkü ekstrenin yeniden üretildiğinde nasıl görüneceğini sessizce değiştirir. Bir komisyon çizelgesi geçişi eski oranları üzerine yazar. Bir katılımcı birleştirmesi (bir TC kimlik düzeltmesi veya mükerrer kayıt temizliğinden sonra gerçekleşir) eski ID ile eski iletişimler arasındaki bağı yok edebilir.

Bir tahkim sürecinde kendini savunan bir şirketin, iki yıl öncesine ait bir veritabanı yedeğini fiziksel olarak geri yüklemek, paralel bir sunucuda ayağa kaldırmak ve neyin iletildiğini kanıtlamak için manuel olarak bir ekstre yeniden üretmek zorunda kaldığı vakalar gördüm. Bu süreç üç hafta sürdü ve uyuşmazlık konusu meblağdan daha fazlaya mal oldu. Bu, ölçeklenebilir bir savunma stratejisi değildir.

Savunulabilir bir bilgilendirme katmanı nasıl görünür

Çözüm mimaridir, prosedürel değil. Uyum klasörüne daha fazla e-posta göndermek bunu çözmez. İşe yarayan desen şudur:

• Değiştirilemez gönderim kayıtları. Her iletişim; render edilmiş çıktıyı (veya nesne depolamasına işaret eden bir içerik hash'ini), JSON veya Parquet olarak girdi verisi anlık görüntüsünü, şablon versiyon tanımlayıcısını ve tetikleyici olay referansını içeren bir kayıt üretir. Bir kez yazılır, asla güncellenmez.
• Event-sourced tetikleyiciler. Komisyon değişiklikleri, fon aksiyonları ve düzenleyici genelgeler, kendi onay izleri ve yürürlük tarihleri olan birinci sınıf olaylar olarak modellenir. Her gönderim, kendisine yol açan olaya bağlanır.
• Operasyonel depolamadan ayrılmış anlık görüntü depolama. Bilgilendirme anlık görüntüsü, yeniden inşa edilen ambarda değil, yalnızca ekleme yapılabilen bir depoda — versiyonlamalı nesne depolama veya özel bir denetim veritabanında — yaşar.
• Umut değil, test olarak yeniden üretilebilirlik. Rastgele geçmiş gönderimleri seçip saklanan anlık görüntülerden yeniden render ederek bayt eşdeğerliğini doğrulayan aylık bir iş. Test başarısız olursa, düzenleyici sormadan önce bilirsiniz.

Rahatsız edici iş gerekçesi

CFO'lar canları yanmadan denetim altyapısı için bütçe ayırmazlar. Bunu şirket içinde dürüstçe çerçevelemenin yolu "uyum duruşumuzu iyileştirmeliyiz" değil, şudur: bir haftalık hukuk ekibi zamanı, artı bir veritabanı geri yükleme mühendislik eforu, artı bir itibar olayının maliyeti; bilgilendirme veri hattına bir anlık görüntü katmanı eklemenin maliyetine karşı nedir?

Bu hesaplamada yardımcı olduğum her şirkette, anlık görüntü katmanı iki uyuşmazlık davasından daha aza mal oluyor. Türk emeklilik katılımcıları ekstreleri konusunda giderek daha bilinçli hale geliyor ve sosyal medya, bireysel şikâyetleri düzenleyici dikkatine eski kâğıt posta döngüsünün asla izin vermediği kadar hızlı taşıyor. Uyuşmazlık hacmi düşmüyor, artıyor.

Geride kaldıysanız nereden başlamalı

Sahip olmadığınız geçmişi geri doldurmaya çalışmayın. Çizgiyi bugünden çekin ve bu çeyrekten itibaren her gönderimin kanıtlanabilir olacağını taahhüt edin. Ardından:

• BES operasyonlarınızın gönderdiği her iletişim türünü envanterleyin. Çoğu şirket 20 ile 40 arasında farklı şablona sahip olduğunu ve yarısının belgelenmemiş olduğunu keşfeder.
• Her biri için tetikleyiciyi, veri girdilerini ve render edilmiş çıktının mevcut depolamasını belirleyin.
• Anlık görüntü yakalamayı gönderim sonrasında değil, üretim noktasında ekleyin. Gönderim sonrasında yakalamak, potansiyel olarak değiştirilmiş veriyi okumak anlamına gelir.
• Şablonlarınızı uygulama kodu ile aynı disiplinde git'te versiyonlayın ve şablon hash'ini gönderim kaydına sabitleyin.

Bilgilendirme katmanı bir pazarlama kanalı değildir. E-posta ve SMS kullanan, düzenlemeye tabi bir delil sistemidir. Onu birincisi gibi görmeye devam eden şirketler, göndermek için bir makine kurup kanıtlamak için makine kurmayı unuttuklarını, uyuşmazlık uyuşmazlık keşfetmeye devam edecekler.