Thursday, November 19, 2020

Programmable money isn't new, we've had it for ages

I often hear that modern money just isn't up to snuff because it isn't programmable. That's why we need Ethereum, stablecoins, and other exotica like central bank digital currencies. These platforms will provide the world with much needed programmability.

Stablecoin issuer Circle is one of the bigger marketers of this idea, but it's far from being the only one: 

"While value exchange may be the initial killer app, it’s the programmability of digital money that will ultimately usher in business model breakthroughs." [link]

I disagree. We've had programmable money for ages. Let me offer a quick guide.

Microsoft doesn't have a bunch of employees who sit at desks and manually sign paper checks all day. No, it uses software that automates payments to its tens of thousands of suppliers, employees, contractors, investors, and the tax authorities. Every day this software relays payment instructions to the Federal Reserve's clearing house for processing. The Fed doesn't rely on physical labour either. FedACH, as it is known, is an automated clearing house. It uses software to automatically clear all incoming payments.


By the way, ACH go back to the 1970s. If Microsoft's software-based payments and FedACH aren't programmability, I don't know what is.

Another example of programmable money is the recent Korean COVID-19 stimulus payments. Koreans had the choice to receive either a prepaid debit card, credit card points, or gift cards. Since the idea was to help local businesses, the prepaid cards and card points were programmed with certain limitations. To begin with, the funds expired by August 2020 in order to discourage hoarding. Secondly, money could only be spent at qualifying shops. That meant no online shopping, no purchases at large-scale supermarkets or entertainment places, and the money had to be spent in the district where the recipient lived.


Programming COVID relief didn't require anything fancy like Ethereum or stablecoins. The card networks make it easy to do this sort of thing.

We scan see another example of card programmability in Australia with its controversial cashless welfare card (or "Indue" card), currently in pilot mode. Once government benefits are deposited onto the Indue Visa debit card, the money is "quarantined" such that it can't be withdrawn as cash from automatic teller machines or used to shop at merchants that sell restricted items like alcohol, tobacco or gambling products. The idea, presumably, is that low-income people can’t control their spending, and thus their money has to be programmed to overcome their shortcomings.

Source: The Gaurdian

Again, this didn’t require Ethereum or stablecoins or a Australian digital currency.

Automated escrow is another example of programmable money. Using Ethereum’s programming language, Solidity, one can create an escrow contract that locks up some Ether until certain conditions are met and a payout is made. But Ethereum isn't the only platform that can do automated escrow. Escrow.com, for instance, lets users code up escrow arrangements using its application programming interfaces, or APIs. Escrow.com stores the dollars and then automatically pays out once an event has been triggered, say a used car inspection has been passed. 

No fancy blockchains here.

Speaking of APIs, the Europeans are probably the leaders in bank account programmability. Thanks to the Second Payment Services Directive, or PSD2, European banks are now obligated to grant fintechs access to customer accounts via APIs. (Some people refer to this as “Open Banking.”)  This provides fintechs not only with the ability to peer into what those bank accounts hold, but also the ability to program those accounts to make transfers and such. And thus they can provide the public with new financial tools, built on top of banks.

Monzo, a UK-based digital bank, provides a taste of what this sort of programmability might offer. In 2018, it introduced functionality that allowed its customers to connect their bank account to a range of other web services and create automated rules or ‘recipes’. Such recipes could allow customers to use data from, say, a weather application to trigger a change in their Monzo account, say to move money to a savings pot.


Even my plain vanilla Canadian bank account grants me some basic programmability. I can set up my Tangerine bank account to pull money from my Royal Bank account, and choose how often this will happen (daily, weekly, monthly), and select how long these periodic transfers are to last. Sure, it's limited. There are no if-than statements. But most regular folks probably don't require much programmability. And banks may not be too keen to provide it to us anyways. We'd probably mess it up, and then they'd have to spend time and money cleaning up our mistakes.

So to repeat, programmability is already here. Has been for a while.

If anything, public blockchains like Ethereum offer a different sort of programmability. Rather than the code being hosted by a commercial or government entity, it is hosted on a neutral, decentralized platform. 

There is a niche for this sort of programmability. Jack may not trust the automation provided by a payments company or a central bank utility. He could be cut off, say because they deem him to be a risky customer, or maybe because he is doing illegal things. But Ethereum isn’t controlled by anyone, so Jack can be sure that the automation provided by Ethereum won’t suddenly stop.


P.S.: Antony Lewis has also been thinking on this topic. Head on over.

2 comments:

  1. > Programming COVID relief didn't require anything fancy like Ethereum or stablecoins. The card networks make it easy to do this sort of thing.


    I think the disconnect is *who* the card networks make it easy for. Sure, the card issuers can easily add programmable constraints to the card, but its not easy for third party developers to add programmability without issuing their own cards.

    I think the key here is making it easier for more people to innovate in adding interesting features to money. I don't disagree that I could probably hack something together connecting my PSD2-compliant bank account and your Monzo account into an escrow.com escrow that triggers on logic from my custom AWS lambda script. But it won't be easy; composing together all these APIs is quite a headache. The actual programming process of composing together Ethereum contracts is much simpler than these web API endpoints with their legacy authentication systems and bespoke architectures. Not to mention their varying qualities of documentation and their habit of changing from under you. If you've ever worked with integrating systems with external APIs, you'll know the less APIs you need to deal with, the better. (https://youtu.be/BxV14h0kFs0)

    I agree that more financial institutions should be providing APIs, but standardization of these APIs is important and this is something that's been happening far better in blockchain world than traditional finance so far. That being said, standardization initiatives like PSD2 are awesome and a step in right direction.


    Also, the fact that on smart contracting systems, assets are represented as first class citizens on the same layer as the computation makes architecting these financial apps far easier. The contract logic can do push payments, rather than need to make a request to a third party API. As mentioned before, the fewer 3rd party APIs, the better. (Btw, the way ERC20 standard is done on Ethereum sucks, and should be redesigned to be more like the "native asset" ETH).

    P.S. Monzo's IFTTT integration is super cool!

    ReplyDelete
    Replies
    1. Good comments, Sunny.

      "If you've ever worked with integrating systems with external APIs..."

      I haven't! :)

      My main point in writing this was to rebut the more naive view that I often hear in promotional material, social media, and elsewhere that old money isn't programmable at all. I wouldn't dare try to rebut your point that the programmability of Ethereum is easier than that of using multiple APIs. I'm sure you're right about that.

      Delete