MicroCustody: Saklama Bankacılığı Platformu

Platform ne yapıyor?

Platform, Portföy Yönetim Şirketleri (PYŞ) ile kurumsal bankalar arasındaki saklama hizmetlerini uçtan uca dijitalleştiriyor. Rol tabanlı erişim kontrolü (RBAC) ve PYŞ bazlı yetkilendirme her şirketin kullanıcısını ve verisini birbirinden ayrık tutarken; fon tanımları, aracı kurum ve komisyon parametreleri ile IBAN ve finansal hesap yapılandırmaları her karşı taraf için yeniden tanımlanmak yerine tek bir merkezi arayüzden yönetiliyor.

Hiçbir veri gözden geçirilmeden işleme girmiyor. Yüklenen tüm veriler standart Maker-Checker (Yükleyici-Onaylayıcı) sürecinden geçiyor; böylece her değişikliğin bir göndericisi, bir onaylayanı ve bir kaydı oluyor. Entegrasyon katmanı EFT ve havale işlemlerini bankacılık çekirdek sistemlerine aktarıyor, PYŞ kaynaklı dosya formatlarını otomatik dönüştürüyor ve bakiye ile işlem verileri için finansal hesap sorgulama servisleri açıyor.

Yetenekler

MicroCustody pilot aşamasında. Aşağıdaki liste platformun tasarlanan yeteneklerini anlatır; bazı parçalar pilotla birlikte tamamlanıyor.

• RBAC ve PYŞ bazlı yetkilendirme — kiracılar arasında segmente edilmiş kullanıcı yönetimi
• Fon tanımlama ve yönetimi — aracı kurum ve komisyon konfigürasyonu
• IBAN ve finansal hesap yönetimi — tek merkezi arayüzden yapılandırma
• Maker-Checker onay süreci — istisnasız her veri operasyonunda
• EFT ve havale entegrasyonu — bankacılık çekirdek sistemleriyle bağlantı
• Otomatik dosya formatı dönüştürme — PYŞ kaynaklı belgeler için
• Finansal hesap sorgulama servisleri — bakiye ve işlem verileri
• Çok kiracılı mimari — tek kurulum üzerinden birden fazla PYŞ

Nasıl inşa edildi?

• Azure üzerinde .NET mikroservis mimarisi
• Tam denetim izi ile PostgreSQL işlemsel veritabanı
• Finansal sistem bağlantısı için olay tabanlı entegrasyon katmanı
• Aynı veri üzerinde çalışan raporlama ve uyumluluk paneli

Maker-Checker bir ekran adımı değil, veri kontrolü

Onay kapısı arayüzde değil veri modelinde uygulanıyor; çünkü arayüz, verinin sisteme girdiği yollardan yalnızca biri — yüklenen bir dosya, bir API çağrısı ve bir toplu iş de aynı tablolara ulaşıyor. Gönderim, canlı kaydı değiştirmiyor. Gönderen kullanıcıyı, hedef kaydı ve öncesi/sonrası içeriğin tamamını taşıyan bekleyen bir değişiklik yazıyor; onay ise bu değişikliği yürürlüğe alan geçişin kendisi ve canlı sürümü yazan tek yol o. Reddedilen bir değişiklik kaybolmuyor, gerekçesiyle birlikte kayıtta kalıyor.

Bunun iki sonucu var. Denetim izi sonradan loglardan derlenmiyor — sürecin zaten üzerinde çalıştığı satırların kendisi olduğu için “bu aracı kurum komisyonunu kim, ne zaman değiştirdi, kim onayladı” sorusu bir soruşturma değil bir sorgu. İkincisi, görevler ayrılığı servis sınırında zorlanıyor: gönderen kendi değişikliğini onaylayamıyor, çünkü geçiş bir düğmeyi gizlemiyor, kimliği kontrol ediyor.

Birbirinden bağımsız iki sınır: ne yapabilirsin, kimin satırına dokunabilirsin

RBAC ile PYŞ kapsamı bilinçli olarak ayrı tutuldu. Roller kullanıcının hangi işlemi çağırabileceğini belirliyor; PYŞ bilgisi ise o işlemin hangi satırlara ulaşabileceğini belirliyor ve bu, her ekranın eklemeyi hatırlaması gereken bir filtre olarak değil, sorgu katmanının altında zorunlu bir koşul olarak uygulanıyor. İkisini tek bir rol matrisinde birleştirmek yaygın kestirme yol ve bedeli iki katlı: her yeni PYŞ tanımlanması gereken rol sayısını katlıyor, unutulan bir filtre de eksik bir menü olmaktan çıkıp kiracılar arası veri sızıntısına dönüşüyor.

Dosya dönüşümü koda dağılmış bir ayrıştırma değil, bir eşleme tanımı

Her PYŞ kendi düzeninde dosya gönderiyor. Karşı taraf başına bir ayrıştırıcının ilk ihtiyaç duyulduğu yerde yaşamasındansa, bir PYŞ’nin formatı bir eşleme tanımı olarak ifade ediliyor ve hat her şeyi tek bir kanonik talimat kaydına indirgiyor; doğrulama, onay ve iletim gibi sonraki adımlar yalnızca bu kanonik biçimi görüyor. Doğrulama satır bazında ve gerekçeli çalışıyor; böylece tek bir bozuk satır aslında sağlam olan bir dosyayı reddettirmiyor ve operatörün eline “yükleme başarısız” yerine neyi düzelteceğinin listesi geçiyor.

Dosya, ayrıştırılmış hâlinin yanında geldiği gibi de saklanıyor. Saklama işi karşı tarafın fiilen ne gönderdiği üzerinden denetleniyor ve bir dönüşüm hatası ancak orijinal veri duruyorsa teşhis edilebiliyor.

Transferde kayıt ve iletim tek bir karar

Onaylanmış talimat ile onu gönderme niyeti aynı PostgreSQL transaction’ında yazılıyor; bankacılık çekirdek sistemine iletim ise bu kayıttan asenkron olarak alınıyor. Bu outbox düzeni, buradaki iki kritik hata durumunu baştan imkânsız kılmak için var: platformda onaylanıp bankaya hiç ulaşmayan bir talimat ve karşılığında onaylanmış bir talimat bulunmayan bir iletim. Yeniden denemeler özgün talimat referansını taşıyor; böylece tekrar iletim ikinci bir transfer olarak değil, tanınan bir tekrar olarak işleniyor. Sonucu bilinmeyen bir gönderim de yeniden göndererek değil durum sorgulanarak kapatılıyor — banka tarafında zaman aşımı ile ret aynı olay değil.

Raporlama defterin kopyasını değil, defteri okuyor

Uyumluluk ve raporlama görünümleri, ayrı tutulan bir aktarımın değil aynı işlemsel verinin üzerindeki okuma modelleri. Raporlama için tutulan bir kopya er ya da geç kaynağından ayrışır; saklama tarafında ise kayıtla çelişen bir rapor, hiç rapor olmamasından kötüdür.