This post explores some of the technological advancements that have allowed remittances to be completed in seconds rather than days.
If you follow me on Twitter, you'll often see me retweeting folks who have just made really fast remittances using Transferwise, a company that specializes in cross-border payments. Like this one:
Australia to Thailand, less than a minute.— John Paul Koning (@jp_koning) February 17, 2020
Remittance providers can achieve speeds like this by stitching together domestic 24x7 real-time payment systems, in this case Thailand's PromptPay and/or Australia's New Payments Platform. https://t.co/6UCdcVMFyO
No, I'm not a paid shill for Transferwise. I'm providing a public service. By shining a light on these quick remittances, I'm hoping to counteract two bad ideas. The first one, which goes back at least to 2011 or, is the idea that traditional fiat-based platforms can't do fast remittances. So we need either bitcoin or some sort of blockchain, say Ripple, to bring competence to the remittance space.
This idea was best captured in this meme from a few years back:
The second and related idea is that since banks or fintechs can't do fast remittances, we need some sort of government fix, specifically a central bank digital currency (CBDC), to expedite them. In a recent white paper, for instance, IBM and the Official Monetary and Financial Institutions Forum describe remittances as "cumbersome, expensive and slow," and suggest that CBDCs may ameliorate this problem. The Monetary Authority of Singapore justifies its experiments with CBDC by using the same two adjectives, "slow" and "cumbersome" for remittances.
But as the above Australia to Thailand remittance shows, it is possible to do instant cross-border payments without blockchain or CBDC. Which means that if central bankers want to justify building their own digital currency they'll have to come up with better supporting facts than private sector incapacity to facilitate fast remittances. And if bitcoin is going to take over the world, it'll have to compete on factors other than remittance speed.
So without further ado, let's get to the main question: how does Transferwise get money from X to Y in ten seconds? After all, it isn't entirely wrong to poke fun at traditional remittance companies. Historically, it has taken a few days to move funds electronically from a bank account in one country to a bank account in another.
To figure out why remittances can go so quickly, we've go to unwind the technology of a money transfer.
The ABCs of a remittance
We can think of any national payment system as a stack of interconnected databases. For a payment to make its way from your account to mine, information has typically had to cascade down the stack of databases to the bottom-most layer and then flow back up. The speed of a payment is a function of both by how quickly each individual database in the stack can be updated, and the speed at which information gets relayed to the next layer in the stack.
Impressive. A 15-second Germany-to-India remittance.— John Paul Koning (@jp_koning) January 9, 2020
No blockchain required, just good ol' centralized databases being rapidly updated on top of real-time central bank payment systems. https://t.co/NlLeiDk9jr
Say that Jill, who lives in the US, wants to transmit $100 to Tom in Singapore via Transferwise.
Jill sits at the top of the U.S. payments stack. She has an account at the First Bank of Boaz or, put differently, she occupies a spot in First Bank of Boaz's database. Transferwise also sits at the top of the US payments stack. It has a business account at Bank of America. In other words, Transferwise is represented by an entry in Bank of America's database.
Before Transferwise can pay Tom in Singapore, it has to wait for Jill's $100 to make its way through the US payments stack and land in its Bank of America account. But the $100 can't simply hop laterally from First Bank of Boaz's database to Bank of America's database. The payment information first has to plunge down to the next lower level of the payments stack.
The whole process begins with Jill asking the First Bank of Boaz to make the $100 payment. First Bank of Boaz adjusts its database by reducing Jill's balance by $100. This information gets relayed down to the next database in the stack.
First Bank of Boaz is a small bank. It has an account at the much larger Chase Bank. So it informs Chase about the $100 that it wants to send to Transferwise on behalf of its customer Jill. It is now Chase's turn to adjust its database. It reduces First Bank of Boaz's balance by $100.
Transferwise doesn't have the $100 yet, however. The payment information still has to be relayed to the bottom-most layer. Chase and Bank of America both have accounts at the Federal Reserve, America's central bank. Chase informs the Fed about the $100 transfer, upon which the Fed updates its database. It reduces Chase's spot in its database by $100 and adds $100 to Bank of America's entry. The banks have now 'settled' their payment. The most important payments layer, the bottom-most one, shows the switch has been made.
Information starts to flow back up the stack. The Fed notifies Bank of America about the $100 credit to its entry in the Fed's database. Upon which Bank of America updates its own database. It increases Transferwise's entry in its database by $100.
Phew. Transferwise finally owns the $100.
Now it can do the Singapore leg of the transaction.
The same down-and-up-the-stack progression that occurred in the US now plays out in Singapore. Transferwise tells its Singapore bank to transfer SG$140 to Tom at his bank. As before, the payment can't just hop from one bank database to another bank database. The information first cascades down to the bottom-most database, the one maintaind by the Monetary Authority of Singapore. Only after MAS updates its database will the information flow back up the stack to Tom's bank. At which point Tom's bank updates its database.
The remittance is now complete. Tom has an extra SG$140 and is free to spend the funds or withdraw cash.
OMG!!!! @TransferWise You are awesome!!!! 5 seconds to send money from Spain to México. The last time it was like 1 day.— Javier Camacho 🇲🇽🇪🇺🇪🇸 (@fjccorp) February 11, 2020
In the old days of two or three day remittances, one of the biggest clogs in the system was the glacial speeds at which information flowed onto the base layer and the rate at which the base layer, usually operated by a central bank, was updated.
Rather than sending Jill's payment instructions individually to the central bank database, banks would typically batch her instructions together with millions of other instructions and send them to the central bank just before closing time. The next day the central bank would process these big batches, check for errors, and cancel offsetting payments. Only then would the central bank update its database by adding money to creditor banks (like Bank of America) and removing it from debtor banks (like Chase).
The updated information could now flow up to higher database levels. But by then the original payment instruction was already a day or two old. Remitters like Transferwise were left waiting for days to receive the originating customer's transfer.
The mirror image of this would occur on the other side of the ocean. If it took Transferwise a day or two to receive money in the U.S., it also took a day or two for Transferwise's Singapore dollar payment to land in the Tom's account. This combination of two sluggish central bank databases is why remittances used to flow like molasses.
Even worse, the central bank database was closed on the weekend. So anything that was sent to the central bank by Friday night would have to wait till Monday morning to be processed.
Not anymore.
The dawn of real-time retail payments systems
Much (though not all) of the speed improvements are due to new ways of operating the central bank's bottom-most database.
Instead of Jill's payment instructions being batched together with many other payments and sent to the central bank at the end of the day, banks will now send Jill's instructions individually and in real-time to the central bank. The central bank updates its database a moment later. Now instructions can flow up to Transferwise's account in the seconds that follow. Which means that Transferwise can quickly start working on the foreign leg of the transaction. As long as the foreign central bank's base layer is also capable of operating in real-time, then the whole cascade of database updates can occur in just a few seconds.*
Like this one:
11 seconds to get money from UK to Hong Kong.— John Paul Koning (@jp_koning) May 3, 2019
Courtesy of the the Hong Kong Monetary Authority newly-built instant retail payments system: https://t.co/WbRhzkXgK8 Transferwise serves as a bridge between the HKMA's new rails and UK's existing instant retail system. https://t.co/1ga0oscZvA
These new core layers work at night and on the weekends too.Which means remittance providers like Transferwise can
Known as real-time retail payment systems, these newly-revamped layers have sped central banking up. They include UK Faster Payments in 2008, India’s IMPS in 2010, Sweden’s BiR in 2012, Singapore’s FAST in 2014, and Australia’s NPP in 2018.** Brazil's PIX is the newest one.
All of these developments may give the impression that Transferwise is just a passive beneficiary of improvements elsewhere in the payments stack. But Transferwise has had to design its own internal mechanisms for ensuring that it can harness these improvements. Automation and AI no doubt have a big roll to play. But I don't work at Transferwise, so I can't shed much light on this. I'm sure it has used some neat tricks.
So we don't really need CBDC or blockchain to get faster. If we want policies that can speed up remittances even more, the best thing is for central banks to continue the process of setting up real-time retail payment systems, until the whole world is blanketed. Then stand aside and let innovators like Transferwise complete the task of linking these disparate systems up.
But if there was one adjustment that could be made to go even faster, it would be this: let remittance companies like Transferwise hold accounts directly at the central bank.
Most jurisdiction only allow their central bank to interact with banks. But this forces Transferwise and other specialized payments companies to seek out banking intermediaries in order to access the central bank's database. And this extra layer may slow them down. By interfacing directly with the central bank's core layer, Transferwise may be able to optimize the interconnection in order to squeeze a few extra seconds out of each remittance.
*There are variations on this theme. UK's Faster Payments scheme uses batching but is still able to process payments in real-time. (I explained how here). US's same-day ACH also speeds up the domestic payments system, but also uses batching. By submitting batches before certain cutoff times during the day, the Fed promises to update its database that same day rather than waiting till the next day.
**By the way, there are other tricks to make the whole series of database updates go quite fast that don't involve speeding up the bottom-most layer. MasterCard and Visa both run real-time communications networks over which debit card-enabled accounts can communicate. And these networks can be used to skip the previously-described trek to the bottom-most (and slowest) layer and back.
For instance, using the Visa Network the First Bank of Boaz tells Bank of America that Jill wants to move $100 to Transferwise's account. Bank of America quickly credits Transferwise the $100 while First Bank of Boaz debits Jill $100. Transferwise can now do the Singapore leg of the remittance. First Bank of Boaz and Bank of America will settle up with each other the next day on the Federal Reserve's database.
Related Posts
Subscribe Our Newsletter