Uluslararası Bankalararası Telekomünikasyon Derneği (SWIFT) ödeme ağı mimarisi

SWIFT (Society for Worldwide Interbank Financial Telecommunication), dünya genelindeki bankaların başka ülkelerdeki bankalarla finansal işlem yapmak için kullandığı bir mesajlaşma sistemidir. Merkezi Belçika’dadır ve SWIFT kodu olarak adlandırılan 8-11 karakterli tanımlayıcıyla gönderen banka ile alıcı bankayı tanımlar.

SWIFT kodu yaklaşık 1975’te kendine özgü bir formatta geliştirildi, ancak 1994’te ISO 9362 ile uluslararası standart tanımlandı. Daha sonra iki kez daha revize edildi ve bugün kullanılan sürüm 2014 baskısıdır. Ayrıntılı format, Estonya merkezli fintech şirketi Wise’ın (eski adıyla Transferwise) sunduğu aşağıdaki sayfada görülebilir:

https://wise.com/gb/swift-codes/bic-swift-code-checker

İlk 4 karakter bankayı, sonraki 2 karakter ülkeyi, sonraki 2 karakter bölgeyi ve son olarak isteğe bağlı 3 karakter şubeyi gösterir. Örneğin SWIFT kodu SMCOGB2LXXX ise, Birleşik Krallık’taki (GB) SMCO bankasının 2L bölgesindeki XXX şubesini ifade eder. Temelde bankalara verilse de, en büyük talep para transferlerinden geldiği için ülkeler arasında sık para alışverişi yapan çok uluslu büyük şirketler de SWIFT kodu alıp kullanır. Tersinden söylersek, SWIFT ödeme ağından çıkarılmak finansal işlemlere ciddi darbe vurur. İran ve Kuzey Kore’nin ise doğal olarak(?) SWIFT’e erişimi yoktur.

Bu yazı, "Büyük Ölçekli Sistem Tasarımının Temelleri: Sanal Mülakat Örnekleriyle Öğrenmek (System Design Interview)" kitabının yazarı Alex Xu’nun açıkladığı SWIFT sisteminin teknik yapısını anlatıyor.

1. Parayı gönderip alan taraf olan Bank, Bank’tan isteği alıp işleyen Regional Processor (RP) ve RP’den isteği alarak para transferiyle ilgili kayıtları saklayan Slice Processor (SP) bulunur. Kolaylık olması için A tarafı Bank/RP/SP ile B tarafı Bank/RP/SP olduğunu varsayalım.
2. Bank(A), Bank(B)’ye gönderilecek transfer talebini RP(A)’ya yollar. RP(A), isteğin geçerliliğini doğruladıktan sonra isteği SP(A)’ya iletir. SP(A), isteği kaydettikten sonra RP(A)’ya isteğin işlendiğine dair yanıtı, RP(B)’ye ise para transferi talebini gönderir.
3. Yanıtı alan RP(A), Bank A’ya transfer talebinin kabul edildiğine (ACK) ya da reddedildiğine (NAK) dair yanıt gönderir. SP(A)’dan isteği alan RP(B), mesajı geçici olarak sakladıktan sonra (muhtemelen iç log veri yapısına fsync ile yazıyordur) mesaja benzersiz bir numara (MON) atar ve ardından SP(B)’ye iletir.
4. SP(B), MON’un geçerliliğini doğrular ve yetkilendirme (authorization) işlemini yaptıktan sonra RP(B)’ye "Bank B’ye para gönder" mesajını yollar.
5. RP(B), mesajı Bank B’ye iletir. Bank B bunu alıp kaydeder, ardından parayı fiilen öder ve başarılı olup olmadığını (UAK/UNK) RP(B)’ye bildirir.
6. RP(B), transfer sonucuna dair bir report oluşturup SP(B)’ye iletir. SP(B) bunu kaydettikten sonra bir kopyasını SP(A)’ya gönderir. SP(A) da bunu yeniden kaydeder.

Yaklaşık 1975’te yapılmış bir sistem olmasına rağmen, modern event-driven microservice yaklaşımının tüm unsurlarını içeriyor. SP, para transferi taleplerini ve sonuç report’larını mesaj biçiminde saklıyor; RP ise SP’yi kullanarak Bank’ın isteklerine hizmet veriyor. RP yalnızca Bank’ın transfer taleplerini almakla ya da kendi sorumlu olduğu bölgeye gelen transfer taleplerini yine kendi bölgesindeki Bank’a iletmekle görevli. Sonuç olarak para transferiyle ilgili tüm talepler, gönderen taraftaki SP ile alan taraftaki SP’de; hem istek hem de işleme sonucu olacak şekilde birer kez saklanmış oluyor. Bank açısından bakıldığında ise SP hiç görünmüyor.