Arquitetura da rede de pagamentos da Society for Worldwide Interbank Financial Telecommunication (SWIFT)

A SWIFT (Society for Worldwide Interbank Financial Telecommunication) é um sistema de mensageria usado por bancos do mundo todo para realizar transações financeiras com bancos localizados em outros países. Sua sede fica na Bélgica, e ela identifica o banco remetente e o banco destinatário por meio de um identificador de 8 a 11 caracteres chamado código SWIFT.

O código SWIFT foi desenvolvido por volta de 1975 em um formato próprio, mas em 1994 o padrão internacional foi definido como ISO 9362. Depois disso, ele foi revisado mais duas vezes, e a versão usada atualmente é a edição de 2014. O formato detalhado pode ser visto na página abaixo, fornecida pela fintech estoniana Wise (antiga Transferwise):

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

Os 4 primeiros caracteres indicam o banco. Os 2 seguintes, o país. Os 2 seguintes, a região. E por fim, um código opcional de 3 caracteres para a agência. Por exemplo, se o código SWIFT for SMCOGB2LXXX, ele indica a agência XXX do banco SMCO, na região 2L, no Reino Unido (GB). Em princípio ele é atribuído a bancos, mas como a maior demanda é por transferências, muitas multinacionais que frequentemente precisam enviar e receber dinheiro entre países também obtêm e usam códigos SWIFT. Em outras palavras, ser excluído da rede de pagamentos SWIFT causa um grande impacto nas transações financeiras. No caso do Irã e da Coreia do Norte, naturalmente(?) o acesso à SWIFT é impossível.

Este texto explica a estrutura técnica do sistema SWIFT, apresentada por Alex Xu, autor de System Design Interview (『Aprendendo os fundamentos do projeto de sistemas em larga escala por meio de casos de entrevistas simuladas』).

1. Existem o Bank, que é a parte que envia e recebe dinheiro; o Regional Processor (RP), que recebe e processa as solicitações do Bank; e o Slice Processor (SP), que recebe as solicitações do RP e armazena os registros relacionados à remessa. Para simplificar, vamos supor que existam Bank/RP/SP do lado A e Bank/RP/SP do lado B.
2. O Bank(A) envia ao RP(A) uma solicitação de transferência para o Bank(B). O RP(A) valida a solicitação e depois a encaminha ao SP(A). O SP(A) armazena a solicitação, responde ao RP(A) que ela foi processada, e envia ao RP(B) a solicitação de transferência.
3. Após receber a resposta, o RP(A) envia ao Bank A uma resposta informando que a solicitação de transferência foi aceita (ACK) ou rejeitada (NAK). O RP(B), ao receber a solicitação do SP(A), armazena temporariamente a mensagem (nota do tradutor: provavelmente em uma estrutura interna de log com persistência via fsync), emite um número único (MON) para a mensagem e então a encaminha ao SP(B).
4. O SP(B) valida a integridade do MON, executa o processo de autorização e depois envia ao RP(B) a mensagem “envie o dinheiro ao Bank B”.
5. O RP(B) transmite a mensagem ao Bank B. O Bank B a recebe, armazena, efetua de fato o pagamento e informa o resultado (UAK/UNK) ao RP(B).
6. O RP(B) gera um relatório do resultado da transferência e o envia ao SP(B). O SP(B) o armazena e depois envia uma cópia ao SP(A). O SP(A) então o armazena novamente.

Embora seja um sistema criado por volta de 1975, ele já contém todos os elementos de uma arquitetura moderna de microsserviços orientada a eventos. O SP armazena, em forma de mensagens, as solicitações de transferência e os relatórios de resultado, e o RP usa o SP para prestar serviço às solicitações do Bank. O RP apenas recebe as solicitações de transferência do Bank ou encaminha às instituições bancárias sob sua responsabilidade as solicitações de transferência que entraram em sua área. Como resultado, todas as solicitações relacionadas a transferências acabam tendo tanto o pedido quanto o resultado do processamento armazenados uma vez no SP do lado que envia e uma vez no SP do lado que recebe. Do ponto de vista do Bank, o SP é totalmente invisível.