Arsitektur jaringan pembayaran Society for Worldwide Interbank Financial Telecommunication (SWIFT)

SWIFT (Society for Worldwide Interbank Financial Telecommunication) adalah sistem pesan yang digunakan bank-bank di seluruh dunia untuk melakukan transaksi keuangan dengan bank di negara lain. Kantor pusatnya berada di Belgia, dan bank pengirim serta bank penerima diidentifikasi dengan pengenal 8-11 karakter yang disebut kode SWIFT.

Kode SWIFT dikembangkan sekitar tahun 1975 dengan format tersendiri, tetapi pada 1994 standar internasionalnya didefinisikan sebagai ISO 9362. Setelah itu direvisi dua kali lagi, dan versi yang digunakan saat ini adalah edisi 2014. Format detailnya dapat dilihat di halaman berikut yang disediakan oleh perusahaan fintech Estonia, Wise (sebelumnya Transferwise):

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

Empat karakter pertama menunjukkan bank. Dua karakter berikutnya menunjukkan negara. Dua karakter berikutnya menunjukkan wilayah. Dan terakhir, tiga karakter cabang yang bersifat opsional. Misalnya, jika kode SWIFT adalah 'SMCOGB2LXXX', itu merujuk ke cabang XXX dari bank SMCO di wilayah 2L, Britania Raya (GB). Pada dasarnya ini diberikan kepada bank, tetapi karena kebutuhan terbesar adalah remitansi, banyak perusahaan multinasional besar yang sering perlu mengirim dan menerima uang lintas negara juga mendapatkan dan menggunakan kode SWIFT. Dengan kata lain, jika dikeluarkan dari jaringan pembayaran SWIFT, aktivitas transaksi keuangan akan terkena dampak besar. Dalam kasus Iran dan Korea Utara, tentu saja(?) akses ke SWIFT tidak dimungkinkan.

Tulisan ini membahas struktur teknis sistem SWIFT sebagaimana dijelaskan oleh Alex Xu, penulis System Design Interview, yang diterjemahkan di Korea sebagai 『Dasar-Dasar Perancangan Sistem Skala Besar yang Dipelajari Melalui Contoh Wawancara Simulasi』.

1. Ada Bank sebagai pihak yang mengirim dan menerima uang, Regional Processor (RP) yang memproses permintaan dari Bank, dan Slice Processor (SP) yang menerima permintaan dari RP lalu menyimpan catatan terkait transfer. Untuk memudahkan, anggap ada Bank/RP/SP pihak A dan Bank/RP/SP pihak B.
2. Bank(A) mengirim permintaan transfer ke RP(A) untuk dikirim ke Bank(B). RP(A) memverifikasi validitas permintaan lalu meneruskannya ke SP(A). SP(A) menyimpan permintaan tersebut, lalu mengirim respons ke RP(A) bahwa permintaan telah diproses, dan mengirim permintaan transfer ke RP(B).
3. Setelah menerima respons, RP(A) mengirim respons ke Bank A bahwa permintaan transfer telah diterima (ACK) atau ditolak (NAK). RP(B), yang menerima permintaan dari SP(A), menyimpan pesan itu sementara (catatan penerjemah: kemungkinan disimpan dengan fsync di struktur data log internal), lalu menerbitkan nomor unik (MON) untuk pesan tersebut dan meneruskannya ke SP(B).
4. SP(B) memverifikasi validitas MON, melakukan proses authorization, lalu mengirim pesan ke RP(B) untuk "mengirim uang ke Bank B".
5. RP(B) meneruskan pesan itu ke Bank B. Bank B menerimanya, menyimpannya, lalu benar-benar membayarkan uangnya dan mengirim hasil sukses/gagal (UAK/UNK) ke RP(B).
6. RP(B) membuat report hasil transfer lalu mengirimkannya ke SP(B). SP(B) menyimpannya lalu mengirim salinannya ke SP(A). SP(A) kemudian menyimpannya lagi.

Meskipun ini adalah sistem yang dibuat sekitar tahun 1975, semua unsur microservice modern yang event-driven sudah ada di dalamnya. SP menyimpan permintaan transfer dan report hasil dalam bentuk pesan, dan RP menggunakan SP untuk menyediakan layanan atas permintaan dari Bank. RP hanya berperan menerima permintaan transfer dari Bank, atau meminta Bank di wilayah yang menjadi tanggung jawabnya untuk memproses permintaan transfer yang masuk ke wilayah tersebut. Hasilnya, semua permintaan terkait transfer, beserta hasil pemrosesannya, masing-masing disimpan satu kali di SP pihak pengirim dan SP pihak penerima. Dari sudut pandang Bank, SP sama sekali tidak terlihat.