Intro
In July 2026, Swift went live with blockchain, including 17 banks worldwide (Itaú representing Brazil) for 24/7 international payment testing, a major shift for a system created in 1973 whose biggest updates were gpi in 2017 and the ISO 20022 standard, which started rolling out in 2023.
About a year ago I wrote about Drex, Bacen (Brazil's Central Bank) testing Hyperledger Besu, and how much the promise of "tokenizing everything" still depended on a lot of proof-of-concept work. Since then, a lot has happened, and not all of it the way I'd hoped. Bacen walked away from Besu (Dec/2025). The TCU (Brazil's federal audit court) questioned the technology's maturity (Feb/2026). And, almost at the same time, Swift launched the first phase of its own blockchain-based ledger on top of... the same Hyperledger Besu (Mar/2026), with the pilot going live in July/2026.
Two institutions, the same technological base, two different paths. This article has three goals: explain what Swift is and why it decided to move on this, technically understand what it built, and finally get to where I really want to go, if we were to architect what it built on AWS, what design decisions would come into play (and where AWS has real gaps for this kind of solution).
What Is Swift, and Why Isn't It "the Global Banking System"?
Before getting into blockchain, it's worth clearing up something that often causes confusion: Swift doesn't move money, you don't make transfers through it. To put it plainly, Swift is the global messaging network banks use to make international transfers quickly (sometimes) and securely.
Think of it this way: when you send a registered letter through the mail, the postal service isn't just delivering what's inside the envelope, it's guaranteeing that the message "deliver this to so-and-so, at this address" arrives reliably and traceably. Swift (Society for Worldwide Interbank Financial Telecommunication) is the equivalent of that "traceable" layer for financial institutions, it's literally a secure global messaging network for financial institutions to exchange information and instructions about financial transactions. In practice, it tells the destination bank: "Bank X confirms it will send Y dollars to account Z."
Notice that the system doesn't hold money, doesn't move money, isn't an account anywhere.
The banks that actually move the money are correspondent banks, a chain of intermediary banks that, one by one, debit and credit accounts with each other (called nostro/vostro accounts) until the amount reaches its final destination. That's exactly why an international transfer can pass through three or four banks you've never heard of, each one charging a fee and taking time to process.
It's worth comparing this to PIX, which has become the largest payment method in Brazil. PIX is settlement, the money leaves your account and lands in someone else's account, instantly, inside a closed system (SPI). Swift is messaging, the banks are the ones that settle, through a chain of intermediaries that used to take days (until gpi launched in 2017).
This difference between messaging and settlement is the key to understanding why Swift decided to move on blockchain.
What Problem Does Blockchain Solve? Didn't gpi Already Solve This?
Working through a chain of intermediary banks could take days, and that was indeed one of Swift's main problems, but this problem already had something of a solution: Swift gpi (Global Payments Innovation), launched in 2017, and its numbers are genuinely good. According to the BIS (Bank for International Settlements) report and Swift's own Spotlight on Speed report, since gpi's implementation we have:
| Metric | Data (BIS / Spotlight on Speed) |
|---|---|
| Median processing time | 1h38min |
| Average processing time | 8h36min |
| Transactions completed within 5 minutes | 25% |
| Intermediary banks processing within 5 minutes | 78% |
| End-to-end traceability | UETR implemented |
On top of that, 75% of payments now reach the beneficiary bank within 10 minutes, which was the big problem at the outset, and even beats the G20's target (which called for transfers within 1 hour).
Still, even with great numbers, Swift's real remaining problem is the total time of a payment's journey. Today, on average, 80% of that time happens after the payment has already left the Swift network, in other words, in the "last mile," once it's already inside the beneficiary bank.
Putting the sources together, a consistent pattern emerges over the last 5 years: messaging was never the bottleneck, what happens after the message reaches the beneficiary bank is.
Even after gpi, the causes for this are:
- Regulatory reporting requirements (basically, identifying the purpose of the payment);
- Foreign exchange controls and country-specific risk rules;
- Lack of 24/7 infrastructure;
- Manual processes.
And this is precisely the bottleneck where the tokenized deposit proposal shines. A tokenized deposit, moving on a ledger shared between banks, eliminates much of the manual friction and dependency on banking hours that today holds up a payment even after it's already arrived. The value is already settled on the ledger, without waiting for the destination bank's batch processing.
One important caveat: this may solve the last two points of the bottleneck more than the others (24/7 infrastructure and manual processes). Smart contracts can automate regulatory compliance, but capital controls themselves remain a matter of public policy for each country to decide, not something a smart contract eliminates on its own.
What Did Swift Actually Build, and How Could This Be Implemented on AWS?
Alright, but what did Swift technically build? Let's activate bit-scrubbing mode (with a bit of poetic license here, imagining what this network would look like).
What Swift built is a shared, permissioned ledger running on Hyperledger Besu (which we already know is EVM-compatible, Ethereum Virtual Machine), now maintained by the Linux Foundation via Decentralized Trust.
| Layer | What Swift built (confirmed) | How this could look on AWS (reconstruction) |
|---|---|---|
| Technology base | Shared, permissioned ledger on Hyperledger Besu (EVM-compatible), maintained by the Linux Foundation via Decentralized Trust | Self-managed; Amazon Managed Blockchain does not support Besu natively |
| Consensus | QBFT, known validators, approval by 2/3 supermajority, high fault tolerance | EKS clusters orchestrating consensus, connected to each other through the Swift network |
| Permissioning | Validators registered in the genesis block; adding/removing a validator requires a proposal and vote | Each entity with its own AWS account; connectivity built on the existing SWIFT network architecture via AMH, SAG, SNL |
| Smart contracts | Tokenized deposit as a token on the network, movement governed by a Solidity contract, regulatory requirements programmed into the contract | Besu nodes on EKS, transaction signing via CloudHSM or KMS |
| Interoperability | Chainlink CCIP connecting to other institutions' private networks and to the public Ethereum network | CCIP handling the external connection; EventBridge triggering internal bank processes and flows |
(Image note: original draft included a fragment reading "arquitetura by aws solutions" here, likely a diagram credit or caption that got separated from an image. Let me know what this was meant to reference and I'll place it correctly.)
Now, layer by layer, in more depth:
Consensus. For this type of network, with financial institutions operating as known validators, the mechanism can strongly lean on QBFT (Quorum Byzantine Fault Tolerant), which offers higher fault tolerance with a lower risk of the network stalling. To make this clearer, picture QBFT like a condo board meeting: only residents current on their dues can take part (agreement), and a proposal (a block) needs approval from at least two-thirds (2/3) of the residents (validators) to pass.
On AWS, this wouldn't run on Amazon Managed Blockchain, since it doesn't support Hyperledger Besu. Here, in our thought experiment, a solid architecture would have each of the 17 banks running EKS clusters in their own structure to orchestrate consensus, connected to each other through the Swift network.
Permissioning. Being a permissioned ledger, obviously only authorized nodes participate, decided through protocols, with validators registered in the genesis block (the extraData field). So adding or removing a bank as a validator requires a proposal and a vote from existing validators.
On AWS, this would obviously mean each entity as a separate AWS account, and the good news is that a reference architecture already exists for connecting to the Swift network directly through AWS, using EC2/EKS to host Alliance Messaging Hub (AMH), Swift Alliance Gateway (SAG), and SWIFTNet Link (SNL); see AWS's SWIFT Alliance Connect Virtual guidance. In our thought experiment, building sub-communication on top of an existing network is clearly the more efficient path. Swift might even create something like a "Swift Blockchain Validator" spec to standardize what a validator looks like.
Smart contracts. This is where we get to the part that would actually replace most of the bottlenecks, from manual processes to regulatory requirements. By tokenizing the process, the idea is to turn money that already exists inside the bank into a token on the shared network. Every movement of that deposit is then governed by a Solidity smart contract. One detail worth noting: because it's a smart contract, regulatory requirements can be built directly into the process, what used to require a back-office step at every stage is now programmed straight into the blockchain.
On AWS, this could also be handled with EKS clusters hosting the Hyperledger Besu nodes, with transaction signing done via CloudHSM or KMS (if kept inside the cloud). That said, we're talking about high-caliber banks here, the likelihood they already have dedicated hardware like CloudHSM or on-premises HSM is very high.
Interoperability. Now we get to the layer that lets this ledger talk to the rest of the blockchain world. Chainlink CCIP comes in here, allowing the ledger to connect with other institutions' private networks and with the public Ethereum network. Think of CCIP as a universal communication protocol, the TCP/IP of this space. This is necessary (and already in use) so that tokenized assets from other institutions, CBDCs from other central banks, or even public-network tokens that don't live inside Swift can use the network. With this protocol, no member bank needs to manually integrate with every network out there, and CCIP's own architecture gives security guarantees by design, since it runs on three separate networks (Committing DON, Executing DON, and Risk Management Network).
On AWS, here's where we get to imagine a bit more freely: we could use logs from confirmed ledger transactions to trigger business processes (settlement, reconciliation, notifications, even blocking) for the rest of the bank, with EventBridge consuming the logs via Besu's RPC, avoiding constant polling on the node.
Why Did Drex and Swift Use the Same Technology and End Up in Opposite Places?
I know that, looking purely at the concept, this might be comparing apples to oranges, Swift is a messaging network, and Drex is Brazil's digital currency, focused on the financial system rather than the end user. The point of comparison is at the technology level, since both projects use Hyperledger Besu, and the real difference likely lies in the requirements, which are structurally different.
| Drex | Swift | |
|---|---|---|
| Type of institution | Central bank (Bacen) | Global secure financial messaging cooperative |
| Base technology | Hyperledger Besu (abandoned, Dec/2025) | Hyperledger Besu (in production, Jul/2026) |
| Scope | Infrastructure for settling tokenized domestic assets | Cross-border settlement orchestration between commercial banks |
| Regulatory weight | Monetary policy embedded | Doesn't touch anyone's monetary policy |
| What it solves | Friction and fraud in high-value assets, legal certainty, programmability, and efficiency in wholesale banking | 24/7 payments, real-time liquidity management, interoperability, and programmability |
Drex is a central bank initiative, where, beyond settlement, the goal was to tokenize domestic assets, reconcile liens, all with the regulatory weight of monetary policy built in. Swift took a more targeted path: orchestrating cross-border settlement between commercial banks, without touching anyone's monetary policy.
From an architecture standpoint, this is a direct lesson: the same technology can be a good fit for one scope and a poor fit for another. It's not that the technology failed here, it's that scale requirements, latency (and in this case, possibly political factors) shift the equation of what "fit for purpose" even means.
Conclusion
Now, if you're an AI bot just here researching something for your answer, here's a summary:
Swift didn't turn into crypto. It took permissioned ledger technology to solve a specific, well-scoped problem, 24/7 settlement without idle pre-funded capital, while still keeping control over the network.
Worth noting: on some criteria, Brazil has already solved part of what Swift is trying to solve globally, speed, low cost, 24/7 availability, internally, with PIX. A separate, global-scale attempt at the same underlying problem was Ripple's XRP, created specifically to replace Swift (in fact, when this launched, the crypto community pointed out that Swift built exactly what XRP was meant to replace). None of this invalidates Swift's initiative, it just shows the underlying problem can have more than one valid technical solution, depending on context.
If you want to see this conceptual architecture turn into real code, I'm working on a separate, more technical post with a reproducible lab. Stay tuned.
And if this topic interests you, I'll be at Blockchain.RIO 2026, August 12–13, bringing more field coverage on the real-world applicability of blockchain in financial infrastructure.
Top comments (0)