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:


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”):


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?


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:


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…


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:


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:


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…


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:


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”:


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.


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:


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

So what?

Let’s look at the shared ledger again:


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.


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.


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.


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):


… 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]


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]

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:


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:


“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]

A simple explanation of how money moves around the banking system

Twitter went mad last week because somebody had transferred almost $150m in a single Bitcoin transaction. This tweet was typical:

There was much comment about how expensive or difficult this would have been in the regular banking system – and this could well be true.  But it also highlighted another point: in my expecience, almost nobody actually understands how payment systems work.  That is: if you “wire” funds to a supplier or “make a payment” to a friend, how does the money get from your account to theirs? 

In this article, I hope to change this situation by giving a very simple, but hopefully not oversimplified, survey of the landscape.

First, let’s establish some common ground

Perhaps the most important thing we need to realise about bank deposits is that they are liabilities. When you pay money into a bank, you don’t really have a deposit. There isn’t a pot of money sitting somewhere with your name on it. Instead, you have lent that money to the bank. They owe it to you.  It becomes one of their liabilities. That’s why we say our accounts are in credit: we have extended credit to the bank.  Similarly, if you are overdrawn and owe money to the bank, that becomes your liability and their asset.  To understand what is going on when money moves around, it’s important to realise that every account balance can be seen in these two ways.

Paying somebody with an account at the same bank

Let’s start with the easy example. Imagine you’re Alice and you bank with, say, Barclays. You owe £10 to a friend, Bob, who also uses Barclays. Paying Bob is easy: you tell the bank what you want to do, they debit the funds from your account and credit £10 to your friend’s account.  It’s all done electronically on Barclays’ core banking system and it’s all rather simple: no money enters or leaves the bank; it’s just an update to their accounting system.  They owe you £10 less and owe Bob £10 more. It all balances out and  it’s all done inside the bank: we can say that the transaction is “settled” on the books of your bank.  We can represent this graphically below: the only parties involved are you, Bob and Barclays.  (The same analysis, of course, works if you’re a Euro customer of Deutsche Bank or a Dollar customer of Citi, etc)

Single Bank Settlement

But what happens if you need to pay somebody at a different bank?

This is where it get more interesting.  Imagine you need to pay Charlie, who banks with HSBC. Now we have a problem: it’s easy for Barclays to reduce your balance by £10 but how do they persuade HSBC to increase Charlie’s balance by £10?  Why would HSBC be interested in agreeing to owe Charlie more money than they did before?  They’re not a charity! The answer, of course, is that if we want HSBC to owe Charlie a little more, they need to owe somebody else a little less.

Who should this “somebody else” be?  It can’t be Alice: Alice doesn’t have a relationship with HSBC, remember.  By a process of elimination, the only other party around is Barclays. And here is the first “a ha” moment…  what if HSBC held a bank account with Barclays and Barclays held a bank account with HSBC? They could hold balances with each other and adjust them to make everything work out…

Here’s what you could do:

  • Barclays could reduce Alice’s balance by £10
  • Barclays could then add £10 to the account HSBC holds with Barclays
  • Barclays could then send a message to HSBC telling them that they had increased their balance by £10 and would like them, in turn, to increase Charlie’s balance by £10
  • HSBC would receive the message and, safe in the knowledge they had an extra £10 on deposit with Barclays, could increase Charlie’s balance.

It all balances out for Alice and Charlie… Alice has £10 less and Charlie has £10 more.

And it all balances out for Barclays and HSBC.  Previously, Barclays owed £10 to Alice, now it owes £10 to HSBC. Previously, HSBC was flat, now it owes £10 to Charlie and is owed £10 by Barclays.

This model of payment processing (and its more complicated forms) is known as correspondent banking. Graphically, it might look like the diagram below.  This builds on the previous diagram and adds the second commercial bank and highlights that the existence of a correspondent banking arrangement allows them to facilitate payments between their respective customers.

Correspondent Banking

This works pretty well, but it has some problems:

  • Most obviously, it only works if the two banks have a direct relationship with each other. If they don’t, you either can’t make the payment or need to route it through a third (or fourth!) bank until you can complete a path from A to B. This clearly drives up cost and complexity. (Some commentators restrict the use of the term “correspondent banking” to this scenario or scenarios that involve difference currencies but I think it helpful to use the term even for the simpler case)
  • More worryingly, it is also risky. Look at the situation from HSBC’s perspective.  As a result of this payment, their exposure to Barclays has just increased.  In our example, it is only by £10.  But imagine it was £150m and the correspondent wasn’t Barclays but was a smaller, perhaps riskier outfit: HSBC would have a big problem on its hands if that bank went bust.  One way round this is to alter the model slightly: rather than Barclays crediting HSBC’s account, Barclays could ask HSBC to debit the account it maintains for Barclays. That way, large inter-bank balances might not build up. However, there are other issues with that approach and, either way, the interconnectedness inherent in this model is a very real problem.

We’ll work through some of these issues in the following sections.

[Note: this isn’t *actually* what happens today because the systems below are used instead but I think it’s helpful to set up the story this way so we can build up an intuition for what’s going on]

Hang on… why are you making this so complicated? Can’t you just say “SWIFT” and be done with it?

It is common when discussing payment systems to have somebody wave their hands, shout “SWIFT” and believe they’ve settled the debate.  To me, this just highlights that they probably don’t know what they’re talking about 🙂

The SWIFT network exists to allow banks securely to exchange electronic messages with each other. One of the message types supported by the SWIFT network is MT103. The MT103 message enables one bank to instruct another bank to credit the account of one of their customers, debiting the account held by the sending institution with the receiving bank to balance everything out.  You could imagine an MT103 being used to implement the scenario I discussed in the previous section.

So, the effect of a SWIFT MT103 is to “send” money between the two banks but it’s critically important to realise what is going on under the covers: the SWIFT message is merely the instruction: the movement of funds is done by debiting and crediting several accounts at each institution and relies on banks maintaining accounts with each other (either directly or through intermediary banks).  Simply waving one’s hands and shouting “SWIFT” serves to mask this complexity and so impedes understanding.

OK… I get it. But what about ACH and EURO1 and Faster Payments and BACS and CHAPS and FedWire and Target2 and and and????

Slow down…..  Let’s recap first.

We’ve shown that transferring money between two account holders at the same bank is trivial.

We’ve also shown how you can send money between account holders of different banks through a really clever trick: arrange for the banks to hold accounts with each other.

We’ve also discussed how electronic messaging networks like SWIFT can be used to manage the flow of information between banks to make sure these transfers occur quickly, reliably and at modest cost.

But we still have further to go… because there are some big problems: counterparty risk, liquidity and cost.

The two we’ll tackle first are liquidity and cost

We need to address the liquidity and cost problem

First, we need to acknowledge that SWIFT is not cheap. If Barclays had to send a SWIFT message to HSBC every time you wanted to pay £10 to Charlie, you would soon notice some hefty charges on your statement.  But, worse, there’s a much bigger problem: liquidity.

Think about how much money Barclays would need to have tied up at all its correspondent banks every day if the system I outlined above were used in practice. They would need to maintain sizeable balances at all the other banks just in case one of their customers wanted to send money to a recipient at HSBC or Lloyds or Co-op or wherever.  This is cash that could be invested or lent or otherwise put to work.

But there’s a really nice insight we can make:  on balance, it’s probably just as likely that a Barclays customer will be sending money to an HSBC customer as it is that an HSBC customer will be sending money to a Barclays customer on any given day.

So what if we kept track of all the various payments during the day and only settled the balance?

If you adopted this approach, each bank could get away with holding a whole lot less cash on deposit at all its correspondents and they could put their money to work more effectively, driving down their costs and (hopefully) passing on some of it to you.  This thought process motivated the creation of deferred net settlement systems.  In the UK, BACS is such a system and equivalents exist all over the world.  In these systems, messages are not exchanged over SWIFT.  Instead, messages (or files) are sent to a central “clearing” system (such as BACS), which keeps track of all the payments, and then, on some schedule, calculates the net amount owed by each bank to each other.  They then settle amongst themselves (perhaps by transferring money to/from the accounts they hold with each other) or by using the RTGS system described below.

This dramatically cuts down on cost and liquidity demands and adds an extra box to our picture:

Deferred Net Settlement

It’s worth noting that we can also describe the credit card schemes and even PayPal as Deferred Net Settlement systems: they are all characterised by a process of internal aggregation of transactions, with only the net amounts being settled between the major banks.

But this approach also introduces a potentially worse problem: you have lost settlement finality. You might issue your payment instruction in the morning but the receiving bank doesn’t receive the (net) funds until later.  The receiving bank therefore has to wait until they receive the (net) settlement, just in case the sending bank goes bust in the interim: it would be imprudent to release funds to the receiving customer before then.  This introduces a delay.

The alternative would be to take the risk but reverse the transaction in the event of a problem – but then the settlement couldn’t in any way  be considered “final” and so the recipient couldn’t rely on the funds until later in any case.

Can we achieve both Settlement Finality and Zero Counterparty Risk?

This is where the final piece of the jigsaw fits in.    None of the approaches we’ve outlined so far are really acceptable for situations when you need to be absolutely sure the payment will be made quickly and can’t be reversed, even if the sending bank subsequently goes bust.  You really, really need this assurance, for example, if you’re going to build a securities settlement system: nobody is going to release $150m of bonds or shares if there’s a chance the $150m won’t settle or could be reversed!

What is needed is a system like the first one we outlined (Alice pays Bob at the same bank) – because it’s really quick – but which works when more than one bank is involved.  The multilateral bank-bank system outlined above sort-of works but gets really tricky when the amounts involved get big and when there’s the possibility that one or other of them could go bust.

If only the banks could all hold accounts with a bank that cannot itself go bust… some sort of bank that sat in the middle of the system.  We could give it a name.  We could call it a central bank!

And this thought process motivates the idea of a Real-Time Gross Settlement system.

If the major banks in a country all hold accounts with the central bank then they can move money between themselves simply by instructing the central bank to debit one account and credit the other.  And that’s what CHAPS, FedWire and Target 2 exist to do, for the Pound, Dollar and Euro, respectively. They are  systems that allow real-time movements of funds between accounts held by banks at their respective central bank.

  • Real Time – happens instantly.
  • Gross – no netting (otherwise it couldn’t be instant)
  • Settlement – with finality; no reversals

This completes our picture:


I thought this article had something to do with Bitcoin?

Well done for getting this far.  Now we have a question: can we place Bitcoin on this model?

My take is that the Bitcoin network most closely resembles a Real-Time Gross Settlement system. There is no netting, there are (clearly) no correspondent banking relationships and we have settlement, gross, with finality.

But the interesting thing about today’s “traditional” financial landscape is that most retail transactions are not performed over the RTGS. For example, person-to-person electronic payments in the UK go over the Faster Payments system, which settles net several times per day, not instantly.   Why is this?  I would argue it is primarily because FPS is (almost) free, whereas CHAPS payments cost about £25.  Most consumers probably would use an RTGS if it were just as convenient and just as cheap.

So the unanswered question in my mind is: will the Bitcoin payment network end up resembling a traditional RTGS, only handling high-value transfers?  Or will advances in the core network (block size limits, micropayment channels, etc) occur quickly enough to keep up with increasing transaction volumes in order to allow it to remain an affordable system both for large- and low-value payments?

My take is that the jury is still out: I am convinced that Bitcoin will change the world but I’m altogether less convinced that we’ll end up in a world where every Bitcoin transaction is “cleared” over the Blockchain.

[Updated several times on 25 November 2013 to correct minor errors and to add the link to my Finextra video at the end]