SWIFT, or the Society for Worldwide Interbank Financial Telecommunication, is the world’s largest electronic payment messaging system, facilitating the exchange of more than $6 trillion a day, according to 2012 estimates.
Though it gets lumped in with electronic funds transfer systems, it doesn’t do any of the funds transfers itself. In fact, it doesn’t even touch money. (Although, as we’ll unpack in part 2 of this series—on the massive Bangladesh hack—it does make money move.)
At its core, SWIFT is basically just a bank-to-bank messaging system. It supplies a standardized language that institutions use to communicate payment instructions and other info to each other.
SWIFT messages are programmed in a language known as FIN. A sample of FIN language is shown at right.
The origins of SWIFT demonstrate how, in spite of tensions, competitive entities—and interests—have historically come together to address shared problems; in this case, issues with interbank payments.
The quick history of SWIFT
Before SWIFT, there was Telex. It’s helpful to start there, because rather than being created from scratch, the SWIFT system is rooted in some precedent.
Telex—or the Teleprinter exchange, if we’re getting formal—was (and is) one of the original ways to transmit data developed during World War II. Though its roots were in the military, it was quickly adopted by financial institutions for their systems to communicate internationally.
By the 70s, Telex had gotten old: It was indisputably slow (transmitting bytes per second), lacked formatting standards (limiting the possibility to automate), and wasn’t as secure as evolving threats demanded (after all, it had basically become a directory served over the phone networks).
Around the same time, domestic electronic funds transfer systems began to emerge, driven by a desire to eliminate paper from the payments process. (Imagine: the push to go paperless was a process that took shape in the 60s.)
The distinction, of course, is that EFTs actually move money. But they often used Telex messages to get information about what needed to happen—which made the issues with Telex all the more pointed.
So in 1973, after a handful of studies and a lot of talking, a group of banks established SWIFT as a specialist’s alternative to Telex. They selected Brussels for the cooperative’s headquarters—evidently, choosing New York or London would have been too political.
By the time SWIFT went live three years later, it comprised a messaging platform, a computer system to validate and route messages, and a set of message standards. More than 500 institutions from 22 countries were connected.
Today, more than 11,000 institutions in more than 200 nations are connected to SWIFT. In 2015 alone, 6.1 billion FIN messages were sent through the network.
How SWIFT works
SWIFT uses a system of codes to detail where a transfer is coming from, where it’s going, and how it’ll to get there. These strings of alphanumeric identifiers comprise an institution code, a country code, a location code, and a branch code. So in that way, it’s not dissimilar to the U.S. routing number system.
It’s worth reiterating that, because SWIFT doesn’t actually send money, institutions that use the network also need banking relationship to move funds.
Each financial institution will have a dedicated SWIFT interface (in other words, a computer-based terminal) on-premises. Most banks set up their SWIFT systems so that they’re isolated from the rest of their networks. (Though, again, as we’ll cover later, not all do.)
Users can log in to these terminals to manually enter messages. Messages can also be auto-generated by the institution’s computer system and passed on to the terminal. The terminal then sends the SWIFT message to the regional processors in the sender’s country. The terminals only connect with processors through leased line, dial up, or public data network connections. C24 has an excellent rundown of how everything works here.
From there, the regional processor checks, stores, and forwards the data to its operating center, which passes the message on to the processor in the recipient’s country. That processor delivers the message to the receiver’s terminal, and then sends confirmation. Officials at the respective financial institutions are supposed to audit these to prevent fraud.
Actually transferring funds internationally is a bank matter.
Say two customers of the same bank are located in two different countries and want to transfer funds. The customer in country A will ask the bank to transfer funds to the customer in country B. Branch A will then tell its counterpart what to do via SWIFT. And then it’ll wire the funds and make the required book entries in its accounting system. That’s it.
But it’s usually more complicated than that, and it often involves more financial institutions.
For example, if one financial institution doesn’t even have a branch in the beneficiary’s country, it might need to loop other institutions—in this context, called correspondent banks—to complete the transaction. If both banks (conveniently!) maintain accounts at a third institution, they might use that third bank to expedite things. They’d identify the relationship, send a secure message over SWIFT between the banks, and do a book transfer.
SWIFT doesn’t provide these services for free—the cooperative makes money from one-time setups, service and equipment fees, consulting, and it takes a cut each time a message is sent (its largest source of revenue), among other streams. It publishes its annual review and financials on its website.