Kiến trúc mạng thanh toán của SWIFT (Hiệp hội Viễn thông Tài chính Liên ngân hàng Toàn cầu)

SWIFT (Society for Worldwide Interbank Financial Telecommunication) là hệ thống nhắn tin mà các ngân hàng trên toàn thế giới sử dụng để thực hiện giao dịch tài chính với các ngân hàng ở quốc gia khác. Tổ chức này đặt trụ sở tại Bỉ và dùng mã định danh dài 8-11 ký tự, gọi là mã SWIFT, để xác định ngân hàng chuyển tiền và ngân hàng nhận tiền.

Mã SWIFT được phát triển vào khoảng năm 1975 theo định dạng riêng, nhưng đến năm 1994, tiêu chuẩn quốc tế ISO 9362 đã được xác lập. Sau đó tiêu chuẩn này được sửa đổi thêm hai lần, và phiên bản hiện đang được sử dụng là bản năm 2014. Có thể xem định dạng cụ thể tại trang dưới đây do công ty fintech Wise (trước đây là Transferwise) của Estonia cung cấp:

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

4 ký tự đầu là ngân hàng. 2 ký tự tiếp theo là quốc gia. 2 ký tự tiếp theo là khu vực. Và cuối cùng là 3 ký tự chi nhánh, có thể có hoặc không. Ví dụ, nếu mã SWIFT là SMCOGB2LXXX thì nó chỉ chi nhánh XXX thuộc khu vực 2L của ngân hàng SMCO tại Vương quốc Anh (GB). Về cơ bản, mã này được cấp cho ngân hàng, nhưng vì nhu cầu lớn nhất là chuyển tiền nên nhiều tập đoàn đa quốc gia lớn, thường xuyên phải chuyển nhận tiền xuyên biên giới, cũng được cấp và sử dụng mã SWIFT. Nói ngược lại, nếu bị loại khỏi mạng thanh toán SWIFT thì hoạt động giao dịch tài chính sẽ chịu ảnh hưởng nặng nề. Trường hợp của Iran và Triều Tiên thì đương nhiên không thể truy cập SWIFT.

Bài viết này trình bày cấu trúc kỹ thuật của hệ thống SWIFT do Alex Xu, tác giả cuốn System Design Interview (『Học thiết kế hệ thống quy mô lớn qua các tình huống phỏng vấn giả định』), giải thích.

1. Có các thành phần gồm Bank là bên gửi/nhận tiền, Regional Processor (RP) là bên nhận yêu cầu từ Bank để xử lý, và Slice Processor (SP) là bên nhận yêu cầu từ RP để lưu trữ các bản ghi liên quan đến chuyển tiền. Để tiện mô tả, giả sử có Bank/RP/SP phía A và Bank/RP/SP phía B.
2. Bank(A) gửi yêu cầu chuyển tiền đến Bank(B) cho RP(A). RP(A) kiểm tra tính hợp lệ của yêu cầu rồi chuyển tiếp sang SP(A). SP(A) lưu yêu cầu, sau đó gửi phản hồi cho RP(A) rằng yêu cầu đã được xử lý, đồng thời gửi yêu cầu chuyển tiền sang RP(B).
3. RP(A) sau khi nhận phản hồi sẽ gửi kết quả cho Bank A rằng yêu cầu chuyển tiền đã được tiếp nhận (ACK) hoặc bị từ chối (NAK). RP(B), sau khi nhận yêu cầu từ SP(A), sẽ tạm thời lưu thông điệp lại, rồi cấp một số định danh duy nhất (MON) cho thông điệp trước khi chuyển sang SP(B).
4. SP(B) kiểm tra tính hợp lệ của MON, thực hiện bước ủy quyền (authorization), rồi gửi cho RP(B) thông điệp “hãy chuyển tiền cho Bank B”.
5. RP(B) chuyển thông điệp tới Bank B. Bank B nhận và lưu lại, sau đó thực sự chi trả tiền và gửi kết quả thành công hay thất bại (UAK/UNK) tới RP(B).
6. RP(B) tạo report kết quả chuyển tiền rồi gửi cho SP(B). SP(B) lưu lại, sau đó chuyển một bản sao cho SP(A). SP(A) lại tiếp tục lưu bản sao đó.

Dù là hệ thống được tạo ra vào khoảng năm 1975, nó đã bao hàm đầy đủ các yếu tố của microservice hướng sự kiện hiện đại. SP lưu các yêu cầu chuyển tiền và report kết quả dưới dạng thông điệp, còn RP dùng SP để cung cấp dịch vụ cho các yêu cầu từ Bank. RP chỉ đảm nhận việc nhận yêu cầu chuyển tiền từ Bank, hoặc chuyển tiếp các yêu cầu chuyển tiền đi vào khu vực mình phụ trách tới các Bank trong chính khu vực đó. Kết quả là mọi yêu cầu liên quan đến chuyển tiền đều được lưu một bản ở SP phía gửi và một bản ở SP phía nhận, cùng với từng kết quả xử lý tương ứng. Từ góc nhìn của Bank thì SP hoàn toàn không lộ diện.