Process Improvement and Blockchain: A Payments Example

“I just wired you the funds; did you get them?”… “No… I can’t see them. Which account did you send them to? Which reference did you use? Can you ask your bank to chase?”

red and white metal mail box

The cheque is in the post…

How can we be almost a fifth of the way through the twenty first century and this is still a daily occurrence? How can we be in a world where even if you and I agree that I owe you some money, it’s still a basically totally manual, goodwill-based process to shepherd that payment through to completion?!

The “Settler pattern” reduces opportunities for error and dispute in any payments process – and does so by changing the process

This was the problem we set out to solve when we built the Corda Settler. And I was reminded about this when I overheard some colleagues discussing it the other day. One of them wondered why we don’t include the recipient of a payment in the set of parties that must agree that a payment has actually been made. Isn’t that kinda a bit of an oversight?!

Screenshot 2019-08-09 at 10.35.03.png

The Corda Settler pattern works by moving all possible sources of disagreement in a payment process to the start

As I sketched out the answer, I realised I was also describing some concepts from the distant past… from my days in the middleware industry. In particular, it reminded me of when I used to work on Business Process Management solutions.

And there’s a really important insight from those days that explains why, despite all the stupid claims being made about the magical powers of blockchains and the justifiable cynicism in many quarters, those of us solving customer problems with Corda and some other enterprise-focused blockchain platforms are doing something a little bit different… and its impact is going to surprise a lot of people.

Now… I was in two minds about writing this blog post because words like “middleware” and “business process management” are guaranteed to send most readers to the “close tab” button… Indeed, I fear I am a figure of fun amongst some of my R3 colleagues… what on earth is our CTO – our CTO of all people! – doing talking about boring concepts from twenty years ago?!

But, to be fair, I get laughed at in the office by pretty much everybody some days… especially those when I describe Corda as “like an application server but one where you deploy it for a whole market, not just a single firm” or when I say “it’s like middleware for optimising a whole industry, not just one company.

“Application Servers? Middleware? You’re a dinosaur! It’s all about micro-services and cloud and acronyms you can’t even spell these days, Richard… Get with the programme, Grandad!”

Anyway… the Corda Settler discussion reminded me I had come up with yet another way to send my colleagues round the bend…  because I realised a good way to explain what we’re building with Corda – and enterprise blockchains in general – isn’t just “industry level middleware” or “next generation application servers”… it’s also a new generation of Business Process Management platform…  and many successful projects in this space are actually disguised Industry Process Re-Engineering exercises.

Assuming you haven’t already fallen asleep, here’s what I mean.

Enterprise Blockchains like Corda enable entire markets to move to shared processes

Think back to the promise we’re making with enterprise blockchains and what motivated the design of Corda:

“Imagine if we could apply the lessons of Bitcoin and other cryptocurrencies in how they keep disparate parties in sync about facts they care about to the world of regular business…  imagine if we could bring people who want to transact with each other to a state where they are in consensus about their contracts and trades and agreements… where we knew for sure that What You See Is What I See – WYSIWIS. Think of how much cost we could eliminate through fewer breaks, fewer reconciliation failures and greater data quality… and how much more business we could do together when we can move at pace because we can trust our information”

And that’s exactly what we’ve built. But… and sorry if this shocks anybody… Corda is not based on magic spells and pixie dust…  Instead, it works in part because we drive everybody who uses it to a far greater degree of commonality.

Because if you’re going to move from a world where everybody builds and runs their own distinct applications, which are endlessly out of sync, to one where everybody is using a shared market-level application, what you’re actually saying is: these parties have agreed in some way to align their shared business processes, as embodied in this new shared application.  And when you look at it through that lens, it’s hardly surprising that this approach would drive down deviations and errors…!

I mean: we’re documenting – in deterministically executed code – and for each fact we jointly care about: who can update which records, when and in what ways. And to do that we have to identify and ruthlessly eliminate all the places where disagreements can enter the process.

Because if we know we have eliminated all areas of ambiguity, doubt and disagreement up-front, then we can be sure the rest of our work will execute as if it’s like a train on rails.

Just like trains, if two of them start in the same place and follow the same track… they’ll end up in the same place at the end.

Reducing friction in payments: a worked example

So, for payments, what are those things? What are those things that if we don’t get them right up front can lead to the “I haven’t received your payment” saga I outlined at the start of the post?

Well, there’s the obvious ones like:

  • How much needs to be paid?
  • By whom?
  • To whom?
  • In what kind of money/asset?

There are trickier ones such as:

  • Over what settlement rail should I pay?
  • To which destination must we pay the money?
  • With any reference information?

These are trickier since there is probably a bit of automated negotiation that needs to happen at that point… we need to find a network common to us both… and the format of the routing strings is different for each and so forth. But if you have an ability to manage a back-and-forth negotiation (as Corda does, with the Flow Framework) then it’s pretty simple.

But that still leaves a problem… even if we get all of these things right, we’re still left hanging at the end. Because even if I have paid you the right amount to the right account at the right time and with the right reference, I don’t know that you’ve received it.

And so there’s always that little bit of doubt. Until you’ve acknowledged it you could always turn around in the future and play annoying games with me by claiming not to have received it and force us into dispute… and we’d be back to square one! We’d be in exactly the same position as before: parties who are not in consensus and are instead seeing different information.

And it struck us as a bit mad to be building blockchain solutions that kept everybody in sync about really complicated business processes in multiple industries, only for the prize to be stolen from our grasp at the last moment… when we discover the payment that is invariably the thing that needs to happen at the end of pretty much every process hasn’t actually been acknowledged.

It would be as if our carefully tuned train had jumped off the rails and crashed down the embankment just at the last moment. Calamity!

So we added a crucial extra step when we designed the Corda Settler. We said: not only do you need to agree on all the stuff above, you also need to agree: what will the recipient accept from the sender as irrefutable proof that the payment has been made?

And with one bound, we were free!

Because we can now… wait for it… re-engineer the payment process. We can eliminate the need for the recipient to acknowledge receipt. Because if the sender can secure the proof that the recipient has already said they will accept irrefutably then there is no need to actually ask them… simply presenting them with the proof is enough, by prior agreement.

And this proof may be a digital signature from the recipient bank, or an SPV proof from the Bitcoin network that a particular transaction is buried under sufficient work… or whatever the relevant payment network’s standard of evidence actually is.

But the key point is: we’ve agreed it all up front and made it the sender’s problem… because they have the incentive to mark the payment as “done”. As opposed to today, where it’s the recipient who must confirm receipt but has no incentive to do so, and may have an incentive to delay or lie.

But building on this notion of cryptographic proof of payment, the Corda Settler pattern has allowed us to identify a source of deviation in the payment process and moved it from the end of the process, where it is annoying and expensive and makes everybody sad… and moved it to the start of the process and, in so doing, allows us to keep the train on the rails.

And this approach is universal. Take SWIFT, for example. The innovations delivered with their gpi initiative are a perfect match for the payment process improvements enabled by the Settler pattern.

The APIs made available by Open Banking are also a great match to this approach.

Middleware for markets, Business Process Management for ecosystems, Application Servers for industries..!

And this is what I mean when I say platforms like Corda actually achieve some of their magic because they make it possible to make seemingly trivial improvements to inter-firm business processes and, in so doing, drive up levels of automation and consensus.

So this is why I sometimes say “Corda is middleware for markets”.

It’s as if the first sixty years of IT were all about optimising the operations of individual firms… and that the future of IT will be about optimising entire markets.

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?

Ledgers

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?

 

A simple model to make sense of the proliferation of distributed ledger, smart contract and cryptocurrency projects

Just when I think I understand the cryptocurrency/block chain space, I realize I didn’t understand anything at all

Four recent events have made me realize that I don’t understand this space anywhere near as well as I thought I did.   But that’s good: it means I’ve been forced to come up with a new mental model to explain to myself how all these projects relate to each other.

TL;DR: the two questions to ask about a “fiduciary code” requirement are: who do I need to trust and what am I trusting them about?

Who do I trust

A simple model to capture the essential differences between some consensus platforms

The rest of this article describes the four events that influenced me to draw it.

Event 1: Nick Szabo’s “The Dawn of Trustworthy Computing” Article

In his recent article, Nick Szabo introduces two really helpful terms to explain what makes systems like Bitcoin particularly noteworthy.

  • First, he talks about “block chain computers”. He defines these as the combination of the Bitcoin consensus protocol and strong cryptography to create the unforgeable chain of evidence for all data stored in the block chain data structure.   I think this formulation is useful because it shines a bright light on an obvious, but often overlooked fact: a “block chain” is just a data structure, utterly useless on its own. What makes the Bitcoin blockchain remarkable is the network of computers – and protocol they follow – that makes it so hard for any single actor, no matter how determined, to subvert it.
  • Secondly, he talks about “fiduciary code”: the code in an application that needs to be the most reliable and secure. For example, in a banking application, this is likely to be the core ledger: who owns what. He points out that a secure block chain computer is an extremely expensive piece of kit: you should only use it to secure that information that really needs it.

Event 2: Albert Wenger’s “Bitcoin: Clarifying the Foundational Innovation of the Blockchain” Article.

In this piece, Albert Wenger makes a really obvious-in-hindsight point: Bitcoin-like block chains are organizationally-decentralised – no one organization can control it but the entire point of the system is to build and maintain a logically-centralised outcome: a single copy of the ledger, which everybody agrees is the true single copy.

ArthurB uses the term “decentralized mutable singleton” to capture the same idea, I think.

And he echoes one of Szabo’s implicit points: a “block chain” is not something of value in and of itself. This insight is also important because it edges us further away from the idea that “decentralization” is some sort of end-goal or absolute target. I made a similar point in this piece on the “unbundling of trust” but Albert and Arthur have captured the key point far more succinctly.

Event 3: The Eris Launch

On Wednesday this week, Eris Industries held the launch event for their new platform. Tim Swanson has done a good job summarizing the Eris concepts. (Disclosure: I was invited to, and attended, the launch).

I’ll admit I still don’t fully understand it. But the general picture that’s forming for me is of a platform that allows you to build and maintain one of these “decentralized mutable singletons” but to specify precisely who is allowed to update it and under what conditions.

In essence: take the idea of a shared common state (Albert’s Arthur’s “mutable singleton”) but relax the constraint that the maintenance of it necessarily happens in a fully public, adversarial environment, for which something like a proof-of-work system may be required, and allow for the idea that the participants might be known.  [EDIT wrong name!]

Fine… but I think the Eris insight is where they go next. They suggest that if you had such a system then you might also be able to distribute the processing of application logic more broadly, too. And I think it’s the application logic they’re most interested in. Their documentation is full of talk of “smart contracts” and it’s perhaps no surprise that their founders are lawyers. In fact, maybe that’s why I don’t understand it as well as I’d like: lawyers just seem to speak differently. Maybe I need a translator.

And to be clear, the part I don’t fully understand just yet is why you need a “block chain” as the underlying data structure in this model, rather than something based on more general-purpose replicated database technology. But this may turn out just to be an implementation detail: so let’s see how they get on over time.  There seems to be a lot of content, reflective of a lot of thought, on the various Eris sites.

Event 4: I looked at HyperLedger in more detail

I had reason to look at HyperLedger this week and, combined with my study of Eris, it was this event that finally convinced me that my mental model of this space was far too simplistic.

Hyperledger calls itself an “open-source, decentralized protocol for the recording and transferring anything of value”. This is a bit like how I might have described Colored Coins or Ripple to people in the past.

But what makes Hyperledger different is that they allow the creation of multiple ledgers (one per asset per issuer) and each ledger can be configured to have different consensus rules – you don’t have to make the assumption of an adversarial open public environment… so some similar assumptions to Eris here, but with a ledger designed to track assets rather than business logic/contracts.

Where is this heading?

So I spent some time this evening trying to piece all of this together in my brain.

I’m pretty sure these projects all sit in Szabo’s “Fiduciary Code” space: they only really have value or make sense if the facts they’re recording are really important!

But they make different assumptions about the threat model they face – and some of these assumptions are very different to the ones against which Bitcoin was designed.  And they’re different to the assumptions underpinning some other prominent platforms, such as Ripple, which, through its use of validators and “Unique Node Lists” has a model, whereby you trust a set of known entities who, in turn, trust some other entities, and so on.

In addition, the facts these systems are recording are very different: ownership of a real-world asset on Hyperledger is different to ownership of a bitcoin on the Bitcoin ledger; a ledger-native asset has no counterparty risk, whereas a real-world asset needs an identifiable issuer. And they’re both different to a platform that potentially executes legal contracts.

So I tried to think of dimensions along which you might be able to classify these projects… and I came up with too many.

But it’s almost Christmas and I’m not to be deterred!   Is it really too much to ask for a model with just two dimensions, that doesn’t require a 3-D screen to render?! So I kept on going. And, finally, came up with something that looks so trivial, I worry it may be content free.   But here it is anyway.

I think the two dimensions that help me think about these projects are:

  • “Who do I trust to maintain a truthful record?”; and
  • “What do I need the record to be about”?

Here is the model I came up with.   It’s obviously not complete and you could put some projects in multiple boxes… but I think it captures the key distinctions.

Who do I trust

Another way to think about the increasingly confusing cryptocurrency/Block Chain space

But this is just a view. I’d really value comments… especially if I’ve missed something really obvious.

[UPDATE 2015-01-08 DISCLOSURE: Since publishing this post, I have become an advisor to HyperLedger, in a personal capacity]