Cryptocurrency products and services will determine adoption of the currency – not the other way round

The critics of Bitcoin-the-currency are right… but only in the sense that the motor-car was a poor imitation of a horse…

I had a light-bulb moment this week. It was triggered by a panel I sat on at Sibos, hosted by the wonderful Adam Shapiro from Promontory Financial Group.

My argument to the audience was the one I usually give: they should simply ignore the currency use-case: it’s the least interesting thing about Bitcoin. They should, instead, look at it as a platform for decentralized value-exchange and focus on the opportunities this enables.

Sibos TV

The panel discussion isn’t online but you can see us debate the issues on Sibos TV.

I then returned to the warm embrace of the Innotribe room and thought little more of it.

I thought little more, that is, until I returned home on Friday and went for a run. I took the opportunity to catch up with a few podcasts, one of which was Dave Birch’s interview with Jeffrey Robinson, author of BitCon. (Aside: everybody I know thinks I’m weird for listening to economics and FinTech podcasts when I run. I can’t be alone… surely?!)

It is fair to say that Jeffrey is not a fan of cryptocurrencies. And he makes some well-aimed shots at the heart of the “Bitcoin is a useful currency” argument in the podcast. For example, he points out that vanishingly few retailers actually accept it, despite the hype (they, instead, receive dollars from BitPay or Coinbase instead).

Now, one could take issue with Robinson’s arguments (he’s very confused on some technical aspects and the Boston Fed does see some evidence that consumers pay marginally less when using Bitcoin rather than payment cards).

But surely this is to miss the point. Whether or not cryptocurrencies are superior than today’s currencies for today’s payment problems isn’t really interesting.

It’s like saying that the automobile is a terrible way of pulling a plough.

Cryptocurrency technology will succeed only to the extent that it enables new products and services that were previously impossible or unimaginable.

And here’s the light-bulb moment: most of the really interesting use-cases turn out to need a payment mechanism – and having a currency and payment mechanism built into the platform turns out to be really, really useful.

Causation runs in the opposite direction to what everybody seems to think: it is new products and services that will drive adoption of the underlying currency. Not the other way around.

Two interesting viewpoints

Perhaps you think I’m setting up a strawman…? Happily, there have been two separate posts this weekend describing what some of these applications might be. So let’s check…

First, Chris Dixon offers some ideas for native Bitcoin apps. If I’m being critical, I thought they were somewhat pedestrian – they all seem to be answers to the question: “if Bitcoin the currency was widely deployed, what could you do with it?” – which I think is the wrong way to look at this. It has causation in the wrong direction.

But Adam Ludwin at Chain.com also blogged on this topic. And his argument is more compelling to me. He acknowledged that we really can’t anticipate where this will go – but he highlights ideas like smart assets and so forth as promising areas of research.

So can we flesh this out some more and identify additional examples?

When the audience takes photos and makes notes, you know they’re excited by the topic…

I hosted five startup CEOs on the Innotribe stage at Sibos on Monday and it’s interesting to me that the demo that created the most excitement was Yoni Assia’s demo of colored coins. He showed the (fake!) example of a large US bank issuing IBM stock on the blockchain so that it could be traded and transferred without the need for the plumbing we take for granted in the securities processing world. I think he used the CoinPrism platform. And it’s worth also checking out ChromaWallet.

coloredcoins

Using the Colored Coins concept to issue, track and transfer securities on a blockchain.

I spoke to various attendees over the following days and this topic clearly excited them. The demo had helped them move from an intellectual, but shallow, understanding of the concept to one that helped them envision a future where custodians, clearing houses, exchanges and brokers work in a completely different way. I’ve written about decentralized securities processing here and seeing it in a live demo made it real for people.

Now the interesting thing is: this use-case has nothing to do with currency. The Bitcoins are just being used as a transport layer. All the intelligence and disruptive power is at higher layers of the stack.

The key insight: what is the best payment mechanism for colored coins?

But now… ask yourself a question: imagine this platform gained adoption. In what currency – and using what mechanism – would participants pay each other?

Sure – you could use whatever you like. But the interesting thing is: if you paid in the native currency of the platform – Bitcoin in this case – some very special possibilities arise. For example, you can use the Bitcoin scripting system to make binding bids and offers without needing a central exchange. And you can achieve atomic swaps of currency for securities – delivery versus payment – without needing a custodian.

So suddenly, a “currency” which may indeed have limited utility for today’s developed markets for today’s problems suddenly becomes utterly superior for this new use-case of decentralized asset exchange.

Now, I should point out that not all of this infrastructure yet exists so I’d advise readers to read an interesting paper by Mark Friedenbach and Jorge Timón on how to modify the underlying Bitcoin system to support it. (My thanks to Ian Grigg for the pointer). In passing, I think these systems also need two other critical pieces of infrastructure:

  • An identity and reputation system: how do I know an issuer of IBM “stock” really is who they say they are? And how do I know they are authorized to make the statement? The complexity here goes beyond narrow concepts of corporate identity
  • What rules are needed to underpin this? Which legal precedents?

But I think it’s examples such as this will lead us to a world of 1) unanticipatable products and services, for which 2) the optimum payment mechanism is the native token of the platform.

To repeat: new apps will drive cryptocurrency usage… not the other way round.

So what are some other potential use-cases?

I’d classify the example above as Smart Property.   I think there are at least two others:

The Economy of Things

I wrote recently about the work we at IBM are doing around the economic model of the Internet of Things. The work is focused on the underlying architecture through which trillions of devices can discover, connect and collaborate. But what would happen if these “things” needed to transact with each other? Wouldn’t the most obvious payment vehicle to use be the native token for the platform? (Usual disclaimer: I raise this as an open question… it’s not a statement of direction or intent by IBM)

Indeed, one potential example of this has already been studied in Switzerland. A recent paper by Dominic Worner and Thomas von Bomhard examines “Exchanging Data for Cash with Bitcoin” – one could easily imagine “things” paying each other for access to trusted data feeds in other scenarios too.

Smart Contracts

Vitalik Buterin’s presentation on Ethereum was a highlight of the first day at Innotribe this week. And I thought his host, Dan Marovitz, showed excellent judgement in allowing him to talk at length and in significant technical depth about his vision. The audience of senior bankers seemed to be completely rapt.

etherscript

Using Ethereum in a world where the there’s been a breakdown in trust between children and the tooth-fairy

At the core of the Ethereum concept is the idea that real-world relationships and contracts can often be reduced to deterministic rules that can be executed by a neutral, unimpeachable platform. And these contracts often (not always) involve the exchange of economic value, usually in the form of the native currency of the platform.

Now… I have some reservations about Ethereum… it is so ambitious and so audacious that I worry that it might prove to be unbuildable – and I note that real-life isn’t always reducible to deterministic rules….   But, as Gavin Andresen has argued, it might be possible to achieve much of what Ethereum aims to do on top of the Bitcoin platform itself. At which point, the world of smart contracts would drive usage of Bitcoin-the-currency.

And I’m sure there are more…

So where next…?

It’s still early days, of course. But the lesson I learned this week was that we need to get away from the sterile “Bitcoin the currency” versus “Bitcoin the platform” debate. Instead, we should consider how one drives the other… and how it’s the platform that is likely to drive the currency, not the other way round.

 

“Device Democracy”: IBM’s IoT Paper – Or “on the blockchain, nobody knows you’re a fridge – made real”

The IBM “Device Democracy” paper is another example of how blockchain technologies could have impacts well beyond currency

I recorded an interview for Finextra last year, where I argued that we should view Bitcoin and cryptocurrencies as far more than just currency and payment systems: they’re enablers for whole new classes of innovation.

One of the example I gave was how they could provide an economic underpinning for the Internet of Things (IoT) and pointed out that if devices in your home each had their own Bitcoin wallet, the Internet of Things could rapidly become the Economy of Things

On the blockchain, nobody knows you’re a fridge (Buy it from teespring.com!)

But talk is cheap. Implementation and delivery is what counts.

So I have been enormously privileged to contribute, in a very small way, to a fascinating project being led by Paul Brody, IBM’s Vice President for our Mobile and Internet of Things consulting team. It has been well-covered by CoinDesk, GigaOm and “Two Bit Idiot” but, as Two Bit Idiot observes, I think its true significance has yet to be understood.

Here’s my simplified take on what this project is all about:

Imagine the predictions of the futurists come true and the Internet of Things becomes a reality: wireless locks controlling our houses, wifi-enabled lightbulbs and internet toasters, all that stuff.

Think about the economics from the manufacturer’s perspective.

My elderly iPhone 4 has finally reached end-of-life: it’s getting slow, iOS 8 will not run on it and I can expect apps to start failing one-by-one as their developers stop updating them for iOS 7. And yet the phone is only four years old. Most other phone manufacturers abandon their customers far more quickly, which means Apple’s four-year support for my phone is industry-leading.

My iPhone 4 served me well – even serving as a prototype for Apple Pay (Not really).  But, after four years, it is obsolete and the latest version of iOS won’t run on it

But, for the internet of things, a four-year old device is barely a child! These devices could last for far longer than anybody expects. How often do you change the locks on your door? When did you last replace your toaster? Some observers claim LED lightbulbs could last for twenty years.

Now imagine what the world would be like if Apple had to support the iPhone 4 for twenty years.  That is a long time to support, maintain and upgrade an internet-connected device.   As Paul and the team write in their very readable whitepaper, we can’t assume that the data produced by these devices will somehow create enough value to fund the ongoing costs.  Consumers seem to be in no mood to give away ever more data in exchange for “free” services… and it’s entirely unclear that this data has as much value as people think, in any case.

Technology Principles for internet-connected devices that could run for decades

So we need to make it as easy as possible for manufacturers and others to support these devices in the field. And part of the answer is surely that we need to make it as easy, cheap and sustainable as possible for manufacturers to do the “right” thing. And the argument that Paul’s paper makes is that the key to doing this is to decentralize as much logic as possible – so that what’s left at the centre is as small as possible.   They capture this intuition in the form of three key “technology principles”:

  • think “peer-to-peer” wherever possible… if two devices can find each other and communicate directly, why route it through a central point?
  • assume you’re operating in a “trustless” world: if you can’t be sure that everything is running perfectly all the time (because it won’t be), then choose a design that needs as little trust as possible
  • decentralize autonomy to the greatest extent possible – if something doesn’t need to be decided at the centre, decide it at the edges. Build on the insight that those with the greatest ongoing incentive to keep these systems running are those closest to them and who depend on them the most.

Device Democracy

This concept inspires the title of the paper: “Device Democracy”. They call the resulting architecture an “Internet of Decentralized, Autonomous Things”. The project’s IBM landing page explains more.

The paper explains the reasoning in more depth but the intriguing result is that the principles above are well-matched to concepts well-understood by the crypto and cryptocurrency worlds. A secure point-to-point messaging system like Telehash is a good candidate for direct device-to-device messaging, for example. Similarly, a trustless decentralized contract platform like Ethereum (a second-generation blockchain technology) could be a way to encode agreements between devices and to enforce rules.

Indeed, the team’s prototype (which has real locks opening and closing – I so wish I had been in the room when they demonstrated it) is based on Ethereum, Telehash and BitTorrent (you need something to distribute billions of firmware updates, after all)

But it’s important to realize that this isn’t a break from the past; it’s incremental. Existing protocols will still be needed and manufacturers will still need a way of communicating with their devices. This is all about making it as easy and secure as possible and to give end-users as much control as possible – hence “Device democracy”.

It’s perhaps likely that we’ll see hybrid models emerge where these peer-to-peer technologies are coupled with centralized services (cloud-based to hit cost objectives).

This is why I say Bitcoin and Cryptocurrencies are about so much more than currency…

For me, this project gives me further reason to believe that the impact of blockchain technologies and cryptocurrencies will be far greater than anybody expects: their applications go beyond the imaginations of any one of us.

We first saw this with Bitcoin. You needed good knowledge of economics, finance, cryptography and computer science to understand the Bitcoin concept in its full breadth. Indeed, I think this is why may academic economists, central bankers and computer scientists were amongst the slowest to grasp its importance: they were, in general, just too specialised and narrow.

So it is with this project: it has taken a team with knowledge of electronics, engineering, manufacturing, decentralized protocols and economics to devise this prototype platform.

The future belongs to the versatilists?

I wonder if this could be further evidence that the future will be owned not by the specialists or the generalists – but by the versatilists?

 

Disclaimer and Notes

1) I know there’s a lot of interest about this project so a quick reminder that this blog contains my views and analyses… not IBM’s.  I am not an official spokesman on IoT or anything else. 

2) I have lost the contact details of the clever person who created the excellent t-shirt design above. Please do get back in touch so I can credit you

 

A simple explanation of how Apple Pay works (probably): It’s all about tokenization

Forget contactless point-of-payment… that’s a solved problem. Apple’s use of tokenization is the interesting part

[USUAL DISCLAIMER: I have no inside info, these are personal views]

I’ve been using a beta version of ApplePay on my iPhone 4 for some time now…

ApplePayBeta

My very old, but very effective, Barclaycard contactless PayTag, stuck to my iPhone 4

The interesting question is how Apple chose to embed the card details inside the phone

To understand why, we have to rewind to March, when something curious happened: a body called “EMVCo” released a technical specification document for something called “tokenization”.

It was curious because it seemed to solve a problem that was already being solved by other players in the card industry. Make no mistake, however: the problem is a big one. Here’s what I mean.

I’ve written extensively about how Payment Cards implement the “pull model”.  When you want to pay for something, you hand over your card details to the merchant and then hope that those details don’t get into the wrong hands as they pass from merchant to their acquirer to the switch and finally to the bank that issued the card in the first place.

PushPull

In particular, the big problem is what happens when companies with millions of cards on file get hacked. Think of major online retailers who save your card details for you. It’s very convenient for you but it only works because they’ve stored your card details on their servers. If they get hacked, then millions of people are at risk of theft and card issuers will have to reissue millions of new cards. It’s a huge pain.

PushPull2

When you allow a merchant to keep your card details on file, you have to trust all the actors in the blue oval not to mess up…

However, there’s a really cool thing you can do to make this system much safer. It’s called tokenization. Here’s the idea:

  • When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.
  • Instead, they send the details to their merchant acquirer – e.g. Elavon – and ask them to issue a token.
  • The acquirer creates a random number that might look like a credit card number in some cases – the token – and returns it to the merchant.
  • The acquirer records all this information in its own database (i.e. the real card details, the token they issued and which merchant they issued the token to, etc).
  • The merchant stores only the token in their database, not the real card number.

Now, next time you try to buy something from that merchant, they send the token they’ve stored to the acquirer. The acquirer checks that the token is valid and that it came from the right merchant. And, if so, they convert it back to the real card number and process the transaction as normal.

The really important point here is that we no longer really care as much about the merchant’s security. If they get hacked, it’s not as much of a problem: the tokens are useless to anybody else. The acquirer will only accept them if they’re presented by the original merchant. If the hacker tries to use them somewhere else, they simply won’t work.

Excellent! A really simple system that dramatically reduces the risk of fraud and lowers risk and cost for merchants. You can think of it as if the “circle of trust” has been shrunk:

PushPull3

If merchants use tokenization services, the implications if they get hacked are far less serious. (TSP stands for “Token Service Provider”)

And this is nothing new. Acquirers have offered this service for ages for merchants who wanted to use it.

Great. Problem solved?

Not so quick….

Now think about Apple Pay and think about the challenges Apple faced in getting this to work.

Here’s how contactless payments are supposed to work when you pay for goods in store: the cashier rings up the price and activates the contactless pad so you can pay. You tap your contactless card and you’re done. This piece is completely normal: anybody with a contactless (“PayWave” or “PayPass”) card can do that today. It’s what I’ve done with the PayTag on my iPhone 4 for ages.

But how do you get a phone to pretend to be a contactless card? Well that’s a solved problem too. Android devices have done it in various ways for years, for example.

So what’s the problem? The answer is: security. Sure… you can put somebody’s card details into the “Secure Element” of a phone (or do something clever with Host Card Emulation) but if you’re putting the real card number in there then you face all the same risks a merchant faces… if somebody were to figure out how to hack into your system, you’ve got a big problem on your hands… And in Apple’s case, imagine if almost 1 billion payment cards were compromised!

So it would be much safer if you stored a token on the phone, rather than the card details themselves. That way, if the system is broken, you can just invalidate all the Apple tokens and you’re done.

But there’s a really subtle problem

How does a firm like Apple get the tokens? Remember: they want to emulate a contactless card so that the customer can use the phone to pay at a merchant. You don’t know which merchant acquirer any given merchant uses so an acquirer-specific token is useless!

So Apple can’t use the merchant acquirer services to get its tokens… imagine it put a First Data token on its phones. What happens if you try to pay for something at a merchant who uses Elavon? It isn’t going to work…

And this is where the EMVCo spec comes in. In short, the EMVCo spec proposes is that tokenization be standardized and it implies strongly that it should be the schemes (or maybe issuers) who perform the work, not the acquirers.

Effectively, they’re proposing the circle of trust be tightened even further:

PushPull4

I scratched my head at first… apart from perhaps being a power grab, why would anybody bother change this simple model?

The answer was on page 26, section 3.8 and the introduction of the idea of a “token requestor”. What the EMVCo spec highlighted – and what I missed at the time – was that it isn’t only merchants who might want to create tokens… other players might need to as well… players like telcos and Apple:

“Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to Card-on-file Merchants, Acquirers, Acquirer Processors, and payment gateways on behalf of Merchants, Payment enablers, such as original equipment manufacturer (OEM) device manufacturers, Digital wallet providers, Card Issuers”

(EMVCo Tokenisation Spec, page 26-27, my emphasis)

Of course!

Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers.

You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services. Indeed, Visa Inc have written about their service here.

And so I think that’s what’s going on. Apple is acting as a “Token Requestor” in the EMVCo model. When you enter your card details or take a picture of your card with your iPhone 6, Apple will call the Token Service for the appropriate network – let’s assume Visa. Visa will check the details (maybe your postal code, CVV2, etc) and perhaps authorize with the issuer.

And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem. But it will look just like an ordinary card number so acquirers will be able to process it without even realizing it’s a token.

And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it.   So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.

In summary, my take on the interesting aspects of the Apple Pay announcement are:

  • It’s looks like a really nice use of the EMVCo “Token Requestor” concept
  • It relies on schemes having Token Service Providers up and running so don’t expect it to roll out everywhere, for all schemes, any time soon.
  • It’s surprisingly vanilla.
  • It’s conceivable that Apple is taking zero cut from any of this. They’re certainly not in the transaction flow in any meaningful way
  • But notice how much leverage it gives them over issuers. It would be easy to refuse to include an issuer’s cards on the platform unless the issuer pays up. That has the interesting property that deals could be done on a case-by-case basis and different issuers may have different deals.

 

This is, of course, just my analysis from public information. I have no inside knowledge and I could be completely wrong. In particular, I’m struggling to reconcile my analysis with some claims that Apple Pay will use a different token for every purchase. I don’t understand how that would work, unless we assume the phone is online at point of purchase? Anybody know for sure? Am I way off the mark?

What happens if Bitcoin mining companies vertically integrate?

Creeping centralization can come in many forms – are the Web Application Server wars a lesson from the past?!

First some history of the IT industry (you can skip this bit if you just want the meat…)

Travel back in time with me to the late nineties…. I started my career during the Web Application Server wars. The web was taking off in the late nineties and companies like WebLogic (quickly acquired by BEA) spotted a need in the marked for a Web Application Server.

They were solving an obvious problem: it was a real pain to write proper applications. Sure: you could write HTML and run it on Apache. And you could use the CGI interface to have scripts run to generate basic dynamic content. But it was painful to do anything more sophisticated

If you were a bank that wanted to build an online banking service that interfaced with your core banking system, it needed a huge amount of effort and care… and you were wholly responsible for figuring out how to manage session state, failover, transactionality and everything else. And what we quickly found was that everybody needed a similar set of code “middleware” services – and were building for themselves each time.

And one solution to this problem was the web application server. This was a server, usually written in Java, that provided a defined set of APIs and an execution environment for web applications.    You could think of it as having two faces: one face spoke “web” – it sent and received HTTP. The other face spoke “enterprise” – it provided a set of APIs, SLAs and common behaviours that app developers could rely on to build their applications.

Products like BEA WebLogic, as it became, Netscape Enterprise Server, IBM WebSphere Application Server and Microsoft’s Internet Information Services platform were all designed to solve this problem… and it became a billion-dollar industry.

Sure – somebody still had to buy, configure, install and manage these platforms (usually in corporate datacenters, running on expensive hardware) but at least there was now a clear separation: and a division of labour emerged: J2EE developers, App Server administrators, infrastructure engineers and so on.

Today is different but not that different!

Fast-forward to today and the world is different: we take a rich execution environment for granted and the state-of-the-art consists of cloud offerings that protect the developer from worrying about anything apart from their code: infrastructure, connectivity, bandwidth, middleware configuration is all delegated to the platform. (IBM’s BlueMix is a recent example of such a service)

But the insight is the same: in any field, we see lower levels of the stack become standardized and commoditized. A small number of specialized players, with economies of scale and benefitting from experience-curve effects, begin to dominate.

So I’ve often wondered if we’ll see something similar in the Bitcoin space.   Are there any parallels we can draw and, if so, what can we learn from them?

Can we see any parallels with Bitcoin infrastructure?

Look back a few years and anybody wanting to build a product or service on Bitcoin had to do it all for themselves.

For example, it seems that Mt.Gox wrote their own custom implementation of the Bitcoin protocol – which is not, perhaps, surprising given the nature of its business and the maturity of the ecosystem when it was founded. I guess that’s similar to people who wrote their own HTTP servers or implemented custom schemes for producing dynamic content back in the nineties.

More recently, APIs like BitcoinJ and platforms like BitsOfProof have emerged as credible abstraction layers upon which interesting products and services can be built. In both cases, developers typically run and maintain their own instance(s) of  Bitcoinj or BitsOfProof, etc. So one could argue this is a parallel to the on-premise app-server days of the web.  

So it’s tempting to ask… are the parallels with the web appropriate? If so, what happens if cloud-based services for Bitcoin developers emerge?

And, of course, we don’t need to imagine. These services already exist. chain.com is one such example.

Chain.com is a cloud-based Bitcoin API for developers. From their website, it appears that they maintain a set of Bitcoin nodes and ensure they are well-run and well-connected, perhaps in the way that Amazon or IBM might maintain app servers, infrastructure, routers and connectivity to major peering points on the internet.

And developers simply write their Bitcoin product or service in a language of their choice, calling the Chain APIs as and when they need to interface with the Bitcoin network.  One can imagine that coding against Chain.com makes it an order of magnitude more easy to get a new Bitcoin company up and running. You don’t need to worry about any of the infrastructure detail: Bitcoin is abstracted away to a set of easy-to-use, well-documented, high-level APIs.  

You might hardly even know you were even using Bitcoin!

And that’s a really important subtlety: if you are not running your own Bitcoin nodes, how do you know the information your service provider is giving you is accurate? How do you know you’re connected to the “real” network and seeing the real blockchain and that your transactions are making it across the network?

Now I’m sure the chain.com team are hugely competent and ethical people. This post is emphatically not a criticism of them or their service. But one does need to be open-eyed about the tradeoffs one is making as an engineer.  And one approach app developers could take might simply be to maintain their own independent copy of Bitcoin core to act as a monitor/sentinel.  It’s probably not a show-stopper.

And I can see this sort of service being immensely popular: it is a lot of effort to install and maintain Bitcoin network infrastructure… keeping it patched, making sure you really are well-connected to the Bitcoin network and so on… and if your business has latency dependencies (mining? Exchanges?) then you also need to worry about making sure your nodes are “close” to other major nodes. And so on and so forth.

Figuring out how to do this sort of stuff well has good scale effects and there will be big learning/experience curves. Just as cloud vendors can run web infrastructure better and cheaper than most companies could do themselves, we should probably expect to see small startups outsourcing their Bitcoin network integration to firms like chain.com – and maybe even hosting providers who include Bitcoin APIs and network abstraction as a core part of their service offering.

So, leaving aside the concerns this might raise around decentralization and ask yourself:

if a cloud-based Bitcoin API/application platform were to become really popular, who is best placed to deliver it?

Until a few weeks ago, I would have said I expected more firms like chain.com to be founded over the coming months and for a handful of them to gain critical mass and become the dominant application platform players of the future.

And then CoinTerra bought BitsOfProof

It was one of those lightbulb moments for me when I heard about it. Of course! How Obvious!

It makes perfect sense. Think about the capabilities and advantages that big mining firms have that they could use to build a powerful hosting proposition for developers:

  • Hosting in low-cost locations
    • They already maintain massive farms of servers, usually in locations with cheap power. They could easily offer colocation to their clients
  • Massive hashing power
    • They could commit SLAs to application clients that nobody else could make – “At this SLA, we will guarantee your transactions make it into a block within x hours”, perhaps?
  • Optimised network connectivity
    • The mining firms must surely have deep knowledge of the Bitcoin network topology so I suspect they could make promises about transaction propagation times and other time-critical requirements that would measure to some clients – “You will see transactions from other people faster on our platform than if you ran your own node”, perhaps?
  • 100% Virgin coins on tap
    • Mining companies can offer businesses who use their APIs access to freshly-minted coins… no taint, no need to ask where they came from
    • … and I’m sure there are more

Many observers, myself included, have tended to ignore mining, regarding it as an infrastructure function, with the main debate being around the threat of concentration of hashing power. What I missed until now is that a well-run mining platform is also a phenomenally powerful platform from which to build up the stack to middleware/APIs and beyond.

So the question for me is: what happens if (when?) one of the mining firms offers a hosted application environment for Bitcoin companies with a really easy-to-use abstraction API over the Bitcoin network?   Commentators such as Tim Swanson have written extensively about the incentive structure of Bitcoin mining but I’ve not yet seen an analysis that thinks through the implications of vertical integration of the sort I outline here – and what it would mean for any security analysis of the system as a whole.  

If anybody’s aware of one, I’d love to read a copy.

Disclaimer: I’ve not spoken to any of the firms named in this post and I have no insight into their product plans

A simple explanation of fees in the payment card industry

I wrote a piece last month explaining how the payment card industry works.  I talked about the various actors (acquirers, issuers, schemes, merchants, etc) and pointed out how weird it is that everybody knows the Mastercard and Visa brand names yet nobody actually has a relationship with them. One of the questions I didn’t address there was fees.  Who makes all the money? Why does it seem so expensive?

Let’s start with the standard four-party model: Merchants, Acquirers, Issuers and Schemes:

Four Party Model Fees 1

The four-party model: Merchants obtain card processing services from Acquirers, who route transactions via Schemes to Issuers, who debit Consumers’ accounts.

A Worked Example

The key point is that one firm from each category is going to be involved in every payment card transaction.  So it’s interesting to ask: how much do they get paid?

Let’s take a concrete example and work it through.  Bear in mind: this is just an example. As you’ll see, there are almost infinite variations and some merchants will pay fees considerably higher than the ones I discuss below.  Also, note: this information all comes from public sources.  I use company names below for clarity but I have no private insight or information into their fee structures

The Scenario

Let’s imagine I’m using a Visa Debit card, issued by a US bank (let’s say Bank of America) to buy $100 of goods from an online retailer.   What happens?  From my perspective, of course, it’s obvious: I’m paying $100!

Four Party Model Fees 2

Imagine I am using my Visa Debit Card, issued by Bank of America to pay for $100 goods from an online retailer.

The Merchant’s Perspective: The Merchant Discount Fee

What does the merchant see?  Well, the merchant will have a contract with an acquirer.  What does that look like?  Let’s take an example.  Costco have a page on their website that refers small merchants to Elavon for acquiring services.  Let’s use the pricing displayed on that page for Online transactions:

1.99% plus 25c per transaction (plus some other recurring/monthly fees, etc)

Many readers will be thinking that seems low but let’s go with it for now.

So, for our $100 transaction, we can calculate how much money the merchant will actually receive from Elavon/Costco:

  • Transaction value: $100
  • Elavon/Costco takes 1.99% + 25c = $2.24. This is often called the “merchant discount fee
  • So merchant gets $97.76

So our picture now looks like the one below:

Four Party Model Fees 3

Merchant receives $97.76 from the $100 transaction. Elavon gets $2.24.  But how is the $2.24 distributed between the acquirer, issuer and scheme?

The Issuer’s Perspective: The Interchange Fee

So we know how much money the merchant has paid to the “credit card industry”. But how is that money allocated between all the participants?   Visa Inc has a very helpful document on their website, which tells us part of the story: Visa U.S.A. Interchange Reimbursement Fees.

The key word here is “Interchange”.  Interchange is the fee that gets paid to whoever issued the card – and it’s set by the scheme (Visa in this case).   You’ll see in that document that this is not straightforward… there are pages and pages of rates:  the interchange fees vary based on whether the card was present or not – and on the type of good or service being bought, whether it was a debit or credit card, whether it was a corporate card, whether it was an international transaction and lots of other criteria…

So let’s just pick a simple example.  We’ll go with page 2 – “CPS/e-Commerce Basic, Debit” (Card not present).

Aside: CPS means that the merchant has complied with various Visa rules (such as validating customer address to reduce fraud risk, etc) and has thus qualified for a low cost option.  

So the issuer is entitled to 1.65% + 15c

  • Transaction value: $100
  • Issuer receives 1.65% + 15c = $1.80.  This is the interchange fee
  • So issuer owes $98.20 to the other participants (Visa, Elavon and the Merchant)

And we already know that the merchant only gets $97.76 of that money (their merchant discount fee was $2.24, remember?).  So that means there is 44c left to share between Visa and Elavon.

The diagram below shows the current state of the calculation:

Four Party Model Fees 4

Interchange Fee (what the issuer gets) is $1.80

So how is the remaining 44c allocated?

We’ve assumed the switch is Visa so we need to know much they charge.  CardFellow.com has a good explanation.

We’ve assumed a Visa Debit card so, according to that site, Visa’s fee, which we call the “Assessment” is 0.11%.   There is a menu of other charges that might apply but we’ve assumed this is a low-risk “CPS” transaction so we’ll assume none of them apply.  (In reality, the 1.55c “Acquirer Processing Fee” probably applies)

  • Transaction value: $100
  • Visa assessment is 0.11% so Visa charges 11c. 
  • So there is $98.09 to pass on to the acquirer.

And if there is $98.09 to pass on to the acquirer and we know that the merchant receives $97.76, that must mean there is 33c left for Elavon.

So there we have it… in this VERY SIMPLE, highly contrived – and probably unrepresentative – example, we end up with the result in the diagram below:

  • Consumer pays $100
  • Issuer receives $1.80
  • Visa receives $0.11
  • Acquirer receives $0.33
  • Merchant receives $97.76 – overall fee $2.24

Four Party Model Fees 6

Final picture showing how the merchant’s $2.24 fee is allocated

As I’ve stressed above, this is just a simple example but it shows two key points:

1) It is the issuer who receives the bulk of the fees (this is, in part, how they fund their loyalty schemes, etc)

2) The schemes actually earn the least, per transaction, of any of the participants.  This underlines, again, how powerful their business model is:  by being at the centre of a very sticky network, they can earn a lot of money overall by charging very low per-transaction fees.   [Edit 2013-08-10 10:35 : it's also worth noting that the acquirers and schemes have pretty much fixed-cost infrastructures - unlike issuers, who need to hire customer service and debt collection staff in proportion to number of cards issued. So the schemes and acquirers also benefit disproportionately from rising volumes.  So: low fees for schemes/acquirers for sure... but HUGE volume is what enables them to make big profits]

[Note: I use blog posts like this to help clarify my own thinking and understanding - as well as to share knowledge...  and there are one or two pieces here where I'm not 100% confident I got it totally correct... so please do tell me where I'm wrong if you spot something]

[Update 2014-08-09 18:47 Minor typos and replaced last diagram]

Think Payment Cards are Insecure? Just Wait Until Push-Payments Hit Primetime…

What Brazil’s Boleto Fraud Tells Us About Bitcoin and other Push Solutions

When I explain to people how payment cards work, they are usually aghast. I point out that when you hand your card to a merchant and sign your name or enter your PIN, you’re authorising them to suck funds out of your account and the only thing that stops somebody draining all your money is trust. The picture below shows the standard “four-party” model for payment cards and I stress that the consumer is merely authorising payment; it’s the merchant and all the other actors who actually move the money.

PushSecurity1 

The Payment Card “Four-Party” Model: Consumers authorise merchants to pull money out of their account.

(Aside: I’ve never understood why this is called the four-party model. I count at least five parties on that picture…)

Online, the problem is more stark: you type your card details, including your CVV2 “secret number on the back” into your browser and hope for the best: you have to trust the merchant, their IT supplier, the acquiring bank, their third-party processor, the card network and your own card issuer – and everybody who works for them and has access to their systems. If a bad guy gets hold of your card details at any point in this process, they could drain your account. The picture below shows the scope of all the entities with access to your critical card information:

PushSecurity2

Your Primary Account Number – PAN – passes through the hands of pretty much everybody involved in processing the transaction.

It seems mad: why would you spray such sensitive information all over the place willy-nilly? Whoever thought it was a good idea to build the system this way?!  Except… the system works.

Fraud is surprisingly low given the design – and consumers get compensated if something goes wrong. And the design isn’t actually as mad as it seems: how else would you build a consumer payment network in a world where you can’t assume the consumer has a smart device with guaranteed network connectivity?

Payment card networks also have the advantage of decades of experience and refinement. For example, the Payment Card Industry Data Security Standards (PCI-DSS) lay down rules and guidance on how to protect the sensitive card data. The EMV smartcard standards make it harder to clone cards. Issuers have sophisticated heuristics to block suspicious transactions. And forthcoming moves to standardise “tokenisation” (something I should blog about one day) will further mitigate the risk of card details getting into the wrong hands. So an underlying architecture that appears wholly unsuited to the web age has actually been patched up to be good enough (but not perfect – and it still has lots of problems)

The Push Pay Revolution – a better way to do retail payments?

As I’ve written often, there is an entirely different way to design a retail payment system, one where the consumer doesn’t have to trust nearly as many people. I call these sort of payments push payments.  Bitcoin follows this model, as does M-Pesa, iDEAL, ZAPP and the Boleto system in Brazil. The defining characteristic of push-payments is that the consumer is in the driving seat.

With Push, it is the consumer who instructs a payment – from their bank or telco or Bitcoin wallet

This is unlike pull-payments, where the consumer merely authorises the merchant to pull the funds from their account.   The difference may seem subtle but it turns out to be hugely important. The picture to have in mind for push-payments is this one:

PushSecurity4

Push payments have a very different threat model to pull payments. Now the consumer only has to trust their payment provider and their own device.

In previous articles, I talked about the benefits of push payments in terms of innovation and the reduced need to trust quite so many people.   In this post, I look at one of the downsides: push payments can be compromised in hard-to-detect ways if they are not implemented really carefully.

So what’s the problem with push payments?

First, let’s remind ourselves about what we do have to trust and what we don’t have to trust in the pull world.

In the pull world, the consumer has to trust everybody else – and, as I’ve discussed above, there are various safeguards in place to fix things when they inevitably go wrong. One might argue that the safeguards don’t always work and that they come at a cost. Both arguments are, of course, valid but let’s leave them to one side for now.

In the push world, it’s different. The way it’s supposed to work is like this:

  • Step 1: The merchant “tells” the consumer how much they’d like to be paid and to where the payment should be sent. Examples:
    • With M-Pesa, this is usually done in-person, verbally
    • With Bitcoin, it is either done ad-hoc or via a QR-code displayed by the merchant or via the emerging BIP70

To illustrate the point, here is a picture of me in Shoreditch trying to tell a Bitcoin ATM where to send some Bitcoins I’d bought. On my laptop screen is a QR code that represents my Bitcoin wallet address. Note how it’s me as the Bitcoin receiver who is telling the sender (the ATM) where to send the coins.     In the more common case, where I am paying Bitcoins, this means it is the merchant who has to show the QR code to me. I need to know where to send the money to.

PushSecurity5

This is me using a QR code on my laptop to tell a Bitcoin ATM where to send my Bitcoins. (The Apple Bitcoin ban was still in force when we took this photo… so I had to use my laptop rather than my iPhone…)

  • Step 2: Once the consumer has the payment request, they use a program or app on their smart device (laptop, smartphone, whatever) to instruct the payment. Examples:
    • An M-Pesa user launches the M-Pesa SIM app and instructs the payment
    • A Bitcoin user pastes the destination address and value into their Bitcoin wallet
    • … or uses their wallet to read the recipient’s QR code
    • … or opens the BIP70 Payment Request with their wallet)

When you put it like this, push payments are obviously superior, right? The consumer is in control, they don’t have to trust all those people and there’s no danger of a rogue agent sucking all their money out of their account!

Not so fast…

The analysis above neglects one small, but rather important, fact: devices get hacked.

In the pull model, the only devices that can get hacked are those inside the “circle of trust” – your plastic card is pretty impregnable.  And as the utterly disastrous Target breach suggests, consumers were made whole when the disaster happened. It was the big firms who messed up who suffered the consequences.  

Yes… I know this is counterintuitive… you must be asking yourselves: “is this guy seriously arguing that the Target disaster is an argument in favour of the current payment card model?!” Obviously, no…. the episode was clearly a catastrophe and it was really, really bad.   But… it did eventually get sorted out and the roll-out of EMV, tokenisation and better enforcement of PCI-DSS should reduce the risks of something similar in the future.   So I raise this merely as prelude to the push scenario.

Now ask yourself what happens if a device gets hacked in the push scenario.  The obvious question is: which device?   Well… the only device in the circle-of-trust this time is the consumer’s smartphone. Uh-oh.

This is the device from which we’re instructing real-time payments, right? The one that could be riddled with malware?

This might have been merely a theoretical risk…. And then the Brazilian Boleto fraud happened.

RSA have a great write-up of a country-scale real-life example of what can go wrong when push-payment systems get breached… and it’s really scary.

The Brazilian Boleto system is very cool.   At core, it is a way for fund requestors (utility firms, etc) to send a payment request to consumers. The request is known as a Boleto and they can be physical or electronic.

PushSecurity7

A Brazilian Boleto. Think of it as a mainstream equivalent of a Bitcoin BIP70 Payment Request…

The idea is this: the Boleto has details of the payment request and includes details of how much to pay and to where.   This is in coded text format and a bar code… basically, something that a consumer can take and feed into their banking app: scan the code with your mobile banking app, approve and you’re done. Or you could take it to a bank branch. And if you’re online, you could copy and paste the code into your online banking website and achieve the same end.

Except… the RSA paper shows all the ways it can and has gone wrong.

First, there’s a simple problem of authentication. How do you know the Boleto really did come from who it says it’s from?   The RSA paper documents examples of people receiving Boletos via email that look convincingly genuine but which have the fraudster’s payment account details in place of the firm from which they purport to come.

This is a real problem but it’s nothing new… it’s not really any different to fake websites that masquerade as real ones. We solved it in the pull world with SSL certificates and the like for websites. And the Bitcoin Payment Protocol includes the option to use the same PKI system, for precisely these reasons.

However, the RSA paper also discusses another attack – and this one’s scarier.

This second attack comes in the form of malware that runs in the consumer’s browser.   When it sees a document that looks like a Boleto, it silently changes the details that the consumer sees on their screen: the payment details are changed from the genuine recipient to the attacker. So when the consumer copies and pastes the details into their banking app, it’s the attacker’s account they’re sending the money to.

Variations on this theme are included in the paper but they all amount to the same thing: if the consumer’s device is compromised then it’s game over. And you don’t even need to compromise the whole device or get root-access… you just need to compromise the browser in this scenario.

There are various mitigation mechanisms one can implement (e.g. tying the payment instruction to a signed representation of the payment request and so forth) but the underlying problem remains: if you’re using the consumer device to instruct payments, you have an issue if that device is compromised.

Now, this risk is perhaps over-blown: the risks identified here apply equally to standalone mobile banking apps and we happily run these on mobile devices today, albeit with the belief that their bank will bail them out if something goes wrong. (It’s no surprise that banks are big users of technology like IBM Trusteer).

Similarly, Bitcoin users run their wallets on their devices, in the full knowledge that there is nobody who will bail them out if malware runs amok on the device.  

But I think the two-step dance of an end-to-end push payment request/instruction – where the device is responsible for turning the request into the instruction – is something new that needs deeper study.  So I think the Boleto story tells us is that we need to think very hard about things like:

  • User experience: how is the linkage between Step 1 (receive and authenticate request) and Step 2 (populate and instruct payment) executed and communicated to the user? If step 1 is done by a different app to step 2, what is the hand-off? What security assumptions are being msde?
  • Validation and Reconciliation: what work should (can?) the “network” do to validate that a payment instruction purporting to be in response to a payment request, really is traceable to that request?
  • Malware detection systems: what new behaviours should anti-virus and other technologies be looking out for?
  • Wallet providers: which scenarios are you willing and able to protect your consumers against?

It is possible that this is just a variation on the age-old theme that end-point security is hard – but when things like the Boleto fraud happen, we should use it as an opportunity to look at the other systems being built along similar lines and ask: are there any lessons we can learn and apply?

Why the payment card system works the way it does – and why Bitcoin isn’t going to replace it any time soon

The Payment Card Industry’s weird business model is a work of genius

Regular readers will know that I am extremely optimistic about the long-term potential of Bitcoin and cryptocurrency technology to revolutionise the financial system. But that doesn’t mean I think they will overturn all aspects of the system.

In particular, I am skeptical of claims that Bitcoin will have a meaningful impact on retail payments and break the stranglehold of the payment card companies.

Of course, many people disagree with me. Articles such as this one from last year are typical of the genre: “credit card companies” are accused of charging obscenely high fees, hindering innovation and being ripe for disruption.

IMG_1600

Payment Cards fees might seem expensive but does it mean they are vulnerable to disruption?

Now, it’s true that the fees do seem expensive at first glance but, as David Evans has argued, it’s not obvious that the Bitcoin payment processors are really that much cheaper, once you take into account their spreads and the costs of getting into and out of Bitcoin at each end.

But the main reason I think the incumbents are in such a strong position is because the industry has extremely strong network effects, which leads to formidable barriers to entry. Would-be Bitcoin entrepreneurs need to understand this structure if they are to succeed.

The Payment Card Industry is marvellous and weird at the same time

When you step back and think about it, the modern payment card industry is a marvel – an underappreciated, underrated miracle of contemporary commerce: you can travel to any corner of the earth, armed only with a piece of plastic bearing the Visa or Mastercard logo. It’s a minor miracle.

But when you look at the businesses of the major card brands, they turn out to be really, really strange companies. They simply don’t do what most of us think they do.

Take a card out of your pocket… chances are, it will be a Visa or Mastercard, or maybe UnionPay if you’re one of my Chinese readers. Let’s assume it’s a Visa card for now. And we’ll worry about American Express later, because they’re different to all the rest.

Here’s one of my Visa cards again:

IMG_1600

A Visa debit card, issued by first direct bank.

Notice something strange. There are two brands on the card. There is the Visa logo and there is one for first direct, the division of HSBC with whom I hold my current account.   Most other consumer products don’t have two firms’ logos on them. Something strange is going on.

Now, it it was first direct that issued the card to me, not Visa.

It is first direct’s website I visit to see my balance, not Visa’s

And it’s first direct I would call if something went wrong, not Visa.

I don’t have any relationship with Visa at all.

There’s no Visa call centre I can call if I have a problem with my card and there’s no Visa app on my phone.  This is strange: a hugely powerful global brand and yet the billions of consumers who use it don’t have a relationship with them.

It gets stranger. Another little-known fact is that no retailer anywhere in the world has a relationship with Visa either!  So we have one of the world’s most recognizable brands and nobody who uses their “product” has any relationship with them.

It’s worth thinking through why this might be and why it is such a powerful model.

How would you build a credit card system if you were doing it from scratch?

Imagine you run a bank in a world before credit cards.   Wouldn’t it be great if your customers could go to local shops and “charge” their purchases to an account that you hold for them?   You could make money offering credit to the customers and make some more money charging the merchants for providing this service.

This is what Bank of America did in California in the 1950s. They issued credit cards to lots of their customers in various cities and signed up local retailers to accept them. Great – the payment card industry was born! You could think of the model looking something like this:

Cards Picture 1

A simple card scheme: a bank issues cards to its customers and reimburses local merchants who accept those cards

But this model has two really unfortunate problems:

  • Your competitors are going to copy this and you’ll soon have schemes like this popping up all over the country, all run by different banks, on different systems, racing to sign up consumers and merchants onto their product
  • Your customers will travel. And they will be very upset when they discover they can’t use your card in a merchant who only takes a different bank’s cards

You would end up with the situation in the diagram below: a merchant who banked with Bank B wouldn’t accept cards issued by Bank A. Why would they? They had no relationship with Bank A and who’s to say cards from Bank A would even work with their machines?!

Cards Picture 2

Why would cards issued by Bank A be accepted by a merchant who uses Bank B if Bank A and Bank B operate competing schemes?

If you were running one of the banks, how might you respond to this problem?

One answer might be to view this as an arms race: perhaps the best strategy is for banks to enter an all-out war… sign up as many merchants as they can… sign up as many customers as they can and bet that you’ll be the last firm standing when the industry shakes out. Obvious problem: it would be ruinously expensive and what happens if it ends in stalemate? You still have the same problem.

But there’s another option… what if you cut deals with other banks: agree for them to accept your cards at their merchants in exchange for you accepting their cards at your merchants. This sounds quite promising but… obvious problem: how on earth would the merchant handle this? They’d need a huge book by every till that listed precisely which banks they could accept card payments from and which ones weren’t allowed. It would be chaos… But perhaps it points the way

A flash of insight – who are you really competing with?

Let’s recap: you’re a bank executive trying to build a payment card business. But your competitors are all trying to do the same and it’s going to end in tears: you’ll confuse the merchants with hundreds of different card types or you’ll go bankrupt trying to be “last man standing”.

It feels like having other banks accept your cards at their merchants would be good… but how to make it work?

And this is where a flash of insight changed the world.

Somebody realized that the cards “business” was actually two businesses.

The first business is all about offering credit to your customers, managing their accounts and processing their payments. We could call this card issuing.

And the second business is all about enabling merchants to accept card payments and get reimbursed. We could call this merchant acquiring.


 

Aside: we call it “acquiring” because it’s helpful to model the card payment as a receivable that the processor purchases (acquires) from the merchant at a small discount, which you can think of as the processing fee.


This is the key point: issuing and acquiring are totally different businesses which don’t compete with each other.

Sure… all the issuers compete with each other.

And all the acquirers compete with each other.

But the issuers don’t compete with the acquirers.

Indeed, they have a really strong incentive to co-operate… the issuers want all the acquirers to accept their cards… and the acquirers want to offer their merchants the ability to accept as many cards as possible.

So let’s imagine a group of issuers teamed up with a group of acquirers. And imagine they agreed that the acquirers would all process the cards of all the issuers in the group: every issuer’s card would be accepted by every acquirer.   They could use this forum to hammer out some standards: they would agree a common way to process cards, timescales for reimbursement, rules for what happens if something goes wrong… they’d define a “scheme”.

Now… this scheme would need two things: consumer recognition and merchant recognition. Consumers would need to know their card would be accepted at a participating merchant. And participating merchants would need to know a given card was part of the scheme.

So we need a brand. This brand would be something you could put on the cards and place in the shop window. It is how a merchant would know an issuer’s card was part of this scheme and it is how card holders would know a merchant was able to accept cards from that scheme.

One of these schemes is, of course, Visa. Another is Mastercard. And so on. And this is why cards carry two brands…. One to identify the issuer and one to identify the scheme.

In this way, the card schemes have created a system that allows merchants, who only have a relationship with their own bank, to accept payment cards issued by hundreds of other banks, without having to have any relationship with those banks at all.   The only thing that matters to them is that the issuer’s card is issued on the relevant scheme.

And this model has really strong network effects… the more issuers and acquirers in the scheme, the more useful the scheme is to card holders and merchants. It’s self-reinforcing.

Talk is cheap… how does it work in practice?

OK. So we have a paper agreement that says an acquiring bank will accept any valid transaction made with a Visa-badged card.   But how? How do they get approval from the issuer for the transaction? How do they get reimbursed? How does it work in reality?

Do all members of a scheme have to have a relationship with every other member so they can route the transaction to them for payment? That would be expensive and error-prone.

So this is where the scheme re-enters the picture.   In addition to maintaining a powerful brand and setting the rules, they also run a switch: the merchant acquirers send all their Visa transactions to Visa itself… and Visa then forwards them on to the appropriate issuer.   Similarly for Mastercard and the other schemes.

So we end up with a hub-and-spoke model… with Visa at the centre. (And Mastercard and Union Pay and so forth).

Cards Picture 3

Issuers and Acquirers are members of a “scheme”, which sets the rules and acts as a central “switch” to route transactions. It means merchants with one bank can accept payments from customers of another bank, without having to maintain bilateral relationships

So now we can see why card schemes are so successful: their globally-recognised brands create networks that anybody aspiring to issue or process cards need to be part of. It’s a self-reinforcing virtuous circle that is extremely hard to disrupt

And this is why Visa’s “customers” are the issuing and acquiring banks… not end-consumers… Visa exists so that issuers can receive broad acceptance of their cards… and so that merchants can, in turn, offer broad acceptance.

But the schemes depend on consumer recognition – hence why they spend so much money advertising to consumers, even though the consumers are not their customers.

What does this have to do with Bitcoin? Push versus Pull

Notice something really important: this is a pull system… the reason you need all this infrastructure is because your card information has to get all the way from the terminal in the merchant back to the issuer so the issuer can pull the money from your account and send it back to the merchant.

By contrast, Bitcoin is a push system: once you know the merchant’s “account” details, you can just push the payment to them. So why do you need all these intermediaries?

If you were a Bitcoin payment firm trying to break into the retail market, perhaps that’s where you’d start? After all, it’s true that most of the payment card infrastructure simply isn’t needed in the Bitcoin world.

But notice how I set up this story. The infrastructure was the last thing I talked about. For me, the two most important things are:

1)   Global acceptance.

2)   The rulebook

Think about what Visa and Mastercard have achieved: they offer global acceptance and predictable behavior.   Wherever you are in the world, you can be pretty sure somebody will accept your card and you know how it will work and that there is a well-understood process when things go wrong. This offer is powerful. Ask yourself: if you could only take one payment instrument with you on a round-the-world trip, what would it be? If you couldn’t stake a stack of dollar bills, I suspect you’d opt for a credit card.

And this predictability – a consequence of the rulebook – is important: consumers enjoy considerable protections when they use a major payment card. They can dispute transactions and, in some countries, their (credit) card issuer is jointly liable for failures of a merchant. Consumers like to be nannied… even if they have to pay for the privilege!

So for those who aspire to overturn the incumbents, you need a strategy for how you will become the consumer’s “default” or preferred payment mechanism.

American Express has achieved this through a joint strategy of having large corporates mandate its use for business expenses and offering generous loyalty benefits to consumers… they effectively pay their customers to use their cards.

PayPal has achieved it through making the payment experience easier – but note, even here, many PayPal payments are fulfilled by a credit card account!

And this is why I harbor doubts about whether Bitcoin will become a mainstream retail payments mechanism, at least in the major markets… why would a consumer prefer it over their card?  Perhaps the openness and possible resistance to card suspension/censorship will attract sufficient users.  But it’s not obvious.

For me, the opportunity lies elsewhere: high-value payments, smart property and so forth.  But I could, of course, be wrong.  It wouldn’t be the first time…

An aside on history and factual accuracy

I know this account would scandalize a historian but that’s OK: It’s not intended to be historically accurate… the idea is to share intuition on why things are the way they are.

Some of the more important topics I’ve ignored or deliberately simplified include:

  • I’ve not explored the difference between Visa Inc (public company) and Visa Europe (owned by its members)
  • I’ve ignored the “three-party” schemes like American Express.
  • I’ve also ignored fee structures and the importance of interchange.
  • I’ve also not discussed the role of processors… specialist firms who effectively outsource the work of issuers and acquirers
  • Security
  • … and lots more