A Simple Explanation of Balance Sheets (Don’t run away… it’s interesting, really!)

Shared ledgers could be revolutionary but do we need to share a mental model for banking to make sense of it all?

What would be your first instinct if your friend were to tell you they had £1m in the bank? To congratulate them on their good fortune? To suppress a pang of jealousy?

Wrong, wrong, a million times WRONG!

The only acceptable first instinct is to shout loudly at them: “No! You fool! You don’t ‘have’ a million in the bank. You have lent a million to the bank. They owe it to you. How could you reveal so casually that your mental model of banking is so wrong?!”

If your first instinct was the correct one then you need read no further; there is nothing for you here.  But, for everybody else, you could be missing something really important.   And this could matter: as I’ve written repeatedly, we could be witnessing the emergence of shared ledger systems in finance – blockchains, if you prefer. And they will be used to record obligations of – and agreements between – firms and people of all sorts. A more complex (and larger) example of this, if you like:

BalanceSheet11

The four-column model of shared ledgers

To make this work, we’re going to have to get a lot more precise about how we think about financial relationships. And I’m pretty sure it all comes down to having a clear mental model for balance sheets.

What is a balance sheet?

Imagine you were starting a bank. You’d want to put a system in place to keep track of the finances: how much cash do you have in the vault? To whom do you owe money? How much have you lent out? And so on.

The basics are not rocket science and there are only two key reports at the heart of this: the balance sheet and the income statement (aka the P+L).

They exist to answer two important questions:

  • What do I own and how much do I owe? This is what the balance sheet tells you. Think of it as a point-in-time snapshot.
  • How did I do in the last period? That is what the income statement tells you. Think of it as the story for how you got from last year to this year.

In this piece, we’ll look at the balance sheet, because I think it’s the one you need to understand to make sense of where shared ledger technology could be going.

And the good news is: a balance sheet is simple… it’s just a two column table:

  • You write all the things you own – your assets – in one column
  • You write all the things you owe – your liabilities – in the other column.
  • If you own more than you owe, the difference belongs to your shareholders: their “equity” is what makes it “balance”.
  • If you owe more than you own, then you’re bankrupt (“insolvent”):

BalanceSheet1

A balance sheet only has two important columns: what you own and what you owe.

Let’s open a bank! 

So now let’s imagine you’re ready to start your small bank, “GendalBank”. Your friends think it looks like a good bet so they’ve agreed to contribute towards the £1m you need to get it up and running in return for shares.

£1m to start a bank?! As you can tell, my example is going to be very unrealistic indeed…

It may be obvious but I’ll say it anyway: they have no right to ask for this money back… it’s not a loan. But if you closed the company down, anything that was left after you’d paid off all your employees, suppliers and lenders, etc., would be returned to the shareholders.

So what they really have is a residual claim on the company. That’s what equity is.  And when you look at it this way, it’s obvious that equity is a liability of the company: GendalBank has an obligation to return what’s left over to the shareholders if it ever closes down.

So GendalBank has been set-up and the shareholders have handed over their £1m. How would we draw up a balance sheet to reflect all this?

BalanceSheet2

GendalBank’s balance sheet after the shareholders have paid for their shares. (Pedants: please forgive me… I omitted the trailing apostrophe on “Shareholders’ funds”. I don’t have time to update ten diagrams… but I can assure you the mistake pains me more than you)

It’s as exactly as we’d expect. Your new bank has £1m in cash – maybe you’re holding it in a vault or perhaps you’re holding it at the Bank of England.   But, either way, this cash is now GendalBank’s… it doesn’t belong to the shareholders any more; it belongs to the company. It’s the bank’s asset now. It can use that cash for whatever it likes. So we note it down in the assets column.

And remember what the shareholders have paid for: a residual claim on the company. Well, there are no other claims on the company right now, so we record a liability to the shareholders of £1m. If we closed down right now, they’d be entitled to be paid £1m.

It bears repeating: bank capital is a liability.   And this turns out to be a really useful thing to know. Because it allows you to spot charlatans at a thousand paces… any time you hear somebody talking about capital as if it were an asset of the bank (“holding more capital” is a great giveaway) then you know they don’t know what they’re talking about…

(I can’t help thinking making statements like that opens me up for all kinds of ridicule when the faults of this piece are identified…)

Great… so now we buy some IT equipment and an office with some of that cash. So perhaps the balance sheet looks like this at the end of the first week:

BalanceSheet3

We use some of the cash to buy some equipment and an office, etc

To keep things really simple, I’m going to assume the bank has no expenses. I did say this was a very unrealistic example! So we’ll assume we own the office and that there are no employees to pay. This is just to avoid having to look at the income statement for now.

And now we’re open for business… time to make some loans…

Bob walks in off the street and asks to borrow £100k because he’s planning on buying a very nice car at the weekend. He looks a trustworthy sort so we make the loan.

And now another really interesting happens: we create money out of thin air…

BalanceSheet4

Our loan to Bob has created money out of thin air!

Now Bob hasn’t withdrawn any money yet – he’s not buying the car until the weekend, remember. But look at how counterintuitive the balance sheet has become.

Look first at the asset side: we still have £500k cash, of course: he’s not drawn anything out yet. And we see the £100k loan to Bob. That’s our asset since Bob is obliged to pay us back £100k in the coming months and years.   That’s a valuable promise to hold – it’s an asset of the bank, for sure.

Aside: just as above, I’m making some massive simplifications here, not least that I’m completely ignoring interest rates and discount rates, etc.   Humour me 🙂  

And now look at the liability side: it records that we owe £100k to Bob.  That’s fair enough. If he looks at his account, he’ll see £100k there that he can withdraw whenever he likes. As far as he’s concerned he thinks “has £100k in the bank”.

So we have £500k of our own cash – either in the vault or at the Bank of England. And Bob thinks he has £100k “in the bank” as well.

Hang on… what’s going on? Did we just turn £500k into £600k by updating a spreadsheet?! Or does this mean that £100k of the £500k is now Bob’s? Or what?

The way to understand this of course is to observe that the £500k is our asset , whereas the £100k is Bob’s asset – and our liability. They’re not the same thing at all and it makes no sense to compare them in this way.

And so here’s another way to spot a charlatan: if you ever hear somebody talking about bank deposits as if they’re assets of the bank, you know you can safely ignore anything that person says…   As this example makes clear, bank deposits are liabilities… and you have to be careful around them… because customers have the annoying habit of asking you to give them the money so they can spend it on something.   And, to do that, you’d better have enough cash (on the asset side of your balance sheet, remember) to be able to honour that request.

This is what people mean in this context when they discuss “liquidity” – do you have enough cash or stuff you can quickly turn into cash to meet withdrawal requests from your customers?

Aside: in many ways, this conundrum is the absolute heart of banking: how to manage the problem of issuing short-dated liabilities (e.g. demand deposits) whilst holding longer-dated assets (e.g. one-year car loans). There’s even a name for it: maturity transformation.   It obviously relies on not all “depositors” wanting “their” money back at the same time and so is inherently unstable.

But it turns out we do have enough cash on hand. So we get to live another day.

And this could go much further…. We could make lots of loans. As long as not everybody wants to take out money at once, maybe we’ll be OK. Let’s imagine lots of other customers plan to make some big purchases in the future and borrow some money from us. This is what the balance sheet would look like immediately after we’d made those loans but before any of them had withdrawn any of the cash:

BalanceSheet5

We make lots of loans and make the balance sheet bigger and bigger…

What happens if the people who borrowed the money from us want to draw out the cash? They presumably borrowed the money for a reason, after all…

Well, that’s probably OK too, at least in “good times”. Let’s say they ask to withdraw £5m between them. There’s the minor problem that we don’t actually have £5m in cash… we only have £500k. But that’s OK…   provided we’re not bust – that we’re solvent – and people believe we’re solvent, perhaps we can borrow the cash temporarily from somebody else – maybe the central bank.

So that’s what we could do:

BalanceSheet6

We borrow £5m cash from somewhere else and use it to pay the depositors who want cash. Notice “deposits” have reduced by £5m and loans from other banks have increased by the same amount. The asset-side of the balance sheet is unchanged in this example.

Of course, another thing we could have done was sell some of the loans to somebody else for cash. And that would have also reduced the size of the balance sheet… since we’d only have £5m loans remaining on the asset side.

But it’s counterintuitive, isn’t it? We set up a bank that is making lots of loans and we’ve not yet taken a single deposit!

Indeed, it’s even weirder… we’ve created deposits seemingly out of thin air by the very act of making these loans. Where else did Bob’s “deposit” come from except from the fact that we made a loan to him?   And it turns out this is a really important point. The Bank of England, no less, argues that this mechanism is the primary way money is created in the modern economy. Everything you were taught at school about how banks need to take in deposits in order to make loans isn’t actually true…    But let’s leave that debate for another day…

“Deposits”

I once wrote a piece explaining how payment systems work. I was blown away by the response: hundreds of thousands of hits, huge numbers of them from people at banks. Clearly: this stuff isn’t as obvious as perhaps it should be.

One of the key points I made in that post was the one I was hinting at above: it makes no sense to say you’ve “paid money into the bank” or that you have “money at the bank”. There’s no jar in the back office containing your money, with your name on the front. Instead, when you “deposit” money with a bank, what you are actually doing is lending it to the bank. It ceases to be yours and that cash becomes an asset of the bank. It becomes theirs, to do with as they wish.   In exchange, they make a promise to you: to give you cash in the future if you ask for it. You acquire a claim on the bank.

So let’s see how that works. What happens if and when somebody finally does make a deposit?

Let’s imagine Alice has just sold her house for £500k and needs somewhere to park the cash for a few days:

BalanceSheet7

We have an extra £500k on hand as a result of a £500k deposit from Alice.

So this works as we’d expect: we record the fact that we owe £500k to Alice – our liability – and that we have an extra £500k in the vault (or with the Bank of England) – our asset.

OK, OK, Enough! What does this have to do with distributed ledgers?!

Well done for getting this far.    Why have I written so many words and laboured so many points? Because, and as I argued recently, we could be moving to a world where agreements and obligations between firms are recorded on a shared ledger at the level of an industry or market, rather than on private systems maintained separately by each of the players.

And, if this is true, we’re going to need to represent the idea that Alice has a £500k deposit at GendalBank or that Freddie has borrowed £500k from “OtherBank”.   And this is only going to work if everybody building this systems has a deep, intuitive sense that “deposits” should be modelled as “claims against an identifiable entity” and that £500k at GendalBank is fundamentally different to £500k at OtherBank and so on. I think we need to be thinking in terms of a “four-column model” of “issuer”, “holder”, “assetID” and “quantity”:

BalanceSheet11

Will the “four-column” model be the core data structure of the shared ledger world? (This is not an original idea to me: the concept is at the heart of systems like Ripple, Stellar and Hyperledger, amongst others)

Perhaps more importantly, once you start thinking about things in this way, it becomes possible to see the outlines of how the future state could work.

One can imagine a world where the bank still records that it owes some money to its customers but the shared ledger is the place that records precisely who those people are. This is fundamentally different to using the shared ledger as a mirror (or mirroring it to the bank’s own ledger) – it’s more akin to seeing the shared ledger as a partial subledger.

And it might perhaps be something that gets adopted to different degrees by different firms.

Perhaps GendalBank just uses the shared ledger to record some balances. So we update GendalBank’s system to say that it owes £5m to somebody but that it’s the distributed ledger that records to whom. And we see on the distributed ledger (above) that these people are Charlie and Debbie. So the total (£5m) is recorded in both places but only the shared ledger keeps track of the fine-grained detail. So it becomes a logical sub-ledger for some deposits (“DistLedger below) whilst the bank’s own ledger is used to record other facts.

BalanceSheet12

Perhaps GendalBank only uses a shared ledger to record details of some accounts (“DistLedger”) and continues to maintain others locally.

OtherBank, by contrast, might go further and move pretty much everything to the distributed ledger – both records of its liabilities and assets. So OtherBank’s internal ledger is extraordinarily simple: it just records the value of assets and liabilities managed externally on the shared ledger:

BalanceSheet13

OtherBank has “outsourced” or moved all processing to the shared ledger

So what?

Let’s look at the shared ledger again:

BalanceSheet11

Imagine you’re Charlie. If you have the ability to read/write to this shared ledger, you could pay away your claim against GendalBank to any other user of that ledger without having to go through any of GendalBank’s systems. We’d have decoupled the deposit-taking and lending functions from the record-keeping, accounting, payment and trading systems.

If you were OtherBank, you could sell your loan to Freddie to somebody else and the business logic might move with the loan (the “smart contract idea): previously illiquid assets might become tradeable under this model.  As I keep saying, this space is about more than just payments, after all.

Now, obviously: there is a lot of detail here that I’ve not even touched on. The reality is going to be so much more complex than this.

But hopefully this sketch shows some possibilities for where this could be going. And, like I said earlier, none of this will happen unless we get everybody to the same page with the right mental model for how banking works…

Appendix: Aside on Regulation… what stops us going completely mad with this?

I can’t write a piece on bank balance sheets without talking about risk.   And a legitimate question is: if my analysis above about how loans are made and deposits are created is correct, what’s to stop us going completely mad and taking in huge amounts of deposits or making huge numbers of loans? Don’t irresponsible banks tend to get into trouble and need to be bailed out? Well, yes they do.   And there are (at least) two very different things that can go wrong.

Illiquidity

The first problem banks can face is one of liquidity.   Imagine lots of customers want their money back at once and the bank doesn’t actually have enough cash on hand. What happens?

As discussed above, the bank might be able temporarily to borrow the cash from somebody else. But what if nobody wants to lend it to the bank? They’d be suffering from illiquidity: the value of their assets exceeds their liabilities, so they’re not bust… but they can’t meet their obligations to repay people. Oops!

In most countries, the central bank will step in in such scenarios and temporarily lend the money to the banks.   Indeed, we might say that the ECB’s “Emergency Liquidity Assistance” programme for Greek Banks was an example of this: on the assumption (pretence?) that the Greek banks weren’t bust, the ECB lent increasing amounts of Euros to the Greek banks to support deposit outflows.

From a regulatory perspective, rules such as the Basel Accord’s “Liquidity Coverage Ratio” is an attempt to force banks to hold enough cash (or cash-like instruments) on their balance sheet for forseeable withdrawals.

Insolvency

Another problem banks can run into is insolvency – being bust.   It’s easy to see how this could happen:

Imagine that some of the people to whom you’ve lent money lose their jobs or their companies go bust and you suddenly realize there is no way they will ever be able to repay their debts to you.

Let’s say £2m of the loans you’ve written become unrecoverable. So you “write down” the loan book from £10m to £8m… since you now know you’ll only ever recover £8m.

Now your assets are worth £9.6m.   But your liabilities haven’t changed.   You still owe £10.6m to your customers and the banks you’ve borrowed money from.

You owe more than you own. Game over. Good bye. You’re insolvent.

BalanceSheet8

Your losses on loans mean your assets are now smaller than your liabilities. You’re bust

But notice something really interesting…. If you’d only lost £500k on your loans, you’d have been OK because your assets (£11.1m) would have still been greater than your liabilities (£10.6m):

BalanceSheet9

… but if you only lost £500k on the loans you’d have been OK

So you can lose some money on your assets and be OK. But if you lose too much, you’re in trouble. What determines how much you can afford to lose? The answer is capital – shareholders’ funds.

You got away with the £500k loss but not the £2m loss because of your capital.   Your shareholders took the hit. Before the bad debts came along, their residual claim on the company was worth £1m. A £500k loss takes their claim down to £500k. But in the £2m bad case above, the loss was greater than the “loss-abosrbing” cushion of £1m provided by the capital and that’s why you went bust.

And so this is why regulators are so fixated on capital: the more the bank is funded by capital rather than deposits or debt, the more resilient the bank is when they make losses on their assets. Capital can be written down to absorb losses on assets in a way that debt can’t.   It’s why you hear so much talk about “capital ratios” and the like: what percentage of your assets should be financed by capital rather than debt?

But notice: the bank is in no sense “holding” capital. You hold assets and capital is not an asset… Instead, think in terms of capital being a mechanism through which the bank is funded.

And these phenomena can interact:  if you are illiquid, you might need to sell lots of assets a “firesale” prices, turning a liquidity problem into a solvency problem.

[Update 2015-07-05 My description of insolvency is *very* simplified, as Ken Tindell has noted here… https://twitter.com/kentindell/status/617719608875872256]

The “Unbundling of Trust”: how to identify good cryptocurrency opportunities?

Decentralization and centralization are two ends of a continuum. Look for opportunities to disaggregate “bundles of trust” to identify good opportunities in the cryptocurrency space

There are so many potential uses for cryptocurrency technology. But how do you know if any of them are good ideas? Blockchain-mediated financial exchange? I have a good feeling about that one. A bank-sponsored local currency system for small businesses? My sense is that it’s probably a terrible idea. But short of going out and building it, how would you know?

So are there any test you can apply beforehand to figure out if a blockchain is a good technical solution for a given problem?   And can you turn a bad idea into a good idea?

It’s a topic that comes up regularly when I present to audiences on Bitcoin and cryptocurrencies. Here are some slides I often use in these discussions. Slide 15 is where I discuss this topic.

Slides I sometimes show when presenting on cryptocurrencies. These represent my views, not IBM’s. But they are Copyright IBM. Please do not reproduce without asking permission first.

For me, the key to deciding if an idea is good enough is the one I’ve summarized on page 15 of the deck: this space is all about decentralization and if your problem isn’t about centralization then this technology may not be for you.

That may sound obvious. But internalizing this point is the key to understanding what a good cryptocurrency use-case looks like. And how to turn a bad one into a good one. Because even if your problem looks centralised, there may be portions that don’t need centralised trust and unbundling those components could be the key to doing something valuable. Here’s what I mean…

Go back to the beginning: what problem was Bitcoin designed to solve?

Bitcoin was invented as an answer to a decades-old question:

How do you come to consensus about some facts with a large group of people when you don’t know each other and some of you are cheating?

In Bitcoin’s case, the “facts” are “who owns what?”

And one answer to that question is, of course: “we all agree to trust somebody (e.g. a bank) and now we don’t need to trust each other”. But the obvious problem is: you have to trust the bank and that’s a potential point of failure. The breakthrough of Bitcoin was in showing us how to answer this question in a way that doesn’t require us to trust any single third parties.

We say the system is “decentralized”, as a shorthand for this concept.

(As an aside, I explained Bitcoin from first principles in this post on how the counter-intuitive genius of Bitcoin is that it works by going slow! For those who want to go even deeper, I share a way to think about the confusing “Unspent Transaction Output” concept in Bitcoin through an analogy of land.)

This is why Bitcoin is often positioned as being a decentralized equivalent to the centralized banking system:

decent1

Bitcoin allows us to agree who owns what without having to know each other or trust anybody else. This is the opposite of the traditional system where everybody has to trust their bank

Bitcoin-as-envisaged isn’t what we have

But there’s a problem: Bitcoin-as-envisaged isn’t what we have today. Phenomena such as mining centralization and the use of SPV Wallets mean that Bitcoin isn’t completely decentralized. It’s not currently a problem but one can already see its effects. For example, some miners refuse to mine certain types of transactions. The effect on average confirmation time for these transaction types might be marginal but it exists, nevertheless.

So Bitcoin-today is somewhere in between. It’s not 100% decentralised yet nor is it centralized.

decent2

Bitcoin today is neither fully decentralized nor is it centralised

So it seems reasonable to consider that centralization may actually be a continuum rather than an either/or phenomenon:

decent3

Are centralization and decentralization actually two ends of a continuum?

This way of thinking can be helpful because it allows us to think about other innovations in this space, such as Smart Property.

Smart Property

I’ve written in the past about a decentralized securities systems being built “hidden in plain sight”. The key idea here is that you can use blockchain platforms (like colored coins or counterparty, etc) to track the ownership and transfer of real-world assets. What distinguishes these platforms from Bitcoin itself is that they have to bridge to the real world: the asset could be a bond with a corporate issuer, being kept safe by a custodian bank, for example.  So there are several real-world entities on whom you depend.

I’ve written about how smart property allows these two roles to be merged (the issuing company could do both) but somebody has to do it – let’s just call them issuers.

So this system has points of centralization (the issuers) and points of decentralization (the ownership tracking and exchange). So perhaps it sits somewhere here on the continuum:

decent4

Perhaps there is value in different “degrees” of decentralization for different business problems

You can have more than one type of decentralization in a single service

But it’s actually more interesting than that. Because not only do smart property systems sit somewhere on the decentralization continuum, the key point is that different parts of the systems sit in different places:

  • the ledger, exchange and transfer system use the underlying Bitcoin consensus system – so they’re all pretty decentralized. No need to depend on any trusted third parties.
  • But you do, of course, have to trust the issuer.  That part of the proposition is centralised

So the important thing about smart property systems is that the all-or-nothing “trust bundle” is unbundled: you need to trust a specific issuer but the ledger, exchange and transfer functions are decentralized in their operation.

The unubundling of trust

And I think that’s what gives decentralised consensus systems some of their power: you can now break down products and services into their constituent elements of trust and implement each one with the most appropriate degree of centralization. For smart property, perhaps the picture looks something like this:

decent5

Different degrees of decentralization can exist within the same service: trust is being unbundled

So what?

Of course, none of this tells us whether smart property or cryptofinance is a good idea. But it is a way to think about whether a particular service is doing anything particularly novel.   Think about it the other way: if somebody proposes a cryptocurrency business idea that doesn’t meaningfully unbundle any trust in an existing service, is it actually doing anything valuable?  Likewise, take any real-world centralised service and ask yourself: what are all the things I need to trust for this to work? Which components have to be centralised? Which could be decentralised? Does that lead to lower risk? Lower cost? More opportunities for competition? Reduced friction for consumers? If the answer is “yes” to those questions then you could have an interesting proposition on your hands.

Unbundling trust in payments

A similar analysis works for systems like Ripple. Ripple’s architecture is more distributed than the traditional payments systems but less so than Bitcoin (at least as envisaged) so perhaps we may place it somewhere like this on the scale:

decent6

Ripple is another example of a “trust unbundling”

But, just like in the Smart Property example above, in the Ripple system there is a “trust unbundling” going on: the ledger is fairly decentralized in its operation whilst you necessarily need to trust a specific gateway.  So it actually looks like this:

 decent7

Different degrees of decentralization can exist within the same service: trust is being unbundled

To see why this is important, recall how current payment systems work. I wrote a simple explanation of it here. As the article shows, you have to trust a lot of moving actors and the point is that you have to take this as a bundle… it’s all or nothing. You trust all those parts of the system or you can’t achieve your objective.  With a Ripple-like system, you only trust the minimal set of actors you have to – namely, the banks who issued liabilities.  Everything else can be decentralised to some degree.

Unbundling trust in contract execution

One last example: a similar argument applies to financial contracts. Projects like Ethereum (and Counterparty!) are exploring the decentralized modeling and execution of law. Gavin Andresen has written about how something similar could be achieved on the base Bitcoin platform.

You can think of this in terms of “trust unbundling” too: the decentralized platform ensures the integrity of contract execution and you can use n-of-m oracles to provide reliable external data. You only trust who you have to, to the minimal degree possible.

Using “trust unbundling” to turn bad ideas into good ideas..?

So now we can put this model to the test. Does it help us spot the silly ideas? Even better, does it help us turn the silly ideas into good ideas?  [UPDATE 2014-11-15 this section was heavily reworked)

Antonis Polemitis commented on an earlier version of this article:

Here’s what I think he means:

A better airline miles system?

As Antonis points out, airline miles systems are highly centralised: the airline is the issuer, redeemer, owner of the ledger, setter of the rules and controls everything else too.

So imagine an airline were to announce that their new airmiles programme was to be based on a fork of Bitcoin. Perhaps they would create their own Blockchain, issue the miles on top, secure it themselves and distribute wallets to all their customers. Brilliant…  an airline miles programme with all the benefits of Bitcoin!

Really? From a consumer perspective, surely this system would be indistinguishable from a traditional system and what is the argument that says it would be better in any meaningful way?

But take a step back and think about airline miles again and think about the trust bundle. Which parts of the system require you to trust the airline?  Issuance and redemption of the miles, for sure.  And setting of the scheme rules.  But storage, exchange and trade doesn’t need to be done by them.

And perhaps there’s a cost saving for airlines if they offload that work to a decentralised network and a benefit for customers if it gives them additional utility – perhaps new ways of swapping miles between competing programmes to accumulate enough points to book a flight?  Some very interesting possibilities emerge if multiple airlines base their systems on the same platform or if third parties can build new services on top of a platform like this.

Suddenly you might have something interesting: an interoperable, multi-provider airline miles storage, transfer and redemption platform. Now it could be a terrible idea – these schemes only work because most miles are never redeemed, after all! But the thought process is important: who are users expected to trust to use your service?  And what are they trusting them for?  What if a component was decentralised? What new possibilities would that enable? What risk could it mitigate?

Now the real world is more complicated than this. But the key insight remains:

  • if your cryptocurrency idea requires users to trust only you, you’re missing the point
  • but if there’s something in the value proposition that can be usefully decentralized or shared with others, you could be on to something

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

 

A decentralized securities trading and settlement system is being built hidden in plain sight

Colored coins, chromawallet, coinprism, NXT Asset Exchange, Mastercoin, Counterparty… tens of projects are working on asset tracking, transfer and exchange systems. What are they doing? Will it work?

I wrote a piece last year explaining how today’s securities trading and settlement systems work. The full picture of participants is pretty complex:

Figure 8 csd

There are surprisingly many parties involved in the safekeeping and exchange of securities. What would the picture look like in a “decentralized world”?

At core, I think the system is all about assuring “performance”. That is… it’s all about making sure that people actually deliver on the promises they make when they enter into a trade

Recent controversies might make this seem hopelessly naïve – and they show that ensuring fairness in exchange is important – but assuring performance is the core of the aspiration.

And to deliver on this aspiration, today’s system is based on a closed, centralized model. I talked about it here and also argued  Mt.Gox model was even more centralized than the mainstream system.

We’re now seeing serious projects work on this problem. Perhaps revisiting the fundamentals will help us predict which of these projects will prevail?

Why do we have exchanges in the mainstream world?  There are lots of valid answers (liquidity, fairness, …) but none of this matters if you can’t be sure a trade you make will be settled. After all, what’s the point of agreeing a trade with somebody if they can just change their mind afterwards if it suits them?

In the mainstream world today, the general model for a stock exchange is one where it has members, who are the only entities allowed to trade on that exchange. These members are subject to strict rules. For example, the London Stock Exchange’s rule book has over 100 pages: http://www.londonstockexchange.com/traders-and-brokers/rules-regulations/rules-lse.pdf

Rule G5000 sums captures the critical function of the exchange for me:

G5000

“Obligation to settle: A member firm shall ensure that every on Exchange trade effected by it is duly settled.” Obvious, perhaps… but it needs to be said!

So the exchange helps ensure an orderly market by vetting and monitoring its members. This gives participants confidence: they don’t need to worry about who is on the other side of their trade. They know the trade they agree to will get settled. But other exchanges employ different models:

  • Prefund: Mt. Gox asked everybody to deposit their Bitcoins or fiat with them before they could trade. It guaranteed that trades executed on Gox would settle. Unfortunately, it only guaranteed they would settle on the books of Mt.Gox. As many people discovered to their cost, a settled trade on Gox was not the same as cash the bank or Bitcoins in their wallet
  • Escrow: The model I outlined in my piece earlier this year was essentially an escrow scheme. You place your Bitcoins beyond reach and they are either delivered back to you when your bid/offer expires or are delivered to the buyer. The trick here is in choosing the escrow “agent” (or agents…) carefully.
  • Clearing: This is how the The London Stock Exchange does it. In certain situations, members don’t even need to own the securities they’re selling at the time they trade them; they just need to make sure they deliver them as promised on the day of settlement. This model works because there is a closed group of trusted and well-known entities. However, there is clearly a risk: what happens if one of the participants goes bust between trade and settlement? That’s what a clearing house is there to solve, amongst other things. It keeps a close eye on its members, requires them to contribute to a “default fund” and steps in to make the other members whole if one of them fails.

Now, when we look at some of the most vibrant projects in the Bitcoin and cryptocurrency world, we see something interesting: a large number of them are working on representing non-crypto assets – such as securities – on the blockchain – They’re building out the vision of a decentralized general-purpose asset ledger.

There are two concepts we need to understand:

  • A token – something that represents an asset. Perhaps 100 shares of IBM Common Stock or ownership of a particular car.
  • An issuer – somebody that makes a promise to confer the rights and benefits associated with that asset to whomever holds it at any given point.

A concrete example: imagine I owned 10000 IBM shares (I wish…). I could issue them onto one of these platforms and publish the definition so others could see it and could see it was from me. I would, in effect, be making a promise:

“I will convey whatever benefits I enjoy through my ownership of these shares to whomever holds the token”.

So if I receive a dividend cheque, I pay it to the holder of the token. If you trust me to be good for this promise, you might be willing to purchase the token from me for $2m or so… the price of the IBM shares… owning the token would be just as good as owning the shares… and you could store it in your Bitcoin wallet and not have to deal with your broker any more!

Now, it is unlikely that you’d trust such a promise from me. But if was made by a major custodian bank you might. But note: you do have to trust the issuer.

So why bother? Why bother going to the trouble of building a decentralized asset ledger if you have to trust somebody at the end of the process?

For me, the answer is that this approach might allow increased competition between issuers. Furthermore, moving disparate asset registers (custody records, vehicle registration databases, etc) onto a common architecture might enable innovations we haven’t yet considered.   It’s too early to tell so we can all be grateful to the pioneers who are experimenting so we don’t have to.

I think there are three broad camps:

  • Coloring Bitcoins. Projects such as chromawallet and coinprism are working on systems to “tag” Bitcoins so that they can be tracked across transactions
  • New Protocols Running Over Bitcoin. mastercoin and counterparty piggy-back on Bitcoin’s peer-to-peer network, double-spend protection and consensus system but their tokens are essentially independent of Bitcoins. A counterparty token is not simply a “tagged” Bitcoin.
  • Entirely Separate Protocols. NXT and ethereum fit into this camp.

I have no particular insight into the structure of any of these projects so let’s assume they’re all run by capable, honest people and further assume that we’ll see a future where assets of all types, including securities, will be represented on a blockchain-like decentralized platform.

Then what? Presumably people will want to buy and sell…. To exchange.

And that’s where things get interesting… because we have to solve the performance problem.   We’re now in a decentralized, pseudonymous world… how do we ensure somebody who offers to buy an asset for a given price actually goes through with it and pays up?

What is the crypto-ledger rule G5000?

Is it possible to build a decentralized exchange on any of these platforms that has the strong performance guarantees we need? Can we build a decentralized exchange where a matched bid and offer inevitably lead to a settled trade?

It we look at our three models from previously, “clearing” isn’t going to work (it is, by definition, centralized and reliant on trusted identities). “Prefunding” is also problematic – what happens if the entity you sent your assets to disappears? So it looks like “escrow” is the only game in town.

Now, part of the solution already exists: we can construct “atomic” asset transfers using the Bitcoin protocol today. So I will assume exchanging payment and asset in a single transaction (“Delivery versus payment”) is achievable today on any of the platforms discussed above. But we need to get to a point where creating a valid transaction like this is inevitable once a bid and offer are matched.

Here’s where I think the state of the art is with the three approaches and it’s surprisingly different:

Coloring Bitcoins. The systems I’ve looked at don’t route bids/offers over the Bitcoin system so any matching will be done external to the platform. So it seems to me that “decentralized exchanges” on this model will have to require those posting bids or offers to demonstrate that they have placed the corresponding colored coins/Bitcoins in escrow with one or more acceptable third parties. There’s nothing that will do this automatically. So, it’s worth watchin firms like Xapo in the US and Elliptic in the UK. Professionally-run Bitcoin “cold storage vaults” such as these feel like “proto custodian banks” that could perform this function. The question is: can they devise a service that is sufficiently decentralized yet which still allows them to earn an income?

New Protocols Running Over Bitcoin. My understanding of these systems is that they embed bids/offers in the blockchain and have a protocol definition that means matches can be determined unambiguously. Furthermore, the act of making a bid or offer locks the associated assets until the trade is resolved or a bid/offer expires… automatic escrow, if you like. Assuming I am right, then this does appear to offer the “inevitability” promise that I think is so important. But it is at the expense of polluting the blockchain with bids/offers. It seems inelegant to me that one would store transient data (time-limited bids/offers) in such a permanent form of storage. But perhaps there’s no other way?

Entirely Separate Protocols. My working assumption is that NXT, too, works on the basis of bids/offers encumbering the associated assets until the outcome of the trade is resolved.  With Ethereum, the answer to every question is, of course, “it’s Turing Complete so of course you can do it” but I need to dig a little deeper to be sure….

 

Where is this going?

I think we’re going to see a market test: the colored coin approach is, in many ways, the most elegant as it uses the blockchain solely for storing/transferring the asset.   It means a range of exchange types can be trialled (escrow, pre-funding, reputation-based?)… but none of them will deliver full “inevitability” of settlement.  Perhaps consumers will care. Perhaps they won’t.

Projects like mastercoin and counterparty look able to deliver on the “inevitability” promise but will it be at the cost of blockchain bloat?

It will be an interesting few months ahead.

 

A final thought… What if we simply don’t worry about it and price it instead?!

The other approach is completely radical… instead of trying to force performance, why not model it as an option? We can think of somebody who posts a bid/offer but who then reneges as exercising an option to renege. This option clearly has value – if they would lose money by completing the trade as agreed, the option payoff is at least as much as they stood to lose! So is it possible to model the value of the option to renege and force participants to pay the option value up-front in order to post a bid/offer?

Unanswered questions: to whom would the price be paid? Is there any precedent for modeling the “option to renege” in this way? What would be the liquidity implications?

Conclusion

I said at the start of this piece that a new financial infrastructure is being built “hidden in plain sight”. For the reasons outlined above, I think the “exchange” aspect of this infrastructure still has a long way to go but we’re about to witness a fascinating experiment.

Bitcoin and Bankers: Reflections on a panel discussion

Look beyond currency to see the true potential for cryptocurrencies… but don’t forget to apply the lessons to today’s problems too…

I participated in the Bitcoin panel at Finextra’s Future Money conference at Canary Wharf’s Level 39 in London this week. Zilvinas Bareisis of Celent has a succinct write-up of the event here. It was live-scribed by the amazing Mela Atanassova:

Bitcoin

The Finextra team assembled the “who’s who” of the London FinTech scene and it pays to be prepared when speaking in front of that sort of audience… so I gave some thought to my talking points beforehand.

When I reflected on the event afterwards, it struck me that our moderator, Liz Lumley, had expertly led us through most of the key “what Bankers need to know” questions: In what way is Bitcoin different to what went before? Why do cryptocurrencies cause such intense discussion? Why do sensible people get so excited by this stuff? Where might it be going?

So in this blogpost I’ve combined my talking points with observations made by my co-panellists: Stan Stalnaker, Ali Farid Khwaja and Nadav Rosenberg.

How do you bring a diverse audience “up to speed” on Bitcoin?

Elizabeth Lumley kicked off the panel by asking who in the audience had a Bitcoin wallet. Over half of the hands went up. Oh dear… this was not your typical audience. What could we tell these people that they didn’t already know?

Luckily, we had been preceded by a keynote by Allessandro Hatami of Lloyds Banking Group. He’s a very smart guy and he gave a thought-provoking presentation. But I noticed something interesting: although he only mentioned Bitcoin in passing, he referred to it in the same context as Amazon Coins. Now, I’m sure he understands the differences but it highlighted that it’s very easy to lead audiences into “category errors” if we’re not careful.

Luckily, we had planned for this in advance. So I spent a few minutes outlining what I think is the “irreducible core” – or fundamental difference – of cryptocurrencies relative to everything that went before, using my “how I explain Bitcoin to new audiences” piece as the structure.

In short:

  • Bitcoin is audacious: until cryptocurrencies came along, humanity had no ability to transmit value at a distance without the permission and support of a third party. Bitcoin taught us how to do it.
  • Blockchain technology could be as important as the web: if we think of the web as the world’s first “internet-scale open platform for information exchange”, we can think of the blockchain as the world’s first “internet-scale open platform for value-exchange”. And the openness is the key.
  • The implications go beyond payments: think “economy of things” and “smart contracts”

In other words, if you’re thinking Bitcoin means “funny internet money”, you’re missing the point.

OK – it could be a cool piece of computer science. But why are so many serious people talking about it so seriously?

Some very smart, very sensible people have concluded that the “web analogy” is plausible and are investing and working on that basis. Other people have been transfixed by the elegance of the underlying consensus algorithm. So it’s not surprising that Bitcoin has unleashed a storm of commentary.

But I think there’s also another reason. I think that Bitcoin has made large numbers of intelligent, thoughtful people realize that they didn’t understand the things they thought they understood. And they are rather enjoying the intellectual rabbit-hole of discovery it has sent them down as they try to “re-learn” things they thought they already knew… This is certainly the case for me. It makes us think deeply about questions like:

The eye-opener for me was what happened when I published my piece on how payment systems work. I wrote it for Bitcoin users who didn’t know much about the banking system. What surprised me was who read it. It was being linked to from banks’ own internal training sites. The answers to these questions are not obvious and Bitcoin has inspired many of us to really think about them.

And I believe this is a big reason why so many people are talking about cryptocurrencies: they force us to clarify our own thoughts about things we thought we already knew.

OK – so cryptocurrencies are important and have potential. But give me just one good example of how it’s going to replace what we already have

I was challenged by a banker in the audience who had clearly heard the cryptocurrency story several times before and was growing tired of all the hype. Sure – it’s clever. Sure – it lets us do things we couldn’t do before. But so what? What real-world problem does it actually solve?

I answered this in three parts.

First, I pointed out how there is a short-term opportunity to take huge cost out of International Remittances. Not glamorous but a clear area where the technology could make a difference to the world.

Second, I argued Bitcoin helps us think about value: what makes today’s financial institutions valuable? Consider Payment Cards. If Bitcoin allows you to pay anybody else near-instantly for near-zero cost, doesn’t this mean Visa and Mastercard will soon be dead? My answer was no. If you believe all they do is payments then Bitcoin is a mortal threat… but that isn’t why they’re valuable. These networks are valuable to us because they promise universal acceptance – they minimize “acceptance anxiety”* no matter where we are in the world. And they have sophisticated rule-books: disputes and chargebacks give consumers and merchants certainty about what will happen when things go wrong. These things are valuable.

Third, I argued that – regardless of whether cryptocurrencies gain widespread adoption – they are already influencing today’s mainstream banking debates. Companies like XBTerminal have shown us how to route Bitcoin push-payment transactions via the terminal, to overcome the problem of mobile devices with no data connection. Peter Keenan, the Chief Executive of Zapp, was at the event and I pointed out how this approach could solve the problem his service will face when customers try to use it in underground shopping malls…

* An aside on “acceptance anxiety”: this is what I call the fear that your payment instrument won’t work when you try to use it. My prediction is that any retail payment solution has to induce less acceptance anxiety than existing methods if consumers are going to adopt it

By way of example, here’s my attempt at using a Bitcoin ATM in Shoreditch… my colleague’s smartphone wallet wasn’t working so I tried my laptop. This is not quite the seamless consumer experience we aspire to 🙂  (not yet…)

Richard Bitcoin ATM.photo

 

How are Banks supposed to formulate strategy when faced with a bewildering landcape of altcoins, sidechains, treechains and who knows what else?

Answer: by keeping laser-focussed on the principles – and ignoring everything else.

This is why I am so maniacal about hammering home phrases like:

  • “Value transfer at a distance with no third party”
  • “Internet-scale open platform for value exchange”
  • “Solving the problem of coming to consensus with people you don’t know, don’t trust and where many of whom are trying to steal your money”

We have to keep focused on these principles because the reality is that the underlying technical details are constantly changing. It may not be obvious to outsiders but it’s important to realize that the cryptocurrency phenomenon is an experiment. Fire up a copy of Bitcoin Core and look at the “about” dialog. Here’s mine:

BitcoinCore

“This is experimental software”

This point is important: the Bitcoin we see today is not the Bitcoin we will be running in two years’ time. Many of today’s supposed problems (transaction throughput limitations, slow confirmation of transactions, …) will have been addressed through sidechains, treechains or solutions that haven’t even been invented yet.

So the only way to formulate strategy today is to keep focused on the principles and to ignore those details that are purely transient.

Ask yourself: what happens if our customers can send money instantly and for free? What happens if push-payments become universal? What happens if we can settle securities transactions, with finality, without needing clearing houses, custodians and CSDs? …

 

But banks should also bear in mind that widespread adoption could take longer than we expect:

Ask a technologist when the web went “mainstream” and they’ll probably say 1994 or 1995. But this answer is wrong by a decade! Facebook wasn’t even founded until 2004. Twitter? 2006. But even this misses the point. The transformational impact of the web (the internet-scale open platform for information exchange, remember…) was that it enabled the mobile and cloud revolutions. Yet Amazon Web Services didn’t launch until 2006 and the first iPhone wasn’t released until 2007.

And on top of this, the reality is that most mainstream users of cryptocurrency technology won’t even know they’re using it.

The only way to stay sane is to focus on the principles.

What about trust?

After the panel, I was approached by a member of the audience who was astonished that we hadn’t touched on the topic of trust. Fair point. Finextra’s Matt White was nearby and grabbed me for a two-minute follow-up:

 

My thanks to Elizabeth Lumley, Nick Hastings and the Finextra team for organizing such an excellent event.

 

[Updated 2014-05-05 with clearer Live-Scribe image]