Architecture du réseau de paiement interbancaire SWIFT

SWIFT (Society for Worldwide Interbank Financial Telecommunication) est un système de messagerie utilisé par les banques du monde entier pour effectuer des transactions financières avec des banques situées dans d'autres pays. Son siège est en Belgique, et il identifie la banque émettrice et la banque destinataire à l’aide d’un identifiant de 8 à 11 caractères appelé code SWIFT.

Le code SWIFT a été développé vers 1975 selon un format propre, mais une norme internationale a été définie en 1994 sous ISO 9362. Elle a ensuite été révisée deux fois, et la version actuellement utilisée est celle de 2014. Le format détaillé peut être consulté sur la page ci-dessous, fournie par Wise (anciennement Transferwise), une fintech estonienne :

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

Les 4 premiers caractères désignent la banque. Les 2 suivants indiquent le pays. Les 2 suivants la région. Enfin, 3 caractères optionnels indiquent l’agence. Par exemple, si le code SWIFT est SMCOGB2LXXX, il désigne l’agence XXX de la banque SMCO, dans la région 2L, au Royaume-Uni (GB). En principe, ces codes sont attribués aux banques, mais comme le besoin le plus fréquent concerne les virements, de nombreuses grandes multinationales ayant beaucoup d’opérations financières internationales obtiennent également un code SWIFT et l’utilisent. Autrement dit, être exclu du réseau de paiement SWIFT a un impact majeur sur les transactions financières. Dans le cas de l’Iran et de la Corée du Nord, l’accès à SWIFT est naturellement(?) impossible.

Ce texte présente la structure technique du système SWIFT telle qu’expliquée par Alex Xu, auteur de System Design Interview (Apprendre les bases de la conception de systèmes à grande échelle à travers des études de cas d’entretiens simulés).

1. Il existe les Bank, qui sont les parties qui envoient et reçoivent l’argent, les Regional Processor (RP), qui traitent les requêtes reçues des Bank, et les Slice Processor (SP), qui reçoivent les requêtes des RP pour stocker les enregistrements liés aux virements. Pour simplifier, supposons qu’il existe un ensemble Bank/RP/SP côté A et un autre côté B.
2. Bank(A) envoie à RP(A) une demande de virement à destination de Bank(B). RP(A) valide la requête puis la transmet à SP(A). SP(A) enregistre la requête, puis renvoie à RP(A) une réponse indiquant que la demande a été traitée, et envoie à RP(B) la demande de transfert.
3. Après avoir reçu la réponse, RP(A) renvoie à Bank A une réponse indiquant que la demande de virement a été acceptée (ACK) ou rejetée (NAK). De son côté, RP(B), après réception de la requête de SP(A), stocke temporairement le message (note du traducteur : probablement via un fsync dans une structure de log interne), attribue au message un numéro unique (MON), puis le transmet à SP(B).
4. SP(B) vérifie la validité du MON, effectue l’opération d’autorisation, puis envoie à RP(B) un message indiquant : "envoyez l’argent à Bank B".
5. RP(B) transmet le message à Bank B. Bank B le reçoit, l’enregistre, effectue effectivement le paiement, puis transmet à RP(B) le résultat, succès ou échec (UAK/UNK).
6. RP(B) génère un rapport de résultat du virement et le transmet à SP(B). SP(B) l’enregistre puis en transmet une copie à SP(A). SP(A) l’enregistre à son tour.

Bien que ce système ait été conçu vers 1975, il contient déjà tous les éléments d’une architecture moderne de microservices orientés événements. Les SP stockent, sous forme de messages, les demandes de virement et les rapports de résultat, tandis que les RP utilisent les SP pour fournir des services en réponse aux requêtes des Bank. Les RP se contentent de recevoir les demandes de virement des Bank ou de transmettre aux Bank de leur zone les demandes de virement entrantes relevant de cette même zone. Au final, pour chaque demande liée à un virement, la requête et son résultat de traitement sont chacun enregistrés à la fois dans le SP côté émetteur et dans le SP côté destinataire. Du point de vue des Bank, les SP restent totalement invisibles.