Society for Worldwide Interbank Financial Telecommunication
lastmod 2022-03-07created 2022-03-074 edits
(For Swift, the programming language, see here)
The Society for Worldwide Interbank Financial Telecommunication (SWIFT) is a Belgian cooperative that intermediates international financial transactions between banks. Its headquarters are in La Hulpe, Walloon Brabant, Belgium.
SWIFT payment network architecture
SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a messaging system that banks around the world use to carry out financial transactions with banks in other countries. It is headquartered in Belgium and identifies the sending and receiving banks with 8-11 character identifiers called SWIFT codes.
SWIFT codes were developed in a proprietary format around 1975, but an international standard was defined as ISO 9362 in 1994. It has since been revised twice more, and the version in use today is the 2014 edition. The exact format can be seen on the page below provided by Wise (formerly Transferwise), an Estonian fintech company:
https://wise.com/gb/swift-codes/bic-swift-code-checker
The first 4 characters are the bank. The next 2 are the country. The next 2 are the location. And finally, an optional 3-character branch. For example, a SWIFT code of 'SMCOGB2LXXX' refers to branch XXX of SMCO bank, location 2L, in the United Kingdom (GB). They are basically assigned to banks, but since the largest demand is for remittances, multinational corporations that frequently send and receive money across countries also often obtain and use SWIFT codes - conversely, being expelled from the SWIFT payment network hurts financial transactions. Iran and North Korea naturally(?) cannot access SWIFT.
This text is the technical structure of the SWIFT system as explained by Alex Xu, author of "System Design Interview".
SWIFT_for_cross-border_payments.jpeg
- There is the Bank, the party that sends and receives money; the Regional Processor (RP), which receives and handles requests from the Bank; and the Slice Processor (SP), which receives requests from the RP and stores remittance-related records. For convenience, assume there is a Bank/RP/SP on side A and a Bank/RP/SP on side B.
- Bank(A) sends a remittance request to Bank(B) to RP(A). RP(A) validates the request and forwards it to SP(A). SP(A) stores the request, then sends RP(A) a response that the request has been processed, and sends RP(B) the remittance request.
- Having received the response, RP(A) sends Bank A a response that the remittance request was accepted (ACK) or rejected (NAK). RP(B), having received the request from SP(A), temporarily stores the message (translator's note: probably saving it to an internal log data structure with fsync), assigns the message a unique number (MON), and forwards it to SP(B).
- SP(B) validates the MON, performs authorization, and then sends RP(B) a message saying "send the money to Bank B".
- RP(B) forwards the message to Bank B. Bank B receives and stores it, actually pays out the money, and sends the success status (UAK/UNK) to RP(B).
- RP(B) generates a remittance result report and forwards it to SP(B). SP(B) stores it and forwards a copy to SP(A). SP(A) stores it as well.
Although the system was created around 1975, it contains all the elements of a modern event-driven microservice. The SP stores remittance requests and result reports as messages, and the RP uses the SP to serve the Bank's requests. The RP only receives remittance requests from Banks, or forwards remittance requests that come into its region to the Banks in its region. As a result, for every remittance request, the request and its processing result are each stored once on the sending SP and the receiving SP. From the Bank's point of view, the SP is completely invisible.