สถาปัตยกรรมเครือข่ายการชำระเงินของ SWIFT

SWIFT (Society for Worldwide Interbank Financial Telecommunication) คือระบบรับส่งข้อความที่ธนาคารทั่วโลกใช้ในการทำธุรกรรมทางการเงินกับธนาคารในประเทศอื่น มีสำนักงานใหญ่ในเบลเยียม และใช้รหัสระบุ 8-11 หลักที่เรียกว่า SWIFT code เพื่อระบุธนาคารผู้โอนและธนาคารผู้รับ

SWIFT code ถูกพัฒนาขึ้นราวปี 1975 ในรูปแบบเฉพาะของตนเอง แต่ในปี 1994 ได้มีการกำหนดมาตรฐานสากลเป็น ISO 9362 หลังจากนั้นมีการปรับปรุงอีกสองครั้ง และเวอร์ชันที่ใช้อยู่ในปัจจุบันคือฉบับปี 2014 รายละเอียดรูปแบบสามารถดูได้จากหน้าด้านล่างที่ให้บริการโดย Wise (เดิมคือ Transferwise) บริษัทฟินเทคจากเอสโตเนีย:

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

4 ตัวแรกคือธนาคาร 2 ตัวถัดมาคือประเทศ 2 ตัวถัดมาคือภูมิภาค และสุดท้ายคือรหัสสาขา 3 ตัวซึ่งเป็นตัวเลือก ตัวอย่างเช่น หาก SWIFT code คือ SMCOGB2LXXX ก็จะหมายถึงสาขา XXX ของธนาคาร SMCO ในภูมิภาค 2L ของสหราชอาณาจักร (GB) โดยพื้นฐานแล้วรหัสดังกล่าวถูกกำหนดให้กับธนาคาร แต่เนื่องจากความต้องการใช้งานส่วนใหญ่คือการโอนเงิน บริษัทข้ามชาติขนาดใหญ่ที่ต้องรับส่งเงินระหว่างประเทศบ่อยครั้งก็มักขอรับ SWIFT code มาใช้งานด้วยเช่นกัน — พูดกลับกันก็คือ หากถูกตัดออกจากเครือข่ายการชำระเงิน SWIFT ก็จะกระทบต่อธุรกรรมทางการเงินอย่างหนัก กรณีของอิหร่านและเกาหลีเหนือย่อมไม่สามารถเข้าถึง SWIFT ได้

บทความนี้อธิบายโครงสร้างเชิงเทคนิคของระบบ SWIFT โดย Alex Xu ผู้เขียนหนังสือ System Design Interview

1. มีองค์ประกอบคือ Bank ซึ่งเป็นคู่กรณีที่รับส่งเงิน, Regional Processor (RP) ที่รับคำขอจาก Bank แล้วประมวลผล, และ Slice Processor (SP) ที่รับคำขอจาก RP แล้วเก็บบันทึกที่เกี่ยวข้องกับการโอนเงิน เพื่อความสะดวก สมมติว่ามี Bank/RP/SP ฝั่ง A และ Bank/RP/SP ฝั่ง B
2. Bank(A) ส่งคำขอโอนเงินไปยัง Bank(B) ผ่าน RP(A) โดย RP(A) จะตรวจสอบความถูกต้องของคำขอ แล้วส่งต่อไปยัง SP(A) จากนั้น SP(A) จะบันทึกคำขอ ตอบกลับ RP(A) ว่าคำขอได้รับการประมวลผลแล้ว และส่งคำขอโอนเงินไปยัง RP(B)
3. เมื่อ RP(A) ได้รับคำตอบ ก็จะส่งกลับไปยัง Bank A ว่าคำขอโอนเงินถูกรับไว้ (ACK) หรือถูกปฏิเสธ (NAK) ส่วน RP(B) ที่ได้รับคำขอจาก SP(A) จะเก็บข้อความไว้ชั่วคราว แล้วออกหมายเลขเฉพาะของข้อความนั้น (MON) ก่อนส่งต่อไปยัง SP(B)
4. SP(B) จะตรวจสอบความถูกต้องของ MON และทำขั้นตอน authorization ก่อนส่งข้อความไปยัง RP(B) ว่า "ให้ส่งเงินไปยัง Bank B"
5. RP(B) ส่งข้อความต่อไปยัง Bank B โดย Bank B จะรับข้อความไปเก็บไว้ จากนั้นจ่ายเงินจริง และส่งผลสำเร็จหรือไม่สำเร็จ (UAK/UNK) กลับไปยัง RP(B)
6. RP(B) สร้างรายงานผลการโอนแล้วส่งให้ SP(B) จากนั้น SP(B) จะบันทึกไว้และส่งสำเนาไปยัง SP(A) และ SP(A) ก็จะบันทึกอีกครั้ง

แม้จะเป็นระบบที่สร้างขึ้นราวปี 1975 แต่ก็มีองค์ประกอบของ event-driven microservice สมัยใหม่ครบถ้วน SP เก็บคำขอโอนและรายงานผลในรูปแบบข้อความ ส่วน RP ใช้ SP เพื่อให้บริการตามคำขอของ Bank หน้าที่ของ RP มีเพียงรับคำขอโอนจาก Bank หรือรับคำขอโอนที่เข้ามาในเขตที่ตนรับผิดชอบ แล้วส่งต่อให้ Bank ในเขตของตนเองเท่านั้น ผลลัพธ์คือคำขอที่เกี่ยวข้องกับการโอนเงินทั้งหมดจะถูกบันทึกทั้งที่ SP ฝั่งผู้ส่งและ SP ฝั่งผู้รับ โดยมีทั้งตัวคำขอและผลการประมวลผลอย่างละหนึ่งชุด ในมุมมองของ Bank จะมองไม่เห็น SP เลย