Bir düzenleyiciden mektup gelir. Önceki yılın üçüncü çeyreğine ait belirli bir bildirimdeki belirli bir satıra atıfta bulunur. Soru dar kapsamlıdır, adeta cerrahi bir hassasiyettedir: bu rakam neden başka bir raporda beyan edilen toplamdan farklıdır ya da altı ay sonra netleştirilen bir kural karşısında bu risk nasıl sınıflandırılmıştır?
Kâğıt üzerindeki yanıt genellikle bir paragraftır. Bazen tek bir cümle. O paragrafın arkasındaki iş, kurumların aslında ne inşa ettiklerini keşfettikleri yerdir.
Zor Olan Hiçbir Zaman Çıktı Olmadı
Türk bankaları ve sigorta şirketlerindeki düzenleyici hatların çoğu tek bir amaç için tasarlandı: bildirimi zamanında, doğru formatta ve alıcı sistemin doğrulama kurallarını geçecek şekilde üretmek. Bu gerçek bir mühendislik başarısıdır ve küçümsemek istemem. XBRL taksonomileri değişir, EGM sigorta bilgi formatları evrilir, BDDK yeni alanlar ekler ve hat teslim etmeye devam eder.
Ama aynı hattan on sekiz ay sonra kendisi hakkında bir soruyu yanıtlamasını isteyin, sessizliğe bürünür.
- Kaynak tablolar bildirimden bu yana binlerce kez güncellenmiştir.
- Referans veriler — müşteri segmentasyonu, ürün sınıflandırması, risk ağırlıkları — bazen sessizce revize edilmiştir.
- Stored procedure'lara ya da Informatica eşlemelerine kodlanmış iş kuralları, hataları düzeltmek veya yeni düzenlemelere uyum sağlamak için değiştirilmiştir.
- Hat kodunun kendisi üç dört sürüm ilerlemiştir.
- Orijinal mantığı yazan kişi başka bir ekibe ya da başka bir şirkete geçmiştir.
Bu değişikliklerin hiçbiri yanlış değildi. Hareketli bir ortama verilen doğru yanıtlardı. Sorun, ortamın iz bırakmadan hareket etmesiydi.
Bir Düzenleyici Sorusu Aslında Neyi Gerektirir
EGM ya da BDDK hedefli bir soru sorduğunda, buna savunulabilir bir yanıt verebilmek için belirli bir zaman noktasına yeniden inşa edilmiş dört şey gerekir:
- Bildirimi besleyen tam girdi verisi — bu tabloların bugünkü sürümü değil, yeterince yakın bir yedek değil, çıkarım tarihinde var olan satırlar ve değerler.
- O veriyi dönüştüren hat sürümü — hangi stored procedure'lar, hangi eşleme sürümleri, hangi lookup tabloları dahil.
- O anda etkin olan iş kuralları ve parametreler — eşikler, sınıflandırma hiyerarşileri, dışlama listeleri, döviz çevrim kaynakları.
- Yapılan manuel müdahaleler — operasyon ekibinin bir müşterinin TCKN'sinde eski bir biçimlendirme sorunu bulunduğu için 47.382 no'lu kayda uyguladığı geçersiz kılma.
Çoğu kurum bu dördün birini güvenle üretebilir. Bazıları ikisini. Bir yıl önce yapılmış bir bildirim için dördünü birden üretebilen çok azdır.
Somut Örnek
Bir hayat sigortası şirketi, on beş ay öncesine ait bir bildirimdeki belirli bir ürün grubunun rezerv hesaplamasına ilişkin bir soru alır. Düzenleyici, rezervin iki ardışık çeyrek arasında neden belirli bir tutarda değiştiğini anlamak ister.
Cevap bilinebilirdir. Aktüerya ekibi hesaplamayı yeniden yapar ve bir sayı üretir. Ancak sayı, sunulan rakamla küçük bir farkla — belki yüzde 0,3 — örtüşmez. İşte asıl iş şimdi başlar:
- O tarihten bu yana mortalite tablosu güncellendi mi? Evet, sekizinci ayda.
- İskonto eğrisi kaynağı değişti mi? Evet, satıcı beslemesi on birinci ayda taşındı.
- Poliçe durumu anlık görüntü mantığı değiştirildi mi? Altıncı ayda, ödenmiş poliçeleri sessizce yanlış sınıflandıran bir kusur düzeltildi.
- Çıkarım kesim zamanı kaydı mı? Farklı bir yukarı akış sistemini karşılamak için batch penceresi doksan dakika kaydırıldı.
Bunların her biri tek başına savunulabilir. Bir arada ele alındığında ise şirketin, Git geçmişi, DBA değişiklik kayıtları ve e-posta yazışmaları arasında arkeolojik bir kazıya girişmeden kendi rapor ettiği rakamı yeniden üretemeyeceği anlamına gelirler.
Düzenleyiciye verilecek yanıt yazılacaktır. Doğru olacaktır. Ancak yirmi dakikada otomatik olarak üretilen bir rakamı gerekçelendirmek için üç haftalık kıdemli analist zamanı harcanacaktır.
Neyin Korunması Gerekirdi
Çözüm daha fazla depolama değildir. Kurumlar zaten terabaytlarca veri saklıyor. Çözüm, doğru şeyleri bildirimin kendisiyle birlikte korumaktır:
- Çıkarım anındaki girdi verisinin değiştirilemez anlık görüntüleri, bildirim kimliğine bağlı olarak, tam düzenleyici saklama süresi boyunca tutulmalıdır.
- Sürümlenmiş iş kuralları ve referans veriler, sürüm tanımlayıcısı her bildirim eserine damgalanmış olarak.
- Hat kodu hash'leri çıktıların yanında kaydedilmelidir, böylece tam dönüşüm mantığı, yeniden yazılmış olabilecek Git dallarına bağlı kalınmadan geri alınabilir.
- Bir manuel müdahale günlüğü; her geçersiz kılmayı, gerekçesini, yazarını ve zaman damgasını, etkilenen kayıtlara bağlı olarak kayıt altına alır.
- Bir mutabakat izi; raporlanan her rakam için kaynak satırlardan sunulan değere kadar toplama yolunu gösterir.
Bunların hiçbiri teknik olarak zor değildir. Mimari olarak modası geçmiş sayılırlar çünkü görünen işi çıktı üretmek olan bir hatta maliyet ve karmaşıklık eklerler. Görünmeyen iş — çıktıyı sonradan kanıtlamak — çoğu tasarımın ihmal ettiği kısımdır.
Aykırı Görüş
Veri ekipleri kendilerini teslimat üzerinden ölçme eğilimindedir. Sunulan bildirimler, tutturulan tarihler, çözülen doğrulama hataları. Savunulabilirliği de önemsiyorsanız bunlar yanlış metriklerdir. Doğru bildirimi üreten ama kendi mantığını yeniden inşa edemeyen bir hat, varlık kılığına bürünmüş bir yükümlülüktür.
Düzenleyici sorularını en iyi yöneten kurumlar en hızlı hatlara sahip olanlar değildir. Her bildirimi üretildiği andan itibaren hukuki bir eser olarak ele alan ve denetimi dışarıdan cıvatayla eklemek yerine korumayı hattın içine yerleştirenlerdir.
EGM ya da BDDK'dan gelen soru aslında hiçbir zaman yanıtla ilgili değildir. İlk kez yanıtladığınız günde ne gördüyseniz, onu hâlâ görüp göremediğinizle ilgilidir. Çoğu kurum göremez. Bir sonraki mektup gelmeden önce çözülmeye değer sorun budur.