What Slack Can Teach Us About Privacy In Enterprise Blockchains

“Channels” in Hyperledger Fabric don’t work the way you think they do…

Corda and Fabric have very different approaches to delivering privacy. In this post, I compare the models, explain why Corda works the way it does and why I think the Fabric privacy model is flawed. It turns out this can have real-world costly business implications.

But first… let’s set up some intuition.

If you’ve ever used the popular messaging tool, Slack, you might recognise this message…

Slack

If you add a new member to a private channel in Slack, you have two choices: share your entire history or start a fresh, empty, channel. This works for interpersonal comms but it turns out it doesn’t work nearly as well for the “trust but verify” world of enterprise blockchains. 

This message reveals a fundamental truth: if you’ve shared lots of information in private with some people – on Slack or in an email thread, perhaps – then you have to be very careful about adding somebody new to that group, especially if you care about controlling what they can and can’t see. Remember that time you added somebody to a long “reply-to” chain, only to realise there was something at the bottom that you really didn’t want them to see?!  Undo! Undo!! Undo!!!

Famously, there’s no “undo” button on a blockchain, so we have to get things right first time.

In this piece I’ll explain how Fabric’s privacy design turns out to be very similar to Slack channels. However, it also turns out that a model that works superbly for Slack doesn’t work as well in the world of enterprise blockchains for some very common use-cases.

But first, some history.

When we began our architectural journey at R3, we examined a large number of platforms. We concluded that none met our needs and we embarked on the project that culminated in Corda, the industry’s only finance-grade enterprise blockchain platform.

One of the platforms we included in that initial evaluation and rejected as unsuitable for the broad range of needs of sophisticated financial institutions was the first version of the Fabric platform.

But that was then… and a lot of time has passed. It’s always valuable to revisit past decisions in the light of new evidence and, since Fabric has just reached an important milestone, now is a good time to look again.

One of the key changes since 2015 is the introduction of something called “channels”, intended to address the severe privacy shortcomings in the initial design. It turns out that Fabric channels are very similar to an idea we had considered and rejected as too limiting at the start of the design process for Corda.

In this post, I explain why we rejected this design for Corda and what I think some of the key problems will prove to be.

As we know, early blockchain designs sprayed data around the network and everybody received and processed every transaction. This is how Bitcoin and Ethereum work and it is, of course, a fundamental part of how they work.   It’s the right design for those public blockchain platforms.

But that design, which is perfect for those platforms, is just not appropriate for most problems in today’s enterprise world. So the first version of Fabric, which broadcast data globally like many other platforms of the time, had to be extensively redesigned.

The new solution adopted by Fabric is called “channels”. The idea is effectively to let you set up many, many “mini blockchains” – each of which is called a “channel”.  So you and I may share a channel. Perhaps Alice, Bob and Charley share another one. And maybe Alice, me and Ivor share another one.  It’s as if there are many little private blockchains where members of a channel can see everything in that channel but nobody else can.

Simple, right? Elegant, right?

Unfortunately, no.

My biggest worry about the design when we first considered – and rejected – it for Corda is that assets will get stranded.

Imagine you issue a bond to an investor in a private channel between you and them. Remember: the whole point is that it’s private so you wouldn’t want anybody else in that channel. Why would you want them to know about your private deal?

And now you have that channel with your investor, you can use it to engage in some other transactions with them too.  Perhaps you use this bilateral channel to manage some records pertaining to some other deal you’re working on together.  Or maybe they’re also a customer of yours and you want to manage a complex order.  There will invariably be lots of different pieces of information in a channel – different deals, trades, records – all being managed together and commingled.  And this will be repeated across all the other bilateral and multilateral channels in which you participate.

And, because of the nature of the programming and consensus model used by Fabric-style blockchains, all information in a channel inevitably gets commingled with all other information in that channel.  There’s no easy way to extract just some pieces, with history and provenance… a channel is an all or nothing proposition. This is intrinsic to how these sorts of blockchains work and is a reason Corda uses a totally different architecture based on individual “states” representing specific shared facts, each of which can evolve independently.

A good way to think about this problem is as if a channel is like a break-out room at a conference… filled with whiteboards and sticky-notes on the wall. If you’re in the room, you can see and understand everything… but if you were to just take one piece of paper out of the room, it would make no sense to anybody else because they’d need the full history of everything that happened in the room and all the other papers to understand it.

Or, rather, I thought that was a good way to think about it until I sent an earlier draft of this article to some colleagues for review and one of them pointed out that this is precisely what happens when you manage private conversations in Slack!

If you set up a private channel in Slack and then try to add somebody else, they get to see everything that went before.  Or… you have to set up a brand new channel where they get no history, no context, no provenance.  It turns out the Slack app even has a perfect error message that describes this issue:

Slack

Slack knows why a channel architecture is problematic for a distributed ledger

So imagine you want to take a bond you’ve bought from the issuer in that channel and sell it to somebody else.  How would you do it?

  • Well…. you can’t invite them into the channel, because then they’d see all your other private information. A non-starter.  It would be like inviting them into your secret breakout room and hoping they didn’t look at things they weren’t supposed to.
  • And you can’t easily just extract the pieces of history needed to prove the history of that bond, because everything is commingled.
  • And you can’t simply tell them you own the bond. Why would they believe you? The whole point of enterprise blockchains is that each party verifies the information it is given. This is what distinguishes enterprise blockchains from databases, after all.
  • I suppose you could ask the issuer to cancel the issuance in your channel and reissue it in the new buyer’s channel.  But now we’re getting a little bit silly. This would be indistinguishable from simply managing the assets on the books of the issuer. It would defeat the point.

This is not just theoretical: it could have real-world impact.

If it is difficult to move assets between channels with provenance, one has to resort to cumbersome workarounds. Workarounds such as introducing “market makers” who sit between channels and maintain liquidity in both. But this has real costs: additional people to trust, additional fees, additional liquidity needs…

How is Corda different?

As I’ve written in other pieces, we spent a TON of time on Corda’s design: the data model, the fundamental conceptual framework and, critically, our solution to the thorny problem of how to assure privacy whilst allowing parties independently to validate chains of custody and other shared data… the essence of what makes a blockchain a blockchain and not just an expensive distributed database!

Our design addresses the problems in this article head on: data is shared at the level of individual deals or agreements or trades or contracts, with only the transactions needed to verify provenance being shared and no more.  On top of this we layer anonymization and other privacy-enhancing techniques. These techniques build on top of each other. The need to prove provenance never goes away but we do our absolute best only to share the data that is needed to satisfy the recipient.

What’s more, we also built Corda to be able to use Intel’s game-changing SGX technology – without any changes to apps and with Corda’s famous developer-friendly programming model.  So I was delighted that we could announce our partnership with Intel earlier this month.

I’m massively optimistic about the potential of blockchain technology to solve real problems in business. Just make sure you fully understand the pros and cons and different tradeoffs of each before making your selection: as always, one size never fits all.

Post-Script

I should stress that I have a boatload of respect for our friends at IBM – and elsewhere. I think channels are a poor architectural solution but I value immensely the collaboration we have via the Hyperledger Project (where we are both premier members) and beyond.  And I look forward to deepening this collaboration further.   There is more that unites projects such as ours than divides us!

And I should also point out that the Fabric team do know about these issues. For example, see this recent Stack Overflow question:

“How do we enforce privacy while providing tracing of provenance using multiple channels in Hyperledger v1.0?”

The answer is: “At the moment there is no straight forward way of providing provenance across two different channels within Hyperledger [Fabric] 1.0”.

And the answer goes on to reference a design document for a fix. That link is to a very long and complex design document. That tells me that the design problem may be pretty fundamental and can’t be fixed easily. But it’s good news that it is being looked at. We all benefit when platforms develop and evolve and I hope to see significant improvements in this area over time.

 

Update

2017-07-20

IBM’s Dan Selman has taken me to task about this post!  He correctly points out that I didn’t say too much about Corda’s design:

This is because I’ve written about it extensively elsewhere but he’s right: I should have linked.  This video from our Developer Relations team gives a pretty good overview:

And the other videos are pretty good too!

What that video doesn’t say (but should!) is the key point: in real-life scenarios, the dependency tree for any given transaction is invariably a very small subset of the overall set of transactions and so this technique (lazy on-demand provision of just the directly-required dependency tree and no more) gives us the optimal balance.  It is enabled by the transaction design, where each transaction specifically specifies which previous state objects (“shared facts”, if you like) are being superseded.   Put another way: we explicitly declare which parts of the shared state are being updated (actually, replaced) and so we know precisely which proof needs to be provided by one party to another.

In the Slack analogy, it would be equivalent to being able to automatically “lift out” just the pieces of a shared conversation that were directly relevant to the new person you wanted to add to the chat, without also showing them parts of the shared conversation that they have no need to see.

A Simple Explanation of Enterprise Blockchains for Cryptocurrency Experts

And why R3’s Open-Source Corda platform is the one to watch…

We’re doing some really interesting engineering at R3 right now… We have Java running in Intel SGX… We’re hacking a JVM to make it deterministic… We’ve proved you can suspend threads of execution to a database and bring them back to life across restarts as if nothing happened… (We even got emojis to display cleanly on multiple different terminals….)

“It’s just so nice to finally see people doing software engineering in this space” (unsolicited comment at a recent conference I attended)

But why are we doing all this work? After all, public blockchains are red hot right now: prices reaching new highs, “Initial Coin Offerings” showing no sign of slowing and new innovations announced daily. Why is a strange firm called R3, which recently raised $107m to complete the build out of our open source Corda platform, heading off in what seems like a different direction? Aren’t we just building over-complicated centralized databases? Or solving a problem that nobody has?

To be honest, I thought the public blockchain community didn’t have much interest in our work… until Joel from our developer relations team visited San Francisco to deliver our Corda technical training. He had been nervous: many cryptocurrency ‘maximalists’ are West-Coast based… and he thought he would be in for a hard time.

Anyway… he needn’t have worried. The audience was the best he’d ever presented Corda to: uniformly respectful, engaged, questioning and inquisitive. And it made me realise: I’ve done a terrible job of explaining what we’re up to and why we’re taking the route we’re are.

What problem do enterprise blockchains solve?

I wrote about this in more depth when we first announced Corda but, in short, the story is simple:

  • In the beginning there was Bitcoin…
  • … and it was a revelation.
  • Not only because, for the first time ever, we had a censorship-resistant, confiscation-proof, scarce, digital bearer asset…
  • … but because the architecture that Satoshi built to give us this amazing gift taught us something we didn’t previously know. It taught us that:
  • It is now possible to build systems that are operated by multiple parties, none of whom fully trust each other, that nevertheless come into and remain in consensus as to the nature and evolution of a set of shared facts.
  • In Bitcoin, the set of shared facts are: how many bitcoins have been mined and what conditions govern how they can be spent?
  • Newer platforms, such as Ethereum, build on these ideas and expand the set of facts over which we’re coming into consensus; in Ethereum’s case: what is the state of a shared world computer?

As we know, Satoshi set a very high bar for Bitcoin. It works when you don’t know who most of the participants are and it lets miners come and go at will without anybody even knowing who they are.  Like I’ve long said, Bitcoin is a work of genius.

But a key point to stress is that those of us building enterprise blockchain platforms aren’t trying to build a better Bitcoin or even build a better Ethereum. (Why bother? They already exist!) Instead, the thing that interests us is the sentence above that I wrote in italics:

It is now possible to build systems that are operated by multiple parties, none of whom fully trust each other, that nevertheless come into and remain in consensus as to the nature and evolution of a set of shared facts.

This is tantalizing… because it suggests we could completely transform the economics and structure of entire industries. Not by introducing a new currency or decentralized governance model (that’s already being built out by the public blockchains, after all).  But by also massively improving the efficiency of what already exists.

If we knew that all parties were in sync, we could accelerate securities settlement, optimize supply chains, liberate assets stranded in one silo for productive use elsewhere and more.  Anywhere where trade is hampered because of inconsistent systems could be in scope for improvement.  In short, we now have at our hands a new approach to solving one of the trickiest problems in transaction processing: the reconciliation problem.

If we could be sure that one firm’s IT systems were in perfect sync with their counterparts’ systems, it is mindblowing to imagine how much error, risk, duplication, complexity and cost could be eliminated… and how many hitherto impossible transactions became feasible.

In other words: quite separate to the well-understood revolution ushered in by the advent of Bitcoin, an entirely different field also got a massive kickstart. Two revolutions for the price of one.

It doesn’t sound as exciting as a new world currency, to be sure. But it could, in its own way, be utterly transformational. And note: the solution I’m talking about is not the same as a distributed database. And it’s not the same as a fully centralized solution. And it’s not another cryptocurrency or public blockchain. It is something new entirely.

In short, there’s a reason why enterprise blockchain firms like ours look, talk and act differently to cryptocurrency firms and communities: we’re building on some of the same technology, but solving different problems. Problems like managing trade finance relationships, confirming trades and issuing and trading Commercial Paper.

But don’t fall into the trap of thinking all enterprise blockchains are the same. Because they’re not. The Corda introductory whitepaper and Corda technical whitepaper go into this in more depth. But I know you’re busy. So let’s look at just three aspects.

Architecture

First, architecture.  We set ourselves the challenge of building an enterprise blockchain that met the needs for the most demanding clients in business: the financial services industry. It’s why it’s the only enterprise blockchain designed to support interoperable business networks: we want ecosystems to be able to transact and to trade. And it’s why we built a platform that could easily talk to existing business applications and which businesses could actually deploy.

That’s why Corda runs on the Java platform, stores its data, immediately queryable, in a relational database and moves data using message queues.  This facilitates integration, keeps operations people happy in big companies and massively simplifies the design.  Mike Hearn has spoken about this at length.  It sounds so simple – so traditional – yet it’s unbelievably valuable. We scratch our heads every day asking ourselves why everybody else in the enterprise blockchain world left this opportunity wide open for Corda to take!

Contrast that with Fabric, part of the Hyperledger Project: written in Go, it uses a gossip network to spray data indiscriminately around the network, with a cumbersome “channels” abstraction bolted on to fix that problem. And rather than default to a SQL database, it offers a strange choice between a key-value store or a NoSQL document database.

JPMorgan’s Ethereum-fork, Quorum, is still a work in progress so it’s hard to comment but it has a talented team behind it. So I’ll just note in passing that the problem that Ethereum solves so well in the public blockchain world is very different to the problem that large institutions have. So it’s not immediately obvious why you’d use the solution to one as the foundation of the solution to the other.

Privacy

Secondly, privacy.  Corda’s design, from day one, was based on an atomic, need-to-know privacy model that enables multiple different business networks and transaction types to co-exist and interoperate at the same time. Truly an interoperable network of networks is being built out.

Fabric’s design is very different. It has had at least two entirely different privacy designs in its short life and the latest, “channels”, suffers from all the same problems as other coarse-grained approaches to privacy: you end up with lots of mini-global-broadcast blockchains that don’t talk to each other and in which assets will get stranded; the opposite of the vision to which we’re building. You might get away with this design in some simple cases but will then come unstuck when you try to extend the solution.

Quorum’s approach is more innovative but I think it still fundamentally suffers from this problem.

Corda is built for the future

Finally, Corda is built for the future. When we designed Corda, we looked at where the broader industry was going and tried to anticipate those trends.  That’s why Corda is designed to work naturally and seamlessly with Intel’s SGX security technology. It’s why you can write your apps in any JVM language and why we chose to write the base platform in Kotlin, one of the most exciting new languages around – a decision which was vindicated when Google made it a first-class language for its Android platform – and it’s why Corda is jam-packed with cool little developer-friendly features that other platforms simply don’t have, such as our support for reactive programming and support for continuations, which we can automatically persist across JVM restarts.

To be fair to IBM, Fabric is also built for the future. If you assume the future runs on a Mainframe 🙂

Learning More about Corda

Corda is currently in public beta, we’ve just shipped our latest milestone release and you can download our one-click live DemoBench tool to get started in no time.

Or if you’d prefer to look at or contribute to the code, head over to our GitHub repo: https://github.com/corda/corda.

The team does its work in public… join the conversation at slack.corda.net!

 

Finally: a note on terminology. In this post I used Blockchain and Distributed Ledger interchangeably.  I tried for a long time to retain engineering purity (“Corda has chains of transactions but it doesn’t batch them into blocks so we probably shouldn’t call it a blockchain!”) But the reality is that the market uses the term Blockchain to describe all distributed ledger technologies, including ours. So I’m not going to fight it any more…!

 

On Distributed Databases and Distributed Ledgers

Why can’t companies wanting to share business logic and data just install a distributed database? What is the essential difference between a distributed database and a distributed ledger?

Last month, I shared the thinking that led to the design of Corda, which we at R3 will be open sourcing on November 30; and Mike Hearn and I were interviewed by Brian and Meher of Epicenter last week. We’ve been delighted by the response and are looking forward to working with those seek to build on Corda, help influence its direction or contribute to its development and maturation;  there’s a lot of work ahead of us!

But one or two observers have asked a really good question. They asked me: “Aren’t you just reimplementing a distributed database?!”

The question is legitimate: if you strip away the key assumptions underpinning systems like Bitcoin and Ethereum, are you actually left with anything? What is actually different between a distributed ledger platform such as Corda and a traditional distributed database?

The answer lies in the definition I gave in my last blogpost and it is utterly crucial since it defines an entire new category of data management system:

“Distributed ledgers – or decentralised databases – are systems that enable parties who don’t fully trust each other to form and maintain consensus about the existence, status and evolution of a set of shared facts”

“Parties who don’t fully trust each other” is at the heart of this. To see why, let’s compare distributed databases and Corda.

Comparing Corda to a distributed database

In a distributed database, we often have multiple nodes that cooperate to maintain a consistent view for their users.   The nodes may cooperate to maintain partitions of the overall dataset or they may cooperate to maintain consistent replicas but the principle is the same:  a group of computers, invariably under the control of a single organisation, cooperate to maintain their state.  These nodes trust each other.   The trust boundary is between the distributed database system as a whole and its users.    Each node in the system trusts the data that it receives from its peers and nodes are trusted to look after the data they have received from their peers.  You can think of the threat model as all the nodes shouting in unison: “it’s us against the world!”

This diagram is a stylised representation of a distributed database:

 distributed-database

In a distributed database, nodes cooperate to maintain a consistent view that they present to the outside world; they cooperate to maintain rigorous access control and they validate information they receive from the outside world.

So it’s no surprise that distributed databases are invariably operated by a single entity: the nodes of the system assume the other nodes are “just as diligent” as them: they freely share information with each other and take information from each other on trust. A distributed database operated by mutually distrusting entities is almost a contradiction in terms.

And, of course, if you have a business problem where you are happy to rely on a central operator to maintain your records – as you sometimes can in finance it should be said – then a distributed database will do just fine: let the central operator run it for you.  But if you need to maintain your own records, in synchrony with your peers, this architecture simply won’t do.

And there are huge numbers of situations where we need to maintain accurate, shared records with our counterparts. Indeed, a vast amount of the cost and inefficiency in today’s financial markets stems from the fact that it has been so difficult to achieve this. Until now.

Corda helps parties collaborate to maintain shared data without fully trusting each other

Corda is designed to allow parties to collaborate with their peers to maintain shared records, without having to trust each other fully. So Corda faces a very different world to a distributed database.

A Corda node can not assume the data it receives from a peer is valid: the peer is probably operated by a completely different entity and even if they know who that entity is, it’s still extremely prudent to verify the information.   Moreover, if a Corda node sends data to another node, it must assume that node might print it all in an advert on the front page of the New York Times.

The trust boundaries – the red curves in the diagram- are drawn in a completely different place!

decentralised-database

In Corda, nodes are operated by different organisations and do NOT trust each other; but the outcome is still a consistent view of data.

To repeat, because this distinction is utterly fundamental:  nodes of a distributed database trust each other and collaborate with each other to present a consistent, secure face to the rest of the world.   By contrast, Corda nodes can not trust each other and so must independently verify data they receive from each other and only share data they are happy to be broadly shared.

And so we call Corda a distributed ledger, to distinguish it from distributed databases. A distributed ledger that is designed painstakingly for the needs of commercial entities.

Put more simply: you simply can’t build the applications we envisage for Corda with traditional database technology.  And that’s what makes this new field so exciting.

Introducing R3 Corda™: A Distributed Ledger Designed for Financial Services

UPDATE: The Corda introductory whitepaper is now available! And this blog post gives more context.

As reported in Bloomberg this morning, I’m delighted to confirm that R3 and our member banks are working on a distributed ledger platform for financial services: Corda™. I explain it on our official R3 blog and reproduce it here.

For the last six months, my team and contributors from our membership have been building a distributed ledger platform prototype from the ground up, specifically designed to manage financial agreements between regulated financial institutions. I am massively excited by the progress our team, led by James Carlyle, our Chief Engineer, and Mike Hearn, our Lead Platform Engineer, are making and I think the time is right to share some details.

Corda: A Distributed Ledger for Recording and Managing Financial Agreements

Corda is a distributed ledger platform designed from the ground up to record, manage and synchronise financial agreements between regulated financial institutions. It is heavily inspired by and captures the benefits of blockchain systems, without the design choices that make blockchains inappropriate for many banking scenarios.

Corda’s key features include:

  • Corda has no unnecessary global sharing of data: only those parties with a legitimate need to know can see the data within an agreement
  • Corda choreographs workflow between firms without a central controller
  • Corda achieves consensus between firms at the level of individual deals, not the level of the system
  • Corda’s design directly enables regulatory and supervisory observer nodes
  • Corda transactions are validated by parties to the transaction rather than a broader pool of unrelated validators
  • Corda supports a variety of consensus mechanisms
  • Corda records an explicit link between human-language legal prose documents and smart contract code
  • Corda is built on industry-standard tools
  • Corda has no native cryptocurrency

Corda’s design is the result of detailed analysis and prototyping with our members and will be open sourced when the code has matured further.

In the remainder of this post, I want to share some insight into our thinking.  Why are we building Corda?  Why have we made some of the design decisions we have?  When will the code be ready for others to examine and build upon? How does this relate to other platforms and projects?

A thought experiment

When I joined R3 from IBM in September 2015, I forced myself to stop and think.  The blockchain bandwagon was running at full speed, I’d just been appointed CTO of a project intended to bring blockchains to finance but there was a nagging worry at the back of my mind…  how could I avoid falling into the trap of believing all the hype?!

I imagined myself sitting in front of the CIO of one of our member banks some time in the future.  I imagined we had naively selected a “blockchain for finance” based on what was popular at the time and widely deployed a range of products and services on top of it. And I imagined we had believed the hype, had suspended our critical faculties and had omitted any engineering.  In this imagined scenario, I now found myself facing an angry CIO, who wanted to know why the system I had built had just failed calamitously. Why on earth did I build it the way I did?!

I concluded that an entirely inappropriate answer to that question would be: “because blockchains were cool in 2015”!  No. That simply won’t do.

The reality is that solutions based on selecting the design first and then trying to apply it to arbitrary problems never work out well.  Every successful project I’ve worked on started with the requirements, not some cool piece of technology, and I was determined to bring that discipline into our work at R3.

Remind me again why a system designed to replace banks is also supposedly their saviour?

And there is a second reason for this caution: the technology and finance industries collectively “decided” some time in early 2015 that “blockchain technology” was somehow the future of financial services.

Indeed, I am one of the most active proponents of precisely that claim. But the reason for blockchain technology’s importance is extremely subtle – and this subtlety is something that most people seem to have missed.

To understand this, we need to look at Bitcoin.

Bitcoin’s architecture, as I have often written, is a marvel.  Its interlocking components are one of those rare examples of something so elegant that they seem obvious in hindsight, yet which required a rare genius to create.

But what is often missed is that the cleverest part of Bitcoin isn’t actually its architecture; I think the cleverest part was to articulate the business problem.  We don’t tend to think of Bitcoin as being the solution to a “business problem” but it can perhaps be thought of as a wonderfully neat solution to the problem of: “how do I create a system where nobody can stop me spending my own money?”   Now, I can’t claim to know the mind of Satoshi and he certainly didn’t write the whitepaper in this way but it triggers a very useful thought-experiment.

In fact, once you write this ‘business problem’ down, the design drops out almost trivially!  (Almost…) You want always to be able to spend your own money? Then you can’t have a central point of control.  It could be shut down by the authorities.  You can’t even have a collection of validators with known identities as they could also be shut down with concerted effort.  Very quickly you realise you need a massively replicated consensus system and, if you don’t want to tie actions to real-world identities, you need something like Proof of Work to make the voting work.  You work the logic through and pretty much the whole design (the blockchain, the need for mining, block rewards, maybe even the UTXO transaction model, etc., etc.) drops out.  Of course, it does push a lot of work onto the users: confiscation of somebody’s bitcoins is easy if you know their private key… but let’s leave that to one side for now.

And this way of looking at it is important because it highlights how Bitcoin’s blockchain can be thought of as the solution to a business problem.    Satoshi Nakamoto didn’t wake up one morning wanting to “apply Blockchain to finance”.  Blockchain was the tool that was invented to solve a real problem.

So we have a conundrum, right?  If that’s the case, then what on earth is the argument that says blockchain has any relevance at all to banking?!

Indeed, last time I checked, banks have the inverse of my Bitcoin problem statement!

What is the defining characteristic of blockchain systems?

So I spent most of October sitting in a dark room (really! This was our first London office… a tiny four-person room in a shared working space in the City of London) questioning some of the most fundamental assumptions about blockchains.  What is it exactly that makes them interesting to banks?

Most people had already made the mental leap that the “bitcoin package” was unacceptable as a take-it-or-leave-it deal: proof of work is unnecessary for private deployments, for example.  But, as I looked around, all I could see was firms who had accepted everything else…  It seemed strange to me that, as an industry, we could tease apart one part of the “blockchain bundle” but then stop there.

I spent several of my earlier, formative years at IBM in a role called “technical sales”.  If you’ve ever bought technology from a large IT vendor, you’ll have met somebody like me.  We’re the people who visit clients with the sales rep and act as the technical expert: we explain how the product works, make sure we’re proposing the right solution to the client and ensure there is no technical barrier to closing the deal.

A lesson I learned very early in that role was: it doesn’t matter how hard you wish or how many client meetings you schedule or how aggressive the sales rep gets, if you can’t show how your solution is going to solve the client’s business problem then the deal almost certainly won’t close.  And those that do are the ones you’ll live to regret…

Fast forward a decade, and as I surveyed the blockchain landscape in October 2015, all I could see was excitable (and vocal!) firms touting solutions that made very little sense to me for the kinds of problems I was trying to solve.  I will confess to many moments of self-doubt:  maybe they were all sane and I was the mad one..?!

But I ploughed on: even if they are right that a “take it or leave it” blockchain design is the saviour of the financial industry, I’ll be doing our members a favour if I could explain why.

So we started picking away at what can perhaps be called the “blockchain bundle”:  the collection of services that blockchains provide to those who use them.

We concluded that a blockchain such as the ones underlying Bitcoin or Ethereum or any of the private variations actually provide at least five interlocking, but distinct, services.  And the right approach is to treat them as a menu from which to select and customise… different combinations, in different flavours, for different business problems.

CONSENSUS

The first, and most important, feature of blockchains – and the thing that is probably genuinely new in terms of scale and scope – is that they create a world where parties to a shared fact know that the fact they see is the same as the fact that other stakeholders see:

“I see what you see… and I know that what I see is what you see”

And, critically:

“I know that you know that I know”! 

And:

“I know that you know that I know that you know…”

And so on…

And it makes this promise across the Internet between mutually untrusting parties.  Sure: consensus systems and replicated state machines have existed for years but consensus systems at Internet scale, between untrusting actors, that work in the face of powerful adversaries? That’s a step forward.

In Bitcoin, the shared facts are things like: “What are all the bitcoin (outputs) that have not yet been spent and what needs to happen for them to be validly spent?”.  And the facts are shared between all full node users.

In Ethereum, the shared fact is the state of an abstract virtual computer.

But notice something interesting: there isn’t some law of nature that says the set of people who have to be in consensus is the whole world.  Bitcoin just happens to work that way because of its unique business problem.   If you don’t have Bitcoin’s business problem then be very wary of those trying to sell you something that looks like a Bitcoin solution.

VALIDITY

The second feature in the “blockchain bundle” is validity. Tightly linked to consensus, this feature is the one that allows us to know whether a given proposed update to the system is valid. It is how we define the rules of the game.  What does a valid “fact” look like in the system?  What does a valid update to that fact look like?

UNIQUENESS

The third feature in the blockchain bundle is its “uniqueness service”.   I can quite easily create two perfectly valid updates to a shared fact but if they conflict with each other then we need everybody who cares about that fact to know which, if either, of those updates we should select as the one we all agree on.  The “anti-double-spend” feature of blockchains gives us precisely this service and it’s hugely important.

IMMUTABILITY

The fourth feature in the “Blockchain Bundle” is often, if misleadingly, termed “immutability”: data, once committed, cannot be changed.

This isn’t quite true: if I have a piece of data then of course I can change it.  What we actually mean is that: once committed, nobody else will accept a transaction from me if it tries to build on a modified version of some data that has already been accepted by other stakeholders.

Blockchains achieve this by having transactions commit to the outputs of previous transactions and have blocks commit to the content of previous blocks.  Each new step can only be valid if it really does build upon an unchangeable body of previous activity.

AUTHENTICATION

The final critical feature in the “Blockchain Bundle” is authentication: every action in the system is almost always associated with a private key; there is no concept of a “master key” or “administrator password” that gives God-like powers.   This is quite different to traditional enterprise systems where these super-user accounts are prevalent and petrifying from a security perspective.

So what is the financial services business problem?

So why did I take us through this analysis?  Because it gets us to the heart of the distributed ledger domain: the thing that is genuinely new is the emergence of platforms, shared across the Internet between mutually distrusting actors, that allow them to reach consensus about the existence and evolution of facts shared between them.

So if that’s what this is all about, then what are the “shared facts” that matter in finance? What business problem would we need to have for any of this work to be of any use at all?

And this is the light bulb moment and the fundamental insight driving the entire Corda project:

The important “shared facts” between financial institutions are financial agreements:

  • Bank A and Bank B agree that Bank A owes 1M USD to Bank B, repayable via RTGS on demand.
  • This is a cash demand deposit
  • Bank A and Bank B agree that they are parties to a Credit Default Swap with the following characteristics
  • This is a derivative contract
  • Bank A and Bank B agree that Bank A is obliged to deliver 1000 units of BigCo Common Stock to Bank B in three days’ time in exchange for a cash payment of 150k USD
  • This is a delivery-versus-payment agreement
  •  … and so on…

The financial industry is pretty much defined by the agreements that exist between its firms and these firms share a common problem:  the agreement is typically recorded by both parties, in different systems and very large amounts of cost are caused by the need to fix things when these different systems end up believing different things. Multiple research firms have postulated that tens of billions of dollars are spent each year on this problem.

In particular, these systems typically communicate by exchanging messages: I send an update to you and just hope you reach the same conclusion about the new state of the agreement that I did.  It’s why we have to spend so much money on reconciliation to check that we did indeed reach the same conclusions and more money again to deal with all the problems we uncover.

Now imagine we had a system for recording and managing financial agreements that was shared across firms, that recorded the agreement consistently and identically, that was visible to the appropriate regulators and which was built on industry-standard tools, with a focus on interoperability and incremental deployment and which didn’t leak confidential information to third parties.  A system where one firm could look at its set of agreements with a counterpart and know for sure that:

“What I see is what you see and we both know that we see the same thing and we both know that this is what has been reported to the regulator”

That’s Corda.

How does Corda choose from the “Blockchain Bundle” Menu?

So now we understand the financial services requirement, we can look again at the “Blockchain Bundle” menu from above and outline the choices we’ve made.

CONSENSUS

A critical piece of the Corda philosophy is that our problem is to ensure that “I know that you see the same details about a shared fact that I see”.

But this does not mean that a third party down the road also needs to see it: our consensus occurs between parties to deals, not between all participants.

VALIDITY

Furthermore, in Corda, the only people who need to be in agreement about a fact are the stakeholders to that fact:  if you and I agree about something that pertains only to us then why should we care what some completely unrelated third party thinks?  And why would we even think of sending them a copy so they could opine on it? So, in Corda, we let users write their validation logic in time-tested industry-standard tools and we define who needs to be in agreement on a transaction’s validity on a contract-by-contract basis.

UNIQUENESS

Just like every other distributed ledger out there, we need to be sure that two valid, but conflicting, transactions cannot both be simultaneously active in the system.  But we also recognise that different scenarios require different tradeoffs. So Corda’s design allows for a range of “uniqueness service” implementations, one of which is a “traditional blockchain”. But it doesn’t need to be and, for our purposes, we also need implementations that make different tradeoffs under Brewer’s CAP theorem: in particular, some financial services use-cases need to prioritise consistency at the expense of availability in the event of a network partition.

IMMUTABILITY AND AUTHENTICATION

Here, Corda’s design departs very little from existing systems: our data structures are immutable and our building block is the exchange of digitally-signed transactions.

So Corda is very traditional in some respects – we directly apply the “authentication”, “immutability” and “uniqueness service” features of blockchains but we depart radically when it comes to the scope of “consensus” (parties to individual deals rather than all participants) and “validation” (the legitimate stakeholders to a deal rather than the whole universe or some arbitrary set of ‘validators’).

How is Corda Different?

Hang on?  Isn’t this the same pitch that every other blockchain firm is making? Not quite.

Notice some of the key things:  firstly, we are not building a blockchain.   Unlike other designs in this space, our starting point is individual agreements between firms (“state objects”, governed by “contract code” and associated “legal prose”).  We reject the notion that all data should be copied to all participants, even if it is encrypted.

Secondly, our focus is on agreements: the need to link to legal prose is considered from the start. We know there will still always be some disputes and we should specify right up front how they will be resolved.

Thirdly, we take into the account the reality of managing financial agreements; we need more than just a consensus system. We need to make it easy to write business logic and integrate with existing code; we need to focus on interoperability. And we need to support the choreography between firms as they build up their agreements.

Different Solutions for Different Problems

But… we should be clear.  We are not viewing Corda as a solution to all problems.  This model is extremely powerful for some use-cases but likely to be less well suited to others.  It’s why we continue to engage extremely deeply with all our partners who are working on complementary platforms in this space; we are not omniscient.  Moreover, there are still many significant design and research questions we have to resolve: there is still a great deal of work to do.

Furthermore, I have been deeply impressed by the quality engineering embodied in the many platforms that have passed through our labs and you will continue to hear about projects we are delivering on platforms other than Corda: different solutions for different problems is our mantra.  Indeed, those who have attended panels or workshops in recent months will have heard me saying this for some time now.

Corda does not seek to compete with or overlap with what other firms are doing:  indeed, we are building it because no other platform out there seeks to solve the problems we’re addressing.  That’s what makes this space so endlessly exciting.

What next?

In the coming weeks and months, you’ll hear more about Corda, about our initial projects and about its design.  We will also be gearing up to release the core platform as open source, possibly as a contribution to other endeavours.  Watch this space.

And… we’re still hiring: there is a great deal of work still to do!

Free advice can be valuable… but only if you take it

If a client tells you your solution doesn’t solve their problem, it may not be the problem that needs to change…

I often argue for the importance of blockchain and distributed ledger technology by using the following chain of logic:

  • Bitcoin’s architecture solved the problem of censorship-resistant digital cash
  • But few, if any, financial firms are interested in censorship-resistant digital cash
  • So why are they looking at this technology?
  • Because some principles underpinning Bitcoin’s architecture – shared ledgers, for example – could be relevant to problems that banks face.

Sure, a blockchain or a replicated shared ledger could indeed be useful to banks. Perhaps it could reduce the need for reconciliation between firms if they all ran off a single ledger, for example. But this says nothing about whether blockchains are the optimal solution to any particular problem in banking.  That still has to be argued, of course.

Recall: the bitcoin architecture was a solution to a very specific, very carefully framed problem – how to transmit value without the risk of censorship. Just because the underlying architecture could be used to solve some pressing problems in banking doesn’t mean it’s the best way to do so. Indeed, although the interlocking aspects of the Bitcoin solution are in some ways quite elegant, there are also some compromises. After all, it is an engineering solution to a set of very specific constraints and so it has to be demonstrated that it’s the right solution when the constraints are different.

Lee Braine, of Barclays Investment Bank CTO Office, made an important contribution to this debate when he spoke at London Blockchain Conference 2015 recently.  The video is now available and I urge anybody working in this space to watch it and to internalise its message.

[vimeo 137190236]

We all too often “talk past each other” in the distributed ledger world and we are quick to assume the other person just “doesn’t get it”.  I can assure you that Lee does get it and it would be a brave startup in this space that chooses to disregard what he said. He’s giving us free advice! Take it!

Like I say, watch the video for yourselves.

I think another way to capture the chain of logic in the video is as follows:

  • Assume the ongoing interest in the application of blockchain technology continues
  • Assume further that some banks identify some compelling business opportunities in deploying a cryptographically-secure shared ledger between themselves.
  • What is the probability that a derivative of Bitcoin or Ethereum or any other current platform will be the best solution to that specific problem?
  • Given that none of them were invented to solve that problem, surely it’s quite low, right?

So we could find ourselves in the situation that bitcoin and blockchain technology have catalysed an orgy of activity, that this activity has identified countless high-quality business problems and yet none of those opportunities are best addressed with the technology that triggered the excitement in the first place!

The theme of this blog is “free advice” and the free advice I’m taking from Lee’s comments includes:

First, we shouldn’t get enamoured by a particular implementation of a technology. Sure: if you have an implementation then you may have bought a place at the table.  But don’t make the mistake of assuming that if the business problem doesn’t fit the technology then it’s the business problem that needs to change!

Secondly, if you’re working in a financial institution, be careful to distinguish between the principles embodied in these technologies. Shared ledgers? Yes. That seems to be at the heart of this domain. Indiscriminate replication? Perhaps. Cryptographically-secured access down to the “row” level? Probably. And so on.

Thirdly, consider the complexity of banks’ existing IT environments. An idealised, “wouldn’t the world be perfect if…” solution is no use to anybody if it requires the whole world to move at once and/or if there is no credible migration path.  This points to a need to listen to the incumbents when they object.  Furthermore, consider the non-functional requirements which are simply a given in this space.

Fourthly, if we assume that today’s current hyperactivity will lead to a new understanding of the possibilities for banks but don’t assume that today’s blockchain platforms (permissioned or permissionless) are the (whole) answer, then surely we’re back in the land of engineering, architecture and hard work? Perhaps this means that the combination of persistence, data models, APIs, consensus, identity and other components that we need won’t all come from one firm.  So a common language, some common vision and an ability to collaborate may become critical. Where is your distinct differentiation? Where would you fit in an overall stack?

Bitcoin and Blockchain: two revolutions for the price of one?

I gave a brief talk on Bitcoin and blockchain technology to an audience of non-specialists at a dinner last week.  It covers many of the themes I’ve explored on this blog before. But the short, fifteen-minute, format forced me to be brief and clear.  This is an edited version of the speech

A £20 note has an obvious, yet extraordinary super-power.   I can hand it to anybody in this room and £20 of value will be transferred instantly, directly, peer-to-peer, person-to-person. Settlement, with finality, in central bank money!  And nobody else need know.  And nobody can stop me.

Super20

Super £20!!   [I really hope there’s no law against posting photos of money…]

But this super-power only works at close distance.  If I want to transfer £20 of value to somebody in a different town or in a different country, I need to trust other people.  Sure: I could put the £20 in an envelope and post it.  But even then I’d have to trust the postal service.

Or I could use a bank.  But I’d be trusting them to be good for the money. And I’d have handed over control: if my name’s on the wrong list, the bank would be obligated to seize my funds. And if you’re on the wrong list, the bank will refuse to transfer the money to you…

“Digital” money is not the same as physical cash.

And the world’s financial plumbing – payments systems, correspondent banking, SWIFT, … – is a direct consequence of this observation: physical cash really is fundamentally different to every other form of money: only physical cash is a bearer instrument. And only physical cash can be transferred without permission – censorship-resistant.

Or so we thought.

Because a curious email to an obscure cryptography mailing list at the end of 2008 said something quite audacious. The email, from the hitherto unknown Satoshi Nakamoto heralded the arrival of Bitcoin and the advent of “purely peer-to-peer electronic cash”.

Super202

“A purely peer-to-peer version of electronic cash”

We all know the story of what happened next.

Except… what many people have missed is that the choice of the word “cash” in that email was absolutely critical and absolutely deliberate. What this email announced was the arrival of a digital bearer asset that is censorship resistant.  Digital cash.  A digital asset that you can hold outright, with no risk of confiscation, and which you can transfer to anybody you choose with no permission from anybody else.

And the funny thing is: the architecture of Bitcoin flows almost trivially (almost…!) from this requirement.  Proof-of-work, the peer-to-peer gossip network, mining, the mining reward, the blockchain.  The lot.  It’s as if the genius of bitcoin was to ask the question.

But why am I saying this in the summer of 2015? This exact same thing could have been said at any point from 2009 until now.  There’s nothing new here.

Except…

Nobody asks the obvious question:

Who actually wants a censorship resistant digital bearer asset?!

 Well… some people do, of course.  But none of them are banks or corporates.  At least, I’ve not yet met a bank that wants this.

So why are so many banks, corporates, VCs and startups spending so much money in this space?!

I think there are two completely distinct reasons and that that the world of “blockchain technology” is actually two completely different worlds, with different opportunities and different likely winners.  And those who don’t realise this might be about to lose a great deal of money.

First, let’s look at Bitcoin.

We should probably be realistic here.  Bitcoin is not the solution to Greece’s crisis and it won’t bring finance to the world’s poor.  But it turns out that censorship resistance is extremely valuable, even for people who don’t think they need it.

Because censorship resistance implies openness.

Anybody or anything can connect to an open network like Bitcoin to own and transfer value.  And anything that is open, standardised, owned by nobody and useful smells very much like a platform.  And we’ve seen how those stories play out.

But notice something else:  Bitcoin is worse than existing solutions for all the use-cases that banks care about.  It’s expensive. It’s slow. And it’s “regulatorily difficult”.  And this is by design.

So this makes it doubly interesting.

Because it means Bitcoin is probably worse than existing solutions for all the things most people and firms care about but vastly better for one single use-case (open access to value transfer) that could be very useful for some people.

Isn’t that pretty much the definition of a disruptive innovation?   Something that’s worse for existing use-cases but solves a niche use-case very well?

So, if this is true, we should expect to see adoption of Bitcoin come from the margins, solving marginal problems for marginal users.

But disruptive innovations have a habit of learning fast and growing.  They don’t stop at the margins and they work their way in and up.

So this is why I think so many of the big-name VCs are so excited about it.

So the incumbents should be keeping a very close eye on what’s going on.    If anything in this space is going to disrupt them, it will probably come from this world.  But it’s perfectly understandable that vanishingly few of them are actually engaging deeply in this world.

So if Bitcoin isn’t why banks are looking at this space, what are they looking at?  

How have so many people convinced themselves that there is something of interest here that is “separate” to Bitcoin or systems like it?

At this point, it’s customary to observe sagely that “of course, the real genius of bitcoin was the blockchain; that’s where the value is”.

But I’ve discovered something rather amusing.  If you push the people who say this, and ask them what they actually mean, most of them can’t!  And yet…   whether they understand why or not, they are actually on to something.

It comes down to how bitcoin delivers on the design goal of “censorship resistant” cash.

Imagine Bitcoin didn’t already exist and you were asked to design a system of censorship-resistant digital cash.  How would you do i?

Well… you couldn’t build it around a central database: the government could shut it down.  That doesn’t sound very censorship resistant.

And you couldn’t rely on a network of trusted people around the globe since law enforcement could simply collaborate to shut them down too.  And in any case, who would control the identity system that helped you be sure these people were who you thought they were in any case?

It turns out that the answer is quite unexpected… and it’s something I’d bet almost all engineers would consider completely mad.

The answer is that you get everybody who fully participates in the system to maintain a full copy of the ledger.   And every time somebody, anywhere in the world, spends some bitcoin, we’re going to inform everybody who’s maintaining this ledger and they’re going to store a copy of that transaction too.

Bitcoin essentially runs on a MASSIVELY replicated, shared ledger.  (The trick is in keeping it consistent, of course…)

It sounds insanely inefficient and expensive… and perhaps it is. But we also have to ask ourselves:  inefficient and expensive as compared to what?

And this leads us to the other world

Just look at the state of banking IT today…  Payments, Securities, Derivatives… Pick any one.  They all follow the same pattern:  every bank has built or bought at least one, usually several, systems to track positions and manage the lifecycle of trades:  core banking systems, securities settlement systems, multiple derivatives systems and so on.

Each of these systems cost money to build and each of them costs even more to maintain.

And each bank uses these systems to build and maintain its view of the world.  And they have to be connected to each other and kept in sync, usually through reconciliation.

Take even the simplest OTC derivative contract:  it is recorded by both sides of the deal and those two systems have to agree on everything for years.  Very costly to operate.

But what if…  what if these firms – that don’t quite trust each other –used a shared system to record and manage their positions? Now we’d only need one system for an entire industry… not one per firm. It would be more expensive and complicated to run than any given bank-specific systems but the industry-level cost and complexity would be at least an order of magnitude less. One might argue that this is why industry utilities have been so successful.

But a centralised utility also brings issues:  who owns it? Who controls it  How do the users ensure it stays responsive to their needs and remains cost-effective?

The tantalising prospect of the blockchain revolution is that perhaps it offers a third way: a system with the benefits of a centralised, shared infrastructure but without the centralised point of control:  if the data and business logic is shared and replicated, no one firm can assert control, or so the argument goes.

Now, there are lots of unsolved problems: privacy, performance, scalability, does the technology actually work, might we be walking away from a redundant (antifragile?) existing model? Who will build these platforms if they can’t easily charge a fee because of their mutualised nature?  Difficult questions.

But see:  this has nothing to do with funny internet money, bitcoin or censorship-resistant digital cash.  It’s a completely different world

Two revolutions for the price of one

So… the blockchain revolution is so fascinating because it could actually be TWO completely different revolutions…   both profound in their implications:

  • Censorship-resistant digital cash providing a new platform for open, permissionless innovation driven from the margins
  • And industry-level systems of record driving efficiencies for incumbents.

Neither of these are “sure things”… they are both high risk speculative bets… but they’re also very DIFFERENT bets…

[EDIT 2015-07-23 Gideon Greenspan has written a great piece that comes at this argument from a very different angle]

As ever, the thoughts and comment on this blog are mine alone and don’t represent the view of my employer….

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]