Cost? Trust? Something else? What’s the killer-app for Block Chain Technology?

Could decentralized ledgers change the face of accounting?

When I speak to people about decentralised ledgers, some of them are interested in the “distributed trust” aspects of the technology. But, more often, they bring up the question of cost.

This confused me at first. Think back to where this all started: with Bitcoin. Bitcoin is deliberately less efficient than a centralized ledger! Its design adds really difficult engineering constraints to what we already had. How could this technology possibly be cheaper than what we already have?

And yet the claims keep coming. So perhaps this “cost” claim deserves closer consideration. Perhaps there are some scenarios where the “cost” camp might be right?


So much comment in this space talks about “distributed ledgers” or “decentralized ledgers”. But there is very little reflection on what we actually mean by “ledger”.

Investopedia has a good definition of a General Ledger:

A company’s main accounting records. A general ledger is a complete record of financial transactions over the life of a company. The ledger holds account information that is needed to prepare financial statements, and includes accounts for assets, liabilities, owners’ equity, revenues and expenses.

There are some key points here: “complete record of financial transactions”… “information that is needed to prepare financial statements”. I find this a useful definition because it captures two insights that will become important.

  • first, we use ledgers to record facts… things that the company has done, transactions it has entered in to.
  • second, the ledger is not an end-product; rather, it’s something from which we prepare other documents – our balance sheet, for example.

A worked example

So let’s work through an example of a balance sheet to test the “cost” argument.

In what follows, I’ll work through a really simple and not-representative example that constructs a balance sheet for a small firm – and asks if there are any opportunities to apply decentralized consensus technology to the problem.  (And, as will become painfully clear, I’m not an accountant…)

The world’s smallest and most naïve investment bank…

Imagine you had a fetish for being regulated and decided to start your own TINY investment bank. You persuaded your friends and family to invest £1m and opened the company.   You haven’t started trading yet so your accounts are really simple: you have put the £1m you raised in the bank (let’s say Barclays) and, since your friends and family own the firm, you also have £1m of equity – which represents their ownership of the firm. Let’s call it RichardCo.

Hang On – What’s a Balance Sheet?

In my mental model, a Balance Sheet is the financial statement you use as a snapshot of the firm’s financial position at a point in time:

  • What are all the things you owned at that point (your assets)?
  • And what are all the things you owe (your liabilities?).
  • If the difference is positive, great: this is your shareholders’ equity in the business. If it’s negative, it’s game over: you’re insolvent.

So the “balance sheet” for RichardCo on day one might look like this:

Balance Sheet 1

RichardCo’s simple balance sheet. There’s £1m in the bank and you record your shareholders’ funds on the liability side of the balance sheet. The “scroll” is the ledger.

By convention, we put the assets (the things you own) on the left and the liabilities (the things you owe) on the right. And we’ve captured a couple of likely entries from various ledgers that explain where the entries on the balance sheet came from.

Notice how we put the shareholders’ funds (the equity) on the “liabilities” side of the balance sheet. This is because the shareholders’ funds can be thought of as a “residual claim” on the company. If you shut it down (or were shut down), you’d have to sell the assets, use the proceeds to pay off everybody you owed money to and, whatever was left, would be the shareholders’. You’d be liable to pay it to them. So we think of the equity as a liability.

Now, like I say, we haven’t done any business yet. But, already, there’s some complexity here

Think about that £1m in cash. It appears on your balance sheet as an asset and you’ll have a record somewhere recording its receipt from your shareholders and another recording the fact that you paid it into the bank. (Actually, you’ll be using double-entry book-keeping and so you will have four entries in the ledger but let’s leave that to one side for now)

Now think about it from the bank’s perspective. They will also have a record. After all, they took it in as a deposit.  So it will also appear on their balance sheet – but this time as a liability. They owe it to you.

So there are multiple ledgers in two different organisations all recording the same pieces of information and two balance sheets that reflect the position:

  • Your balance sheet, recording the claim against Barclays: an asset
  • Barclays’ balance sheet, recording their obligation to you: a liability

Balance Sheet 2

Your £1m asset in the bank also appears on the bank’s balance sheet, as a liability.

Great – this is as it should be and it makes it possible for us to keep an eye on things. When it’s time to get your accounts audited, the auditor doesn’t just have to trust your ledgers. They can phone up the bank and get them to verify that their recording of the position matches yours. The fact you know this can happen acts as a disincentive to cheat in the first place.

If only banks really were this simple…

But, in reality, it’s far more complex than this.

In reality, banks aren’t funded primarily by equity… they also have a HUGE amount of debt…

So let’s imagine you have gone to some pension funds and borrowed £2m – you want to be prudent for now.

Youou decide to build out your broker-dealer arm first so you use the money you borrowed to buy some shares for inventory: £2m of IBM stock. That gets you about 20,000 shares, which you deposit at a custodian bank for safekeeping.

Let’s also imagine that you enter into some interest rate swaps with some other banks. Perhaps LCH.Clearnet, acts as central counterparty for all these trades.  And, brilliant news! Your derivatives positions have moved in your favour and it looks like you’re up £1m on them!

Great. So your balance sheet now looks like this.

Balance Sheet 3

Your balance sheet after borrowing £2m, entering into some derivatives contracts that move in your favour (£1m mark-to-market – MTM) and buying some IBM shares. Notice how Shareholders’ Funds (equity) has increased by £1m as your assets (the money owed to you by LCH) have increased in value, whilst your debt has stayed the same.

Now think about all the book-keeping at all the other firms

For every position on your ledgers that goes into creating this balance sheet, at least one other entity will also have a ledger that records the same position (from their perspective).

So you might end up with a picture like this:

Balance Sheet 5

Your (still very simple!) balance sheet will be reflected on ledgers and balance sheets all across the financial system.

And this picture isn’t the full story. Remember we said the clearing house stepped in and became your counterparty? So the other participants will, in turn, have their own ledgers on the other side of the clearing house. And your shareholders presumably have their own records. And so on.

Making sure all these ledgers are kept in sync: reconciliation

One of the many important control functions in a bank is to check regularly that all these ledgers line up – that your counterparties agree with you on what it is that each of you own or owe to each other.

But, interestingly, you only really need to agree your positions – not the valuations. You could, quite legitimately, come to different conclusions about the value of some positions. For example, let’s imagine that the pension fund thinks there’s a chance you’ll default on your loan. They will still have a record that you borrowed £2m but they may only value the position on their balance sheet as a £1.9m asset.

This is an interesting subtlety: the fact, as shown on the ledger, is that you owe £2m but the pension fund’s balance sheet may reflect their opinion that they’ll likely only recover £1.9m

Similarly, the fact of your derivatives positions is recorded on your (and LCH’s) ledgers. And you’ve probably agreed to pay (or receive) whatever cashflows their systems calculate. But how you value your overall position on the balance sheet could depend on a whole other set of factors.

So perhaps the picture actually looks like the one below: the “facts” that we need to reconcile between firms are those contained on the underlying ledgers, not the subjective valuations on the balance sheets:

Balance Sheet 6

In principle, we need to reconcile our ledgers to keep everybody accurate and honest. But it’s perfectly OK for the subjective valuations of some of the positions (as reflected on the balance sheets) to be different – such as with the pension fund here.

So, to simplify hugely, we could say that our problem is one of keeping all these disparate ledgers in sync:

Balance Sheet 7

The same picture as before but with the other firms’ balance sheets removed for clarity. Our problem is to make sure these ledgers always agree with each other when they record information about the same transactions.

So we see in the picture above that the facts that underpin my view of the world need occasionally to be checked against at least four other ledgers in other organisations and, in reality, many more.

Enter Decentralised Ledgers

So now let’s turn attention back to the world of decentralized consensus.

I said earlier that it’s hard to argue a decentralised ledger system like Bitcoin that replicates ledger data thousands of times can be more efficient.   But perhaps it (or something like it) can.

Imagine we’re living five or ten years in the future. Perhaps we have a securities block chain that records ownership of all securities in the world. Perhaps we have a derivatives smart contract platform that records (and enforces?) all derivatives contracts? Maybe, even, there will be a single, universal platform of this sort.

If so, perhaps all participants would have a full copy of this ledger.   And so now maybe we can redraw the picture.

Balance Sheet 8

A possible future: all firms record their external obligations and claims on a single shared, massively replicated ledger. Would this reduce (remove?) the need for systems duplication and reconciliation?

Sure – everybody still has a copy of the data locally… but the consensus system ensures that we know the local copy is the same as the copy everywhere else because it is the shared consensus system that is maintaining the ledger. And so we know we’re producing our financial statements using the same facts as all the other participants in the industry.

Does this mean we no longer need audit? No longer need reconciliations? Obviously not, but perhaps this approach is what is driving some of the interest in this space?

But notice: this is just a way of ensuring we agree on the facts: who owns what? Who has agreed to what? We can still run our own valuation algorithms over the top and we could even forward the results to the regulator (who could also, of course, have a copy of the ledger) so they can identify situations where two parties have very different valuations for the same position, which is probably a sign of trouble.

Of course, this is a very simplified example and the real-world is considerably more complex. In particular, some really difficult problems stand in the way of making this a reality:

  • Scale – think about how many transactions would be recorded
  • Security – imagine what would happen if somebody managed to subvert the ledger. This also has implications for who controls it, runs it and is allowed to connect to it. Bitcoin’s pseudonymous consensus system is unlikely to be appropriate here?
  • Privacy – do you really want everybody being able to see all your positions?
  • … and so on.

So I’m really not saying this is how things will pan out but I think it’s a useful thought experiment: it shows a potential use for replicated ledgers that might have utility but which doesn’t depend on being “trust-free” or “censorship-resistant”.

Perhaps this is what some of the other commentators in this space have in mind?


29 thoughts on “Cost? Trust? Something else? What’s the killer-app for Block Chain Technology?

  1. “Notice how we put the shareholders’ funds (the equity) on the “liabilities” side of the balance sheet.” – Someone should have told BitShares this… 😉

  2. Great topic! your thought experiment is very useful for understanding the implication of an open and decentralized ledger.

    It may not be for everyone, but you can imagine that some investors would favor companies that adhere to a form of radical transparency that provides real time data on not just assets, liabilities and valuations, but even internal accounting about budgets, spending, cash flow, etc. Any disadvantages from the competition knowing your books might be balanced by the reduction in middle management used for internal controls.

    This sort of system might first be appropriate for non-profits, who ostensibly have no competitive advantage to secrecy, but it could certainly be applied to types of companies, such as low overhead start ups.

    Another advantage is that an open API would exist for analyzing and processing corporate records. Any corporate services (eg. year end reporting, taxes, etc) built using these APIs could be shared and thus dramatically lower the cost of these services for companies adhering to this open architecture.

  3. Hi Richard,

    Great article. You make some interesting points about cost / trust. I’ve been looking at this problem for a while and came to the conclusion that companies will never adopt a wholly decentralised ledger. Philosophically, a legal entity structure aims to centralise the operations of a business and the recording of events relating to that business, in one place. Decentralised ledgers are not inherently useful for companies to record ALL their accounting journals. As you note, they do have a place, however.

    As an ex-investment bank auditor, the focus of our work was on existence, completeness and valuation of transactions with counter-parties. All the other stuff comes secondary.

    The first hurdle is to ascertain whether or not the transaction actually exists (and is it recorded in the correct period), for widget factories this is trivial; send debtor confirmations, look for post year end cash receipts, etc. for a bank/trading house it’s far more complex, however we mostly used to rely on trade confirmations or reconciliations from clearing houses. Before we could do this, we had to rely on the operational controls of the clearing house, i.e. there is a chain of trust, which if broken, makes an auditors life a nightmare. I.e. if clearing house X fail their SOC-2 controls review and there are no compensating controls then I cannot rely on the data they produce. This happens.

    Secondly, we audited the valuation. The IRS example you use is bread and butter for banking audit… For OTC instruments add in model reserves, liquidity, reserves, day 1 P&L reserve and credit valuation adjustments/debit valuation adjustments and it starts to get rather complex! As you note though, the valuations are subjective. Consequently, we can split journals into two types;

    Transactions (Cash, anything that requires an invoice or that the auditor wants 3rd party evidence for (if possible))
    Local adjustments (I.e. bumping valuations up or down, posting accruals, recognising depreciation)

    The bank can maintain a local ledger containing all its adjustments, however it can also maintain a list of pointers to a distributed ledger which contain details of all exchange traded and OTC derivative contracts. As the distributed ledger is agreed upon by all participants and there are, for example, digital signatures to prove some degree of non-repudiability, we can RELY on this ledger. Now the auditors job starts getting easier!

    Perhaps there is one huge ledger for everything, however it seems more sensible to have a ledger (or chain) for each type of thing; IRS, option agreement, insurance contract, ordinary shares, invoices. Companies just replicate the ledgers which are relevant for them.

    My point is that if you are inherently happy about TRANSACTIONS then the accounting and audit process becomes much more simple; no need for reconciliations or for an auditor to mess about with 3rd party confirmations (which are almost never returned!). An auditor can also gain 100% assurance into existence and completeness of transactions with counter-parties – this is the holy grail of audit. Valuation is another beast and will always require human judgement.

    As mentioned in the above comment, this is super useful, not only for audit. Due diligence, tax reporting, generating data for financial reporting (E.g. IFRS 15) also benefit, among other things.

    I’ve started building the distributed ledger based on a blockchain to record journals pertaining to invoices. It looks more like Factom than Bitcoin. Let me know if you’d like to discuss. Cheers

  4. @Roger – thanks for the detailed comment…. extremely interesting and helpful. Yes – it would be great to discuss. Want to drop me a note? (gendal AT gmail DOT com)

  5. Pingback: The Weekend Read: Jan 16 | Todd Blog
  6. Another great piece Richard. You have a knack of explaining complex topics in an easily digestible way. I’m a big supporter of the ‘market efficiency’ use case for Distributed Ledgers/Smart Contacts and that leads directly to cost saves. Can’t wait 5-10 years though… 🙂

  7. To me, the magic in this space is what we sometimes flippantly call triple entry (link below), which innovation is highlighted by the blockchain’s success in mounting an independent currency over a shared ledger.

    We all know how insubstantial internal ledger entries are, and how we can really only lean on them to the extent that we trust our internal processes (e.g. slightly germane is the events of 2007-08 leading to a popular view that accounting and audit have failed us).

    On the other hand, we also see how solid the payment systems are. Whether bank- or govt- or private-run, payments generally work. When these multi-party activities do not work, all hell breaks loose, and people run, sometimes quite literally, to other systems.

    When accounting ledgers break, we shrug. Triple entry takes us from the unreliable fantasy of the accounting entry to the hard concrete reality of the payment: the distributed ledger is as solid as a payment.

    This doesn’t replace double entry, nor does it replace classical payment systems. Rather it augments it by providing a way for parties to share certain transactions as if they were as solid as payments.

    E.g., when RichardCo decides to place its capital at Barclays, it will no longer rely on its accounting systems alone to describe this situation, and neither will Barclays. Both of these parties will share a “receipt” that is cryptographically signed by some party that has mediated it (could be Barclays, could be the Bank of England, or it could be VirginMoney).

    That’s three parties, each holding a copy of the same receipt, hence the label triple entry. In the Bitcoin world, that middle intermediator is the blockchain, but single servers or replicated servers or small partner groups are equally applicable and in many cases better.

    The receipt itself is strong because it is cryptographically authorised by the payer, and cryptographically signed off by the mediator (as a minimum). It represents such high class evidence that it is practically irrefutable in terms of the facts on record, and it is trivially automatable in audit terms.

    Holding this entry is far more flexible than RichardCo and Barclays relying on their double entry systems because firstly you can build the double entry systems out of the collection of receipts any time you need them, and secondly, it is so strong that it can be used as evidence to create derivative claims. E.g., it’s a set-up for securitisation or loaning or other more advanced uses. And, it’s a lot easier to audit because it is such solid evidence.

    Back to bitcoin and its blockchain. This is the first successful experiment in a large scale triple entry issuance. In part, seeing what happens on the blockchainn generates excitement because we perceive an ability for any company to turn its stalled internal assets into contracts that are then dynamically mediated through cryptographic receipts.

    Now, that contracting arrangement isn’t there yet (see for example the conceptual tussle between smart contracts and Ricardian Contracts as mechanisms of issuance) but it will get there. Once I can issue all my accounted assets into a triple entry arrangement that others will instantly respect, finance will democratise so fiercely that if you’re not seeing where it’s going, the shock will probably take you down.

  8. @hyder… ha! Well… I’ve tried making nearer-term predictions in the past and been told I was delusional 🙂

    @iang – really helpful post… thank you for taking the time to spell it out so clearly. One question though: I find the term “triple entry” really confusing! In my simplistic mind, I think of “double-entry” as being all about ensuring that a *single set* of accounting records (i.e. within an organisation) are self-reconciling… every act is recorded in two places. However, if I’m understanding your description of “triple-entry”, you’re talking about a different concept… about how economic activity *between* two entities can (should) be recorded by both parties (each as part of their own double-entry system – so four entries) AND by an unimpeachable third party (another entry or entries). Did I get that right?

  9. First I want to highlight what might be the best line ever in a post about fintech, crypto, etc (and quite possibly beyond): “Imagine you had a fetish for being regulated…”

    Okay, now back to being serious, this is a great post and definitely lots of food for thought. For me it highlights a couple key points (please forgive me if they are obvious) that I have been mulling over myself:

    1) Cost and Trust are inherently intermingled here – level of trust has an inverse relationship to level of cost and it seems similar to the issues that Ripple has tried to address with trust line – and to my mind with middling success

    2) Valuations as subjective – I know that we have accepted this as the case but does it really have to be? Particularly if you are to develop a system which uses smart contracts (read: does not rely on people) to execute contracts and perhaps even determine a suggested valuations based on previous behavioral patterns. This would go a long way to solving the issue of trust since you are using the identity (always comes back to that!) of the user to determine the valuation on your own books – this may be more of a crypto 4.0 innovation when the systems that provide this information have already been rationalized an integrated but one can dream!

    To clarify: I am using identity in order to refer to the pertinent relevant information versus an entire profile of an individual or entity

  10. Yes, triple entry might be considered a radical departure from double entry. In double entry, in order to make the entries reliable, we duplicate it onto opposite sides. This neat trick makes it very clear to an auditor if there is an error (entries don’t match, so, fix them!) or a fraud (entries match, behead the accountant!) which overall makes the meta-entry reliable. Arguably, it was this innovation that allowed Italian merchant houses to grow beyond the bounds of “trusted family bookeeping.”

    Instead of this technique we use cryptographic signatures to make one entry as reliable (or more reliable) than a double entry pair. These signed entries are so strong that we can even use them as a payment token, so a payment from Alice to Bob ends up being held on Alice’s books, on Bob’s books and also on Ivan the issuer or intermediary’s books. That latter part is the blockchain in Bitcoin world, but it can be a single server.

    Hence there are three copies of the entry, one for each interested party, and hence triple entry. (We could suggest it is just a software triviality to take all your entries and then break out the information into a double entry ledger; this would be like recovering a SQL database from its log entries, read each entry and “inject” the resultant information until you’ve read the entire log.)

  11. @jo – thanks for the comment. Not sure I understood your comment about trust and cost being inversely related. e.g. if we take the pure Bitcoin space, one could argue that my trust in it probably should increase in direct proportion to the amount of hashing power (=cost) being applied to it. So direct, not inverse. Am I misunderstanding you?

  12. @iang – thanks. That’s the first time I’ve come close to understanding the concept, I think. I’ve written recently in private correspondence that I hate the term triple-entry. (In fact, I think I wrote the word “hate” more than once and used capitals and asterisks…) Perhaps I need to do some back-tracking and owe you an apology 🙂

    One point thought: is it necessarily true that the cryptographically signed receipt is sufficient to recover the journal entries? e.g. a signed bitcoin transaction can be used to reconstruct a ledger entry on the sender-side that shows a reduction in the number of bitcoins being held. And it can be used to reconstruct a ledger entry on the receiver-side that shows the opposite. But it does nothing to help me construct the second entry for each of those parties… i.e. how do I reconstruct the entry showing the increase in inventory of widgets that arose as a result of paying the supplier for them? I guess the receipt *could* include that information but today’s bitcoin system doesn’t do that, right?

  13. @gendel – Certainly, in my work, there is a memo field inside the transaction which can be used to support the other ledger, but it’s never been used as such. I think a fair reason for being skeptical over full double entry recovery from the pure receipt is that there is information that isn’t knowable at the time of the receipt. That is, meta-data gets added later by end-users. Also in a published ledger such as bitcoin, it is unlikely that users will give away any information they don’t have to.

    But the receipt can be augmented with additional information; it is still a single entry. Whether this amounts to anything in practice will have to await large scale tests at the accounting level.

  14. It’s completely fair to be skeptical about the whole notion of triple entry. On the one hand, we’re into the information age, even the persistent peer-to-peer age. And we’ve got crypto and open networks, things which are game changers. Pure information plays like accounting should be being challenged, why so little result up until now?

    But on the other hand, double entry has shown itself to be remarkably strong, and while I think the ideas behind triple entry are fairly radical, I’m not actually convinced it is the final word. For example, it’s a bit of a handwavy claim to say that blockchain is triple entry. For my money, I press the case, but I’m keen to see how history treats it. Hold on to that apology, but I’ll take a coffee as an advance payment 😉

  16. Pingback: Bitcoin, Accounting and the Blockchain - Digital Thinking
  17. Pingback: A Simple Model for Smart Contracts | Richard Gendal Brown
  18. Pingback: The myth of a cheaper Bitcoin network: a note about transaction processing, currency conversion and Bitcoinland | Great Wall of Numbers
  19. Pingback: 一个简单的智能合约模型 | 巴比特
  20. Pingback: Can Bitcoin’s internal economy securely grow relative to its inputs? | Great Wall of Numbers
  21. Pingback: Think The Blockchain is Interesting But Bitcoin Isn’t? Think Again | The Innovation Blog
  22. Pingback: Think The Blockchain is Interesting But Bitcoin Isn’t? Think Again | Bank Innovation
  23. Pingback: Learning from the past to build an improved future of fintech | Great Wall of Numbers
  24. Pingback: Worlds collide: JPM works with team behind anonymous crypto Zcash | American Banker | FintechLab
  25. Pingback: 一个简单的智能合约模型 | 区刻

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s