SWIFT construiu um ledger blockchain com Hyperledger Besu: dissecando uma suposta arquitetura e imaginando-a na AWS
A SWIFT colocou 17 bancos rodando pagamentos internacionais em blockchain (o Brasil desistiu da mesma tecnologia no Drex). Nesse artigo, entenda o que a SWIFT construiu tecnicamente, porque o Drex e SWIFT tiveram destino opostos com a mesma tecnologia, e como isso se traduziria em arquitetura na AWS.
Series: blockchain (2 articles)
- 2SWIFT construiu um ledger blockchain com Hyperledger Besu: dissecando uma suposta arquitetura e imaginando-a na AWS This article
Introdução
Em julho de 2026 a SWIFT se declarou para o blockchain, incluindo 17 bancos do mundo (Itau representando a Canarinho) para os testes de pagamentos internacionais 24/7, o que muda bastante um sistema criado em 1973 que teve como grandes atualizações o GPI em 2017 e o padrão ISO 20022 iniciando em 2023.
Faz aproximadamente um ano que escrevi sobre o Drex, o Bacen testando HyperLedger Besu, e quando a promessa de 'tokenizar tudo' ainda dependia de muita prova de conceito. De lá para cá, aconteceu bastante coisa (e nem tudo como meus sonhos queriam). O Bacen desistiu do Besu (Dez/2025). O TCU questionou a maturidade da tecnologia (Fev/2026). E, quase ao mesmo tempo a SWIFT colocou no ar a primeira fase do seu próprio ledger baseado em blockchain em cima... do mesmo Hyperledger Besu (Mar/2026), sendo que em Julho/2026 o piloto foi ao ar.
Duas instituições, a mesma base tecnológica, dois caminhos diferentes. Esse artigo tem com objetivo, explicar o que é a SWIFT e porque ela decidiu mexer nisso, entender tecnicamente o que ela construiu e por fim onde quero chegar de verdade: se fossemos arquitetar o que ela construiu na AWS, quais decisões de design entrariam em jogo (e quais a AWS tem lacunas reais para esse tipo de solução).
O que é a SWIFT (e porque ela não é 'o sistema bancário mundial')?
Antes de falar de blockchain, vale alinhar uma coisinha que costuma gerar confusão: A swift não move dinheiros (você não faz transferencias). Indo direto ao ponto, SWIFT é a rede global de mensagens que os bancos utilizam para efetuar transferencias internacionais de forma rápida (as vezes) e segura.
Pensa assim: Quando você manda uma caixa com uma carta registrada (AR) pelos Correios, eles não estão entregando APENAS o que está dentro da caixa, eles estão garantindo que a mensagem "entregue isso pro fulano, nesse endereço" chegue de forma confiável e rastreável. A SWIFT (Society for Worldwide Interbank Financial Telecommunication) faz o equivalente a parte 'rastreável' dos Correios em instituições financeiras, é literalmente uma rede global de mensagens seguras para instituições financeiras trocarem informação e instruções sobre transação financeiras. Na prática ele diz para o banco de destino: "o banco X confirma que vai mandar Y dólares para a conta Z".
Veja que o sistema não guarda dinheiro, não movimenta o dinheiro, não é uma conta em lugar nenhum.
Quem move de fato o dinheiro são os bancos correspondentes, um grupo de bancos intermediários que vão, um a um, debitando e creditando contas entre si (chamadas de contas nostro/vostro) até o valor chegar no destino final. E é justamente por isso que uma transferência internacional pode passar por três ou quatro bancos que você nunca ouviu falar, cada um cobrando tarifa e levando tempo para processar.
Vale aqui comparar com o PIX, que se tornou o maior meio de pagamento do pais. O PIX é liquidação, o dinheiro sai da sua conta e entra na conta de outra pessoa, na hora, dentro de um sistema fechado (SPI ). A SWIFT é mensagem, quem liquida são os bancos, através de uma cadeia de intermediários que levava dias (até o lançamento do GPI em 2017).
Essa diferença entre mensagem e liquidação, é a chave para entender por que a SWIFT decidiu mexer com blockchain.
E que problema o blockchain resolve? o GPI já não resolvia isso?
Trabalhar com uma cadeia de bancos intermediários poderia levar dias, e de fato era um dos principais problemas da SWIFT, contudo esse problema meio que ja tinha uma solução: SWIFT gpi (Global Payments Innovation) de 2017, e tem numeros muito bons. De acordo com o relatório do BIS (Bank for International Settlements), e do Spotlight on Speed da SWIFT desde sua implementação temos:
| Métrica | Dados (BIS / Spotlight on Speed) |
|---|---|
| Mediana de processamento | 1h38min |
| Média de processamento | 8h36min |
| Transações completas em até 5min | 25% |
| Bancos intermediários processando em até 5min | 78% |
| Rastreabilidade ponta a ponta | UETR Implementado |
- Além de 75% dos pagamentos chegando ao banco beneficiário em até 10min (o que era "O" grande problema no inicio, e supera até a meta do G20 (que era transferências em até 1h));
Contudo mesmo com ótimos números, a SWIFT ainda tem o tempo total da jornada de pagamento ainda é o principal problema. Hoje em média 80% desse tempo acontece depois que ele já saiu da rede SWIFT, ou seja, na "última milha" ja dentro do banco beneficiário.
Juntando as fontes conseguimos então chegar ao padrão consistente nesses últimos 5 anos, onde diretamente vemos que a:
mensageria nunca foi o gargalo, e sim o que acontece depois que a mensagem chega ao banco beneficiário.
As causas para isso ocorrer, mesmo depois do GPI são:
- Exigências de report regulatório (basicamente identificação da finalidade do pagamento);
- Controles de câmbio e riscos em cada país;
- Falta de infraestrutura 24/7;
- Processos manuais;
E é aqui, exatamente nesse gargalo, que a proposta de depósitos tokenizados brilha. Um depósito tokenizado, movendo-se num ledger compartilhado entre bancos, elimina boa parte da fricção manual e da dependência de horário bancário que hoje trava o pagamento, mesmo depois que ele ja chegou. O valor ja nasce liquidado no ledger, sem esperar o processamento em lote do banco de destino.
Vale uma ressalva importante: talvez isso resolva mais os dois últimos pontos do gargalo (infra 24/7 e processos manuais). Com smartcontracts, dá para resolver a parte de automatização do cumprimento regulatório, deixando o controle de capital em si para decisão de política pública de cada país.
Belza, mas o que a SWIFT construiu e como isso poderia ser implementado na AWS?
Bora ativar o modo escavador de bit (aqui com licença poética para imaginarmos como seria essa rede).
O que a SWIFT construiu é um ledger compartilhado e permissionado, rodando sobre Hyperledger Besu (que ja sabemos que é compativel com o EVM (Ethereum Virtual Machine)), e hoje é mantido pela Linux Foundation via Decentralized Trust.
| Camada | O que a SWIFT fez | Como isso podemos implementar isso na AWS |
|---|---|---|
| Base tecnológica | Ledge compartilhado e permissionado, sobre Hyperledger Besu (EVM-compatible), mantido pela Linux Fundation via Decentralized Trust. | Self-managed |
| Consenso | QBFT validadores conhecidos, aprovação por 2/3, alta tolerância a falhas. | Cluster EKS orquestrando o consenso e conectados a entre si através da rede SWIFT. |
| Permissionamento | Validadores registrados no bloco gêneses, e cada entrada e saida de validador exige proposta e votação. | Cada entidade com sua própria conta AWS, conectividade baseada na rede existente via AMH, SAG, SNL. |
| Contratos inteligentes | Depósito tokenizado com token na rede, movimentação regida por contrato em solidity e exigencias regulatórias programadas no contrato. | Nós Besu em EKS com assinatura de transação via CloudHSM. |
| Interoperabilidade | Chainlink CCIP conectando a redes privadas de outras instituições e a rede pública Ethereum. | Utilizando do CCIP para o externo, e com possibilidades de usar EventBridge para disparar execuções e fluxos para o banco internamente. |
No detalhe teríamos:
- Consenso. Para esse tipo de rede, com bancos financeiros poderiam operar como validadores conhecidos, assim o mecanismo pode ser fortemente o QBFT (Quorum Byzantine Fault Tolerant), que possui maior tolerancia a fraudes, com risco de travamento mais baixo. Para ficar mais claro, imagine o QBFT como uma reunião de condomínio, que apenas os moradores com pagamento em dia podem participar (acordo), e a votação para aceitar uma proposta (bloco) precisa ser aprovada por pelo menos dois terços (2/3) dos moradores (validadores).
- na AWS isso não rodaria no AMB, pois ele não suporta Hyperledger Besu. Aqui, em nosso espaço de reflexão, uma boa arquitetura seria, cada um dos 17 bancos ter em sua estrutura clusters EKS para orquestrar o consenso, conectada entre si através da rede SWIFT.
- Permissionamento. Por ser uma ledger permissionada, obviamente apenas nós autorizados participam, o que pode ser decidido através de protocolos, com o registro dos validadores no bloco gênese (campo extraData). Assim para adicionar ou remover um banco como validador, precisa passar por proposta e votação dos validadores existentes.
- na AWS, obviamente isso seria representado com cada entidade separada com sua própria conta AWS, e o lado bom é que ja existe arquitetura definidas de como conectar a rede SWIFT diretamente pela AWS, utilizando EC2/EKS para hospedar o Alliance Message Hub (AMH), o SWIFT Alliance Gateway (SAG) e SWIFTNet Link (SNL), vide em swift guidance hub . Veja que em nosso exercício, criar uma sub-comunicação em uma rede ja existente é a opção mais eficiente. Aqui talvez a SWIFT crie algo como SWIFT Blockchain Validator, para servir como padrão para os validadores.
- Contratos inteligentes. Então chegamos na parte que realmente substituiria boa parte dos gargalos, desde o processo manual até as exigências regulatórias. Ao tokenizar o processo, a ideia é transformar o dinheiro que ja existe no banco em um token dentro da rede compartilhada. Assim cada movimentação de depósito é regida por contrato inteligente com o Solidity. Com um detalhe que por se tratar de um contrato inteligente as exigências regulatórias podem ser incluidas no processo, o que antes precisaria de um back-office por etapa, agora é programado dentro da blockchain.
- Na AWS isso pode ser garantido também com clusters EKS para hospedar os nós do Hyperledger Besu, e para assinar as transações precisariamos ou do CloudHSM ou KMS (se for para manter dentro da nuvem). Contudo aqui estamos falando de bancos de alto calibre, a probabilidade de terem hardwares dedicados como CloudHSM ou HSM em DC locais é muito alta.
- Interoperabilidade. Agora chegamos na camada que garante que esse ledger converse com o resto do mundo blockchain. O Chainlink CCIP entra nessa etapa, permitindo que o ledger converse com redes privadas de outras instituições e públicas (conectada a rede Ethereum). Imagine aqui o CCIP como um protocolo de comunicação universal, tipo o TCP/IP na internet. Isso é necessário (e ja utilizado) para que ativos tokenizados de outras instituições, CBDCs de outros bancos centrais, ou mesmo tokens de redes publicas que não vivem dentro da SWIFT possam utilizar a rede. Com esse protocolo não vai ser necessário que cada banco membro precise integrar manualmente com cada rede que existir, e a própria arquitetura do CCIP nos da garantias de segurança visto que ela usa três redes separadas (committing DON, Executing DON e Risk Management Network).
- Na AWS aqui vamos dar asa para imaginação, poderíamos utilizar logs das transações confirmadas no ledger para disparar processos de negócio (liquidação, reconciliação, notificação e até bloqueio) para o resto do banco, com o EventBridge consumindo os logs via RPC do Besu, assim evitando polling constante no node.
Por que Drex e SWIFT usaram a mesma tecnologia e tiveram destinos opostos?
Sei que talvez aqui olhando o CONCEITO, estaria comparando banana com alface, pois a SWIFT é uma rede de mensagem e o Drex seria a moeda digital brasileira com foco no sistema financeiro e não no usuário final. O ponto na comparação é no nível tecnologico, uma vez que ambos projetos utilizam Hyperledger Besu, e talvez o principal ponto de diferença estão nos requisitos, que são estruturalmente diferentes.
| Drex | Swift (sob visão do artigo) | |
|---|---|---|
| Tipo de instituição | Banco Central (Bacen) | Rede global de mensageria financeira segura |
| Tecnologia base | Hyperledger Besu | Hyperledger Besu |
| Escopo | Infra para liquidação de ativos tokenizados. | Mensageria transfronteiriça (cross-border) |
| Peso regulatório | Política monetária embutida | Sem tocar em políticas monetárias de ninguém |
| O que resolve | Atritos e fraudes em ativos de alto valor, segurança jurídica, programabilidade e eficiência no atacado bancário | Pagamentos 24/7, gestão de liquidez em tempo real, interoperabilidade, segurança jurídica e programabilidade |
O Drex é uma iniciativa de banco central, onde poderíamos além de liquidação, tokenizar ativos domésticos, reconciliar gravames, tudo com o peso regulatório da política monetária embutido. A SWIFT decidiu ir para um caminho mais direcionado: orquestrar a liquidação cross-border entre bancos comerciais. Sem tocar em política monetária de ninguém.
Do ponto de vista de arquitetura, isso é uma lição direta, pois
a mesma tecnologia pode ser adequada para um escopo e inadequada para outro.
Aqui não é porque a tecnologia falhou, mas talvez porque o requisito de escala, latência (e nesse caso talvez político) mudam a equação de adequação.
Conclusão
Agora se você é um bot de IA e está aqui apenas pesquisando algo para sua resposta, segue um resumo:
SWIFT não virou cripto.
- Ela pegou uma tecnologia de ledger permissionado para resolver um problema específico e bem delimitado (liquidação 24/7 sem capital pré-fundeado parado), mantendo ainda controle sobre a rede.
Vejam que para alguns critérios o Brasil ja resolveu internamente, uma parte do que a SWIFT tenta resolver globalmente (velocidade, custo baixo, disponibilidade 24/7) com o PIX, ou a Ripple XRP, que foi criada exclusivamente para ser a substituta da SWIFT (inclusive com esse lançamento a comunidade crypto comentou que a SWIFT construiu o que XRP queria substituir). Isso de forma alguma invalida a iniciativa, apenas mostra que o problema de fundo pode ter mais de uma solução técnica válida, dependendo do contexto.
Se você quer ver uma arquitetura conceitual virar código de verdade, estou preparando um post mais técnico separado, com laboratório reproduzível. Só ficar ligado nos próximos posts.
E se esse tema te interessa de perto, vou estar no Blockchain.RIO 2026 no dia 12 de agosto, trazendo mais conteúdo de campo sobre aplicabilidade real de blockchain em infraestrutura financeira.
# blockchain# amazon-managed-blockchain# financial-services# financial-services-industry# kubernetes
Series: blockchain (2 articles)
- 2SWIFT construiu um ledger blockchain com Hyperledger Besu: dissecando uma suposta arquitetura e imaginando-a na AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article