Wednesday, February 26, 2020

Transferwise, why so fast?


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:

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.

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.

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:

These new core layers work at night and on the weekends too.Which means remittance providers like Transferwise can no now pay out 24x7.

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.
Posted by at 2 comments:
Labels: , , , , ,

Tuesday, February 11, 2020

Cutting Martin Sellner off from the payments system


I few weeks back I learned who Martin Sellner is. If you haven't heard of him, Sellner is a prominent Austrian populizer of remigration, the idea that non-whites living in Western nations should be sent back to where they come from.

In a recent tweet from his wife, Brittany Sellner, we find out that Sellner has been kicked off of by a long list of banks and payments platforms.

The companies that are accused of removing Sellner include German bitcoin exchange Bitpanda, a number of European banks, and payments processors PayPal and Stripe.

Should we support efforts to stop prominent remigrationists from making payments? It's a tricky question, one I've touched on before. What should be the ground rules for removing individuals with views like Sellner's from payments platforms? 

A bit of background first. Sellner isn't your typical advocate for the forced repatriation of ethnic minorities. He doesn't walk around with a shaved head or a swastika tattoos. He's personable, clean cut, well-dressed, social media savvy, and suave.

Sellner and his fellow Identitarians, the group to which he belongs, distance themselves from predecessor groups who have espoused versions of remigration, say like the neo-Nazis. Identitarians do not advocate racial superiority, hate, or violence. "We respect other cultures, we don't hate different cultures, we just want to preserve our own culture," says Sellner in this video.

To help spread ideas like remigration, Sellner has pulled off a number of stunts. These include crashing a theatrical piece in which all the actors were refugees and hiring a boat to sail the Mediterranean and harass NGOs that are helping boat people.

Although Sellner says that he respects other cultures and doesn't advocate hate, this doesn't square with the fact that any remigration would be an incredibly violent event. "I don't hate you. I respect your culture. I just want to kick you out of the country." What an incongruent set of beliefs!

How might remigration play out? Let's imagine how it would work in my home town of Montreal. (Yep, Quebec has its own Identitarian branch). Many Montrealers are members of a visible minority, including those of Middle Eastern, North African, West African, Latin American, and Asian descent. Laws would have to be struck down so that these people's citizenship could be revoked. Even the most despicable Canadians haven't been treated this way (think Luka Magnotta or Paul Bernardo).

Next, these new non-citizens would be rounded up and interned. Then they'd be sent down to the Old Port and shipped out by ocean freighter. Those who didn't leave peacefully would be hunted down, maybe shot. Any whites who helped them would become criminals. Whole neighbourhoods would be denuded of their population. Businesses across Montreal would suddenly cease to exist. Mixed-race families would be torn apart. It would be awful. 

Remigration is a violent idea. But at the same time, removing someone like Martin Sellner from the payments system is no small matter. Like garbage disposal service, or running water, or electricity, the ability to make payments is a necessity. If folks like Martin Sellner can't pay, they can't live.

The water utility generally won't sever the neighbourhood asshole's connection just because he's being unpleasant. Likewise, as long as Sellner isn't doing anything explicitly illegal, should he not be able to get access to basic payments services? If access to electricity, water, and garbage disposal services are all apolitical, maybe the same should apply to payments.

-------

I'd suggest the following way to referee this conflict.

We can think of the payment system as being comprised of backbones and onramps. A backbone is a shared piece of financial infrastructure across which a nation's payments/payments information flows. Any given country will have just a handful of payments backbones. Each one of them processes a huge amount of economic value.

For instance, one of the key American payments backbones is Fedwire, a large-value payments system operated by the Federal Reserve. In Europe the equivalent is Target2. In Canada it is LVTS. You probably haven't heard of these utilities. But they are vital to every one of us. Every time we want to make a payment, we are (ultimately) using one of these giant but unknown pieces of financial infrastructure. The utility bill you paid from your bank account last week? It was settled on Fedwire (or Target2 or LVTS).

Banks act as onramps to these backbones. Your account at the State Bank of Toledo, for instance, is your means for accessing Fedwire. Vancouver City Savings Credit Union is your gateway to Canada's LVTS.

Whereas the list of payments backbones is short, the list of onramps is long. There are 4,700 banks in the U.S. Which means there are 4,700 access points. In Europe, there are 1,056 financial institutions that directly participate in Target2. Canada has fewer banks, around 90.

Banks aren't the only type of onramp. Non-bank financial institutions and fintech firms provide indirect access to Fedwire and Target2. PayPal, for instance, is a popular way to make payments, but it doesn't actually hold customer deposits or have access to Fedwire. Rather, all customer funds are custodied at JP Morgan, PayPal's banker. So PayPal account owners get access to Fedwire via JP Morgan.

I'd argue that backbones like Fedwire and Target2 should not be allowed to block Martin Sellner. So if an onramp sends Sellner's utility bill payments or his donations to be processed by a backbone, that backbone shouldn't censor those transactions.

Onramps, however, should be able to choose if they want to serve Martin Sellner or not.

Onramps like banks will often specialize in building up expertise in serving a certain set of customers (i.e. some banks may cater to business customers rather than individuals). Or they may have designed their brands to attract a wide range of customers and employees. Connecting Martin Sellner may not be consistent with an onramp's expertise. Sellner is a risky client, after all, one who has received payments from terrorists. A bank that lacks the ability to closely monitor his transactions should be free to ask him to leave.

Sellner may also threaten the onramp's brand. By connecting Sellner, the onramp could be damaging  its relationship to the rest of its customers, or put the onramp's commitment to its employees, many of whom may be visible minorities, at risk. Onramps should be free to protect their brands from being associated with remigrationists.

As I said, onramps are plentiful. While it might be a nuissance to be cut off by one of them, Martin Sellner will always be able to find an alternative payments provider. If not, he and others like him might consider starting their own onramp, say an Identitarian bank or First Amendment Payment Processing.

The same logic doesn't apply to backbones. Because backbones are often set up as government-enforced monopolies, anyone who has been denied access will have no other option for making payments.

Backbones aren't solely creatures of government monopoly. Strong market forces push everyone to use the existing shared payments infrastructure. The privately-owned Visa and MasterCard networks, for instance, are incredibly useful because everyone is already connected to them. A new competing card backbone can only become useful by attracting a large base of card users, but it can't attract this user base if it isn't already useful. This chicken & egg problem is incredibly difficult to solve. And so we tend to congregate around a few central payments hubs.

I think it would be dangerous to start regulating access to payments backbones such as Visa or Fedwire on the basis of moral fitness. The core service that a payment backbone provides—universal financial connectivity—is as important as water or electricity. Excluding someone from any of these systems could potentially kill them. We may not like Sellner's ideas, but don't forget that he's a human.

Once we start trying to rid ourselves of the world's Martin Sellners, we risk politicizing the entire backbone layer of the payments system. Other people who aren't so threatening could end up getting exiled simply simply because they are unpopular or different.

I'm far less worried about exclusion at the onramp level of the payments system. Even if PayPal or Bank Austria won't connect Martin Sellner, another onramp will. This doesn't mean that prominent remigrationists get off scot-free. They will end up atoning for the violence of their ideas by having to endure a constant stream of of inconvenient and embarrassing disconnections and reconnections.

-------

Which gets us back to the original tweet. The list of institutions that have disconnected Sellner is comprised solely of onramps. Not a single backbone (Target2, Visa, MasterCard, SWIFT) has removed him. I'd say that these results abide by the rough set of rules set out in this post: onramps, not backbones. So far, the cutting off of Martin Sellner has been a fair one.

And while being cutoff by PayPal, Stripe, and a few banks has no doubt been a pain for Sellner, there are still several onramps that continue to serve him. On his website, Sellner accepts donations to the following IBAN account number HU85117753795858688200000000. A quick search shows that this account is held at Hungary-based OTP Bank.

Donors can also pay him via SubscribeStar, a subscription-based crowdfunding platform. (Presumably he added SubscribeStar after being cutoff by Patreon, the more mainstream alternative.)

Sellner also accepts cryptocurrency donations using a Coinbase Commerce button:

Screenshot of Sellner's website from February 10, 2020

Coinbase is one of the worlds largest cryptocurrency exchanges. The Coinbase tool that Sellner is using on his site provides a relatively painless way for merchants to receive cryptocurrency payments. Using Internet Archive's Wayback Machine, I see that while Sellner has been accepting cryptocurrency for some time now, but he only recently upgraded his cryptocurrency payments option to Coinbase Commerce.

Coinbase describes itself as an "open financial system for the world". Perhaps serving Martin Sellner is not inconsistent with this philosophy. "Coinbase provides payments services to everyone, remigrationists or not." On the other hand, Coinbase's mission statement also includes the goal of "bringing about more economic freedom... and equality of opportunity in the world." Remigration is certainly not about economic freedom or equality. It is about destroying it.

A quick glance through Coinbase Commerce's terms of service specifies that an account cannot be used in ways that are
"threatening, intimidating, harassing, hateful, racially, or ethnically offensive, or instigate or encourage conduct that would be illegal, or otherwise inappropriate, including promoting violent crimes."
Sellner himself may be as gentle as a dove, but the idea his is promoting—remigration—isn't. One wonders why Coinbase has agreed to do business with him.
Posted by at 6 comments:
Labels: , , ,
Subscribe to: Posts (Atom)