Bir düzenleyici, geçen yılın 3. çeyreğine ait bir BES bildirimi hakkında yazı gönderiyor. Özellikle, belirli bir riskin neden o şekilde sınıflandırıldığını anlamak istiyorlar. Ekibiniz arşivlenmiş çıktıyı çekiyor — sayı, sunulan rakamla eşleşiyor. Güzel. Ardından daha zor soruyu soruyorlar: o gün pipeline'ınızın uyguladığı kuralı bize gösterin.
İşte çoğu kuruluşun, var olduğunu bilmediği bir sorunu keşfettiği yer burasıdır.
Kod Sürümlemesi ile Kural Sürümlemesi Arasındaki Uçurum
Ciddi her finans veya sigorta IT organizasyonunda Git vardır. Her pipeline bir repository'de yaşar, her commit izlenebilir, her deployment tag'lenir. O kısım çözülmüştür.
Neredeyse hiçbir zaman çözülmeyen ise: regülasyon ile kod arasındaki yorum katmanı. Bir krediyi yeniden yapılandırılmış olarak sınıflandıran bir BDDK raporlama pipeline'ını düşünün. Sınıflandırma şunlara bağlıdır:
- Bir toplantıda birinin karar verdiği bir eşik değeri
- Bir genelgenin belirli bir okumasını kodlayan bir CASE ifadesi
- Raporlama ekibinin Excel'de tuttuğu bir eşleme tablosu
- İç denetimin bir sınır durumunu işaretlemesi üzerine üç ay önce uygulanan bir yama
- Bir meslektaşın SQL'in teminatı iki kez saydığını fark etmesi üzerine birinin yaptığı sessiz bir düzeltme
Git kod değişikliğini takip eder. Ancak eşiğin neden 91 değil de 90 gün olduğunu, ekibin genelgenin hangi versiyonunu okuduğunu veya bildirimin gönderildiği gün raporlama sorumlusunun yorumunun ne olduğunu size söylemez.
Çıktının Tek Başına Bir Savunma Olmamasının Nedeni
Türkiye'deki düzenleyiciler — BDDK, SPK, SEDDK — arşivlenmiş bildirimi kanıt olarak kabul etmek yerine giderek daha fazla yeniden inşa soruları soruyor. "Bize mantığınızı gösterin" ile "bize çıktınızı gösterin" aynı şey değildir. Güzelce arşivlenmiş bir XBRL paketi sunan, ancak T zamanındaki sınıflandırma motorunun X kural yorumunu uyguladığını göstermesi istendiğinde başarısız olan firmalar gördüm.
Hata modeli öngörülebilir:
- Pipeline çalışır, çıktı üretir, çıktı arşivlenir.
- İki hafta sonra bir bug keşfedilir. Düzeltme deploy edilir. Kimse bunu düzenleyici mantık değişikliği olarak işaretlemez çünkü "sadece bir bug'dı."
- Altı ay sonra başka bir sınır durumu ortaya çıkar. Birisi netlik için sınıflandırma modülünü yeniden yazar. Davranış mevcut veriler için eşdeğerdir ancak geçmiş veriler için ince şekilde farklıdır.
- On dört ay sonra düzenleyici belirli bir kayıt hakkında soru sorar. Mevcut pipeline'ı arşivlenmiş girdi üzerinde çalıştırırsınız. Çıktı farklıdır. Şimdi nedenini açıklamanız gerekir — ve yapamazsınız, çünkü hangi yorumun ne zaman uygulandığını kimse yazmamıştır.
Firmaların Aslında Sahip Olduğu Şey
Çalıştığım çoğu banka ve sigorta şirketinde gerçek şudur:
- Kod için kaynak kontrolü: evet, olgun, disiplinli.
- Referans veriler için sürüm kontrolü (eşleme tabloları, eşikler, ürün hiyerarşileri): genellikle paylaşımlı bir sürücü, ara sıra geçmişi olmayan bir veritabanı, nadiren düzgün bir SCD Type 2.
- Kural yorumu için sürüm kontrolü (bir CASE ifadesinin arkasındaki neden): birinci sınıf bir eser olarak neredeyse hiç var olmaz.
- Bir bildirimi belirli bir kod + referans veri + yorum paketine bağlamak: temelde mevcut değildir.
Bulguların doğduğu yer bu son noktadır. Düzenleyici sorduğunda, "bu bildirim, 2023-08-14 tarihli eşleme tablosu snapshot'ı kullanılarak, yeniden yapılandırılmış KOBİ kredilerinin ele alınmasına ilişkin INT-2023-07 yorum notu uygulanarak, pipeline sürümü 4.2.1 tarafından üretildi" diyemezsiniz. Yalnızca "işte bugün çalışan kod" diyebilirsiniz.
Gerçek Bir Yeniden İnşa Paketi Nasıl Görünür
Savunulabilir bir bildirim, tek bir manifest'ten yeniden üretilebilir olmalıdır ve şunları içermelidir:
- Bildirimi üreten pipeline kodunun tam Git SHA'sı
- Kullanılan her referans tablosunun, çalışma zamanındaki satır düzeyi durumuyla snapshot'ları
- Yürütme sırasında çözümlenen parametre değerleri (eşikler, tarihler, kesim noktaları)
- Aşikar olmayan herhangi bir kural kodlamasını gerekçelendiren yorum belgesine bağlantı
- Aynı kayıtlar üzerinde çalıştığınızı kanıtlayabilmek için girdi verisinin hash'i
- Arşivlenmiş XBRL'in tahrif edilmediğini kanıtlayabilmek için çıktının hash'i
Bunların çoğu mevcut araçlarla başarılabilir. Çoğu yerde eksik olan, yorum belgesi bağlantısıdır — regülasyon okumasının kendisini, uyum tarafından incelenen ve pipeline metadata'sından referans verilen sürümlenmiş bir eser olarak ele almak.
İşe Yarayan Somut Adımlar
İşe yaradığını gördüğüm uygulamalardan:
- Referans verileri SCD Type 2 semantiği ile dondurun. Her eşleme değişikliği bir geçerlilik-başlangıcı ve geçerlilik-bitişi alır. Pipeline durumu "mevcut" olarak değil, raporlama tarihi itibarıyla sorgular.
- Yorum notlarını kodla aynı repo'da saklayın. Her önemsiz olmayan CASE, her eşik, her sınıflandırma ağacı bir yorum belgesi ID'sine atıfta bulunan bir yorum içerir. Belge sürümlenmiştir. Uyum, değişiklikleri onaylar.
- Her bildirim için bir çalışma manifest'i oluşturun. Çıktıyla birlikte arşivlenen, yeniden inşa için gerekli her hash ve sürüm işaretçisini içeren JSON dosyası.
- Sessiz düzeltmeleri yasaklayın. Sınıflandırma davranışını değiştiren bir "bug fix" bir kural değişikliğidir. Diğer düzenleyici mantık değişiklikleriyle aynı incelemeden geçer. Düzeltme önceki bildirimleri değiştirecek olsaydı, bu bir mühendislik sorusu değil, bir açıklama sorusudur.
- Yeniden inşayı üç ayda bir test edin. Rastgele geçmiş bir bildirim seçin. Manifest'ten yeniden oluşturun. Yapamıyorsanız, düzenleyici bulmadan önce boşluğu bulmuşsunuzdur.
Rahatsız Edici Kısım
Çoğu firma zorlanmadıkça bunu yapmayacaktır. Nedeni organizasyoneldir: referans veriler raporlama ekipleri tarafından, kod IT tarafından, yorumlar uyum tarafından tutulur ve kesişimin sahibi kimse değildir. Manifest, bu üç grubun çıktılarının bağımsız iş akışları değil, bağlı eserler olduğunu kabul etmesini gerektirir.
Bu sahiplik sorusu çözülene kadar sürüm kontrolü sorunu teknik bir sorun değildir. Teknik bir kostüm giymiş bir yönetişim sorunudur. Ve bunu düzeltmeden geçen her çeyrek, yeniden inşa edemeyeceğiniz bildirimler için on dört aylık başka bir sayaç tıklamaya başlar.