Paralel Gönderim Sorunu: FATCA, CRS, HAYMER ve GEV'i Aynı Takvim Penceresinde Çalıştırmak Neden Bir Zamanlama Değil, Mimari Sorunudur?

Her yıl, Mart sonu ile Haziran başı arasında bir yerlerde, Türk finans kurumlarında aynı konuşma yaşanır. Operasyon tarafından biri, son teslim tarihlerini daha rahat karşılamak için yasal gönderimleri "paralelleştirebilir miyiz" diye sorar. IT tarafından biri, bol miktarda işlem gücümüz olduğunu doğrular. Uyum tarafından biri onaylar. Ve üç hafta sonra, bir dosyalamada bir düzeltme belirir ve diğer üçünü sessizce zehirler.

FATCA, CRS, HAYMER ve GEV boru hatlarını aynı anda yeterince uzun süredir yönettiğim için bunu açıkça söyleyebilirim: sorun zamanlama değildir. Mimaridir. Ve çoğu kurum bu dördünü sadece aynı takvimi paylaşan bağımsız iş yükleri olarak ele aldığı için yanılır.

Bunlar bağımsız değildir. Durum paylaşırlar.

Bağımsızlık yanılsaması

Kağıt üzerinde, her rejimin kendi kapsamı, kendi formatı ve kendi alıcısı vardır:

• FATCA — ABD kişileri, yerel vergi otoritesi aracılığıyla IRS'e raporlanır
• CRS — mukim olmayan hesap sahipleri, partner yargı bölgelerine raporlanır
• HAYMER — yurt içi gerçek faydalanıcı sicili
• GEV — hesap ve işlem verileri için gelir idaresi raporlaması

Farklı formlar, farklı XSD'ler, aynı pencere içinde farklı son teslim tarihleri. Dört paralel iz gibi görünür. Onlara böyle davranırsanız, hepsinin aynı temel gerçekten okuduğunu acı bir şekilde keşfedersiniz: mutabakatı yapılmış katılımcı durumundan.

Hesap sahibi sınıflandırması, TIN geçerliliği, mukimlik tespiti, kontrol eden kişi yapıları, CRS altında varlık türü ile HAYMER altında varlık türü — bunlar dört ayrı veri ürünü değildir. Bunlar aynı müşteri ana verisinin, dört düzenleyici için filtrelenmiş ve yeniden şekillendirilmiş dört projeksiyonudur.

Bağlanma aslında nerede yaşıyor

Gönderim pencerelerini yok eden şey, gizli bağlanmalardır:

1. Paylaşılan referans verisi. Ülke kodları, FI tanımlayıcıları, öz beyan durumu, belgesiz hesaplar için curing mantığı. Eğer FATCA düzeltmesi 12 Mayıs'ta bir hesap sahibini recalcitrant'tan uyumluya yeniden sınıflandırırsa, aynı sahip için CRS mukimlik mantığı hâlâ 1 Mayıs anlık görüntüsüne karşı çalışıyor olamaz.

2. Paylaşılan mutabakat durumu. Dört boru hattının hepsi dönem sonu bakiyelerine ve toplu işlem toplamlarına bağımlıdır. Eğer GEV mutabakatı bir kurumsal hesapta bir muhasebe hatası ortaya çıkarırsa, bu düzeltme CRS toplu raporlamasına ve potansiyel olarak HAYMER'in gerçek faydalanıcı eşiklerine yayılır.

3. Paylaşılan düzeltme semantiği. Ekipleri hazırlıksız yakalayan budur. Bir FATCA düzeltme dosyalaması, sizinle IRS arasında özel bir olay değildir. Eğer temel veri noktası FATCA'da yanlıştıysa, CRS'de de yanlıştı, muhtemelen GEV'de de. Birini, diğerlerini de yasal olarak düzeltmek zorunda kalmadan düzeltemezsiniz. Dosyalamalar arasındaki sessiz sapma, geç dosyalamadan daha büyük bir sorundur.

4. Paylaşılan insan inceleme kapasitesi. CRS altında varlık sınıflandırmasını anlayan aynı üç veya dört kişi, onu HAYMER altında da anlar. Boru hatlarını paralel çalıştırmak, beyinlerini paralelleştirmez.

Zamanlama öncelikli yaklaşım ve neden başarısız olur

Gördüğüm — ve dürüst olmak gerekirse erken dönemde denediğim — yaygın örüntü şudur: paylaşılan bir takvim görünümü oluşturmak, iç son teslim tarihlerini kademeli hale getirmek, tampon günler eklemek ve her boru hattını bağımsız bir Airflow DAG'ı veya SSIS paketi olarak ele almak. Gerektiğinde ekstra işlem gücü. Sıkışıklıkta ekstra eller.

Pratikte ne olur:

• Boru Hattı A önce biter, gönderim yapılır.
• Boru Hattı B yarıdayken biri paylaşılan sınıflandırma mantığında bir kusur bulur.
• Düzeltme B'nin dalına gider. A zaten dosyalanmıştır.
• C ve D düzeltmeyi B'den alır, ama şimdi A, C ve D ile tutarsızdır.
• İki hafta sonra, C ve D ile uzlaştırmak için A üzerinde bir düzeltme dosyalıyorsunuz ve düzeltmenin kendisi B ile yeni bir tutarsızlık yaratıyor çünkü B ara bir durumda dondurulmuştu.

Bu bir varsayım değil. Yanlış yönetilmiş bir gönderim penceresinin içeriden görünüşü budur. Ve olur çünkü takvim tasarım artefaktı olarak ele alınmıştır.

Bağımlılık grafiği yaklaşımı

Yeniden çerçeveleme: dört gönderimi, kenarları zaman bağımlılıkları değil, veri bağımlılıkları olan bir DAG'daki düğümler olarak modelleyin.

Somut olarak bu şu anlama gelir:

• Sürümlenmiş, tek bir mutabakat yapılmış katılımcı durumu. Her boru hattı, müşteri ve hesap ana verisinin değişmez, sürümlenmiş bir anlık görüntüsünden okur. Düzeltmeler anlık görüntüyü değiştirmez; yeni bir sürüm oluştururlar. O zaman dört boru hattı da açık sürümlere sabitlenebilir ve sapma tesadüfi değil, tespit edilebilirdir.

• Sınıflandırma mantığı tek bir yerde yaşar. FATCA indicia kontrolleri, CRS mukimlik tespiti, HAYMER kontrol eden kişi türetmesi, GEV hesap türü eşlemesi — bunlar sürümlenmiş duruma karşı çalışır ve kendi sürümlenmiş çıktılarını üretir. "Bu varlık bir Finansal Kuruluş mudur" mantığını üç kez yeniden uygulamazsınız.

• Düzeltmeler dosyalamalar değil, grafik işlemleridir. Bir kusur bulunduğunda iş akışı şudur: etkilenen anlık görüntü sürümünü belirle, düzeltilmiş bir sürüm üret, etkilenen kayıtlara dokunan her aşağı akış sınıflandırmasını ve her aşağı akış dosyalamasını yeniden oynat. Eğer FATCA zaten gönderildiyse, yeniden oynatma size şimdi IRS'e hangi düzeltmeleri borçlu olduğunuzu tam olarak söyler — ve aynı yeniden oynatma, göndermeden önce CRS, HAYMER ve GEV'in ne borçlu olduğunu size söyler.

• Gönderim sırası takvimi değil, grafiği takip eder. Düzenleyicinin son teslim tarihi dış sınırı belirler. İç sıra, hangi dosyalamaların durumun en kararlı alt kümesine bağımlı olduğuna göre belirlenir. Deneyimlerime göre, HAYMER mümkün olan yerde en sona gitmelidir, çünkü gerçek faydalanıcı çözümlemesi yukarı akış düzeltmelerine en hassas olanıdır. FATCA ve CRS birlikte kilitlenmeli ve operasyonel kısıtlamaların izin verdiği kadar yakın zamanda gönderilmelidir, çünkü örtüşmeleri en büyüktür.

Bu operasyonel olarak neyi değiştirir

Dört boru hattı bir grafik olarak modellendiğinde:

• 10 Mayıs'ta bulunan bir kusur paniğe yol açmaz. Bir sürüm yükseltmesi ve yeniden oynatma tetikler. Yeniden oynatma, tek bir XML'e dokunmadan önce patlama yarıçapını size söyler.
• Son teslim tarihinden sonra dosyalanan düzeltmeler, kahramanca manuel mutabakatla değil, tasarım gereği rejimler arasında tutarlıdır.
• Gönderim penceresi paralel yangın söndürme dönemi olmaktan çıkar ve kararlı bir duruma karşı sıralı sürümler dönemi haline gelir.
• Yeni rejimler — ve yeni rejimler olacak — beşinci bir paralel iz haline gelmek yerine aynı grafiğe bağlanır.

Rahatsız edici kısım

Bu, kolayca satabileceğiniz bir proje değildir. Yöneticiler son teslim tarihlerini karşılayan dört çalışan boru hattı görür ve neden temeli yeniden inşa etmek istediğinizi sorar. Dürüst cevap, boru hatlarının düşük düzeltme hacminin tesadüfüyle son teslim tarihlerini karşıladığı ve ciddi bir veri kusuru olan ilk yılın, düzenleyicilerin sonunda fark edeceği bir rejimler arası tutarsızlık üreteceğidir.

Yasal raporlamayı bir mimari sorunu olarak ele alan kurumlar daha temiz düzeltmeler dosyalar ve gönderim pencerelerini rahat uykuda geçirir. Onu bir zamanlama sorunu olarak ele alanlar her yıl daha fazla insan işe alır ve aynı yangının biraz farklı bir köşede tekrar tekrar başlamasına şaşırırlar.

Son teslim tarihi kısıt değildir. Paylaşılan durum kısıttır. Bunun için tasarım yapın, takvim kendi başının çaresine bakar.