Tag Archives: Mainelli


In Third Parties We (Mis)trust?

Technology is transforming trust. Never before has there been a time when it’s been easier to start a distant geographical relationship. With a credible website and reasonable products or services, people are prepared to learn about companies half a world away and enter into commerce with them.

Society is changing radically when people find themselves trusting people with whom they’ve had no experience, e.g. on eBay or Facebook, more than with banks they’ve dealt with their whole lives.

Mutual distributed ledgers pose a threat to the trust relationship in financial services.

The History of Trust

Trust leverages a history of relationships to extend credit and benefit of the doubt to someone. Trust is about much more than money; it’s about human relationships, obligations and experiences and about anticipating what other people will do.

In risky environments, trust enables cooperation and permits voluntary participation in mutually beneficial transactions that are otherwise costly to enforce or cannot be enforced by third parties. By taking a risk on trust, we increase the amount of cooperation throughout society while simultaneously reducing the costs, unless we are wronged.

Trust is not a simple concept, nor is it necessarily an unmitigated good, but trust is the stock-in-trade of financial services. In reality, financial services trade on mistrust. If people trusted each other on transactions, many financial services might be redundant.

People use trusted third parties in many roles in finance, for settlement, as custodians, as payment providers, as poolers of risk. Trusted third parties perform three roles:

  • validate – confirming the existence of something to be traded and membership of the trading community;
  • safeguard – preventing duplicate transactions, i.e. someone selling the same thing twice or “double-spending”;
  • preserve – holding the history of transactions to help analysis and oversight, and in the event of disputes.

A ledger is a book, file or other record of financial transactions. People have used various technologies for ledgers over the centuries. The Sumerians used clay cuneiform tablets. Medieval folk split tally sticks. In the modern era, the implementation of choice for a ledger is a central database, found in all modern accounting systems. In many situations, each business keeps its own central database with all its own transactions in it, and these systems are reconciled, often manually and at great expense if something goes wrong.

But in cases where many parties interact and need to keep track of complex sets of transactions they have traditionally found that creating a centralized ledger is helpful. A centralized transaction ledger needs a trusted third party who makes the entries (validates), prevents double counting or double spending (safeguards) and holds the transaction histories (preserves). Over the ages, centralized ledgers are found in registries (land, shipping, tax), exchanges (stocks, bonds) or libraries (index and borrowing records), just to give a few examples.

The latest technological approach to all of this is the distributed ledger (aka blockchain aka distributed consensus ledger aka the mutual distributed ledger, or MDL, the term we’ll stick to here). To understand the concept, it helps to look back over the story of its development:

 1960/’70s: Databases

The current database paradigm began around 1970 with the invention of the relational model, and the widespread adoption of magnetic tape for record-keeping. Society runs on these tools to this day, even though some important things are hard to represent using them. Trusted third parties work well on databases, but correctly recording remote transactions can be problematic.

One approach to remote transactions is to connect machines and work out the lumps as you go. But when data leaves one database and crosses an organizational boundary, problems start. For Organization A, the contents of Database A are operational reality, true until proven otherwise. But for Organization B, the message from A is a statement of opinion. Orders sit as “maybe” until payment is made, and is cleared past the last possible chargeback: This tentative quality is always attached to data from the outside.

1980/’90s: Networks

Ubiquitous computer networking came of age two decades after the database revolution, starting with protocols like email and hitting its full flowering with the invention of the World Wide Web in the early 1990s. The network continues to get smarter, faster and cheaper, as well as more ubiquitous – and it is starting to show up in devices like our lightbulbs under names like the Internet of Things. While machines can now talk to each other, the systems that help us run our lives do not yet connect in joined-up ways.

Although in theory information could just flow from one database to another with your permission, in practice the technical costs of connecting databases are huge. Worse, we go back to paper and metaphors from the age of paper because we cannot get the connection software right. All too often, the computer is simply a way to fill out forms: a high-tech paper simulator. It is nearly impossible to get two large entities to share our information between them on our behalf.

Of course, there are attempts to clarify this mess – to introduce standards and code reusability to help streamline business interoperability. You can choose from EDI, XMI-EDI, JSON, SOAP, XML-RPC, JSON-RPC, WSDL and half a dozen more standards to “assist” your integration processes. The reason there are so many standards is because none of them finally solved the problem.

Take the problem of scaling collaboration. Say that two of us have paid the up-front costs of collaboration and have achieved seamless technical harmony, and now a third partner joins our union, then a fourth and a fifth … by five partners, we have 13 connections to debug, by 10 partners the number is 45. The cost of collaboration keeps going up for each new partner as they join our network, and the result is small pools of collaboration that just will not grow. This isn’t an abstract problem – this is banking, this is finance, medicine, electrical grids, food supplies and the government.

A common approach to this quadratic quandary is to put somebody in charge, a hub-and-spoke solution. We pick an organization – Visa would be typical – and all agree that we will connect to Visa using its standard interface. Each organization has to get just a single connector right. Visa takes 1% off the top, making sure that everything clears properly.

But while a third party may be trusted, it doesn’t mean it is trustworthy. There are a few problems with this approach, but they can be summarized as “natural monopolies.” Being a hub for others is a license to print money for anybody that achieves incumbent status. Visa gets 1% or more of a very sizeable fraction of the world’s transactions with this game; Swift likewise.

If you ever wonder what the economic upside of the MDL business might be, just have a think about how big that number is across all forms of trusted third parties.

2000/’10s: Mutual Distributed Ledgers

MDL technology securely stores transaction records in multiple locations with no central ownership. MDLs allow groups of people to validate, record and track transactions across a network of decentralized computer systems with varying degrees of control of the ledger. Everyone shares the ledger. The ledger itself is a distributed data structure held in part or in its entirety by each participating computer system. The computer systems follow a common protocol to add transactions. The protocol is distributed using peer-to-peer application architecture. MDLs are not technically new – concurrent and distributed databases have been a research area since at least the 1970s. Z/Yen built its first one in 1995.

Historically, distributed ledgers have suffered from two perceived disadvantages; insecurity and complexity. These two perceptions are changing rapidly because of the growing use of blockchain technology, the MDL of choice for cryptocurrencies. Cryptocurrencies need to:

  • validate – have a trust model for time-stamping transactions by members of the community;
  • safeguard – have a set of rules for sharing data of guaranteed accuracy;
  • preserve – have a common history of transactions.

If faith in the technology’s integrity continues to grow, then MDLs might substitute for two roles of a trusted third party, preventing duplicate transactions and providing a verifiable public record of all transactions. Trust moves from the third party to the technology. Emerging techniques, such as, smart contracts and decentralized autonomous organizations, might in future also permit MDLs to act as automated agents.

A cryptocurrency like bitcoin is an MDL with “mining on top.” The mining substitutes for trust: “proof of work” is simply proof that you have a warehouse of expensive computers working, and the proof is the output of their calculations! Cryptocurrency blockchains do not require a central authority or trusted third party to coordinate interactions, validate transactions or oversee behavior.

However, when the virtual currency is going to be exchanged for real-world assets, we come back to needing trusted third parties to trade ships or houses or automobiles for virtual currency. A big consequence may be that the first role of a trusted third party, validating an asset and identifying community members, becomes the most important. This is why MDLs may challenge the structure of financial services, even though financial services are here to stay.

Boring ledgers meet smart contracts

MDLs and blockchain architecture are essentially protocols that can work as well as hub-and-spoke for getting things done, but without the liability of a trusted third party in the center that might choose to exploit the natural monopoly. Even with smaller trusted third parties, MDLs have some magic properties, the same agreed data on all nodes, “distributed consensus,” rather than passing data around through messages.

In the future, smart contracts can store promises to pay and promises to deliver without having a middleman or exposing people to the risk of fraud. The same logic that secured “currency” in bitcoin can be used to secure little pieces of detached business logic. Smart contracts may automatically move funds in accordance with instructions given long ago, like a will or a futures contract. For pure digital assets there is no counterparty risk because the value to be transferred can be locked into the contract when it is created, and released automatically when the conditions and terms are met: If the contract is clear, then fraud is impossible, because the program actually has real control of the assets involved rather than requiring trustworthy middle-men like ATM machines or car rental agents. Of course, such structures challenge some of our current thinking on liquidity.

Long Finance has a Zen-style koan, “if you have trust I shall give you trust; if you have no trust I shall take it away.” Cryptocurrencies and MDLs are gaining more and more trust. Trust in contractual relationships mediated by machines sounds like science fiction, but the financial sector has profitably adapted to the ATM machine, Visa, Swift, Big Bang, HFT and many other innovations. New ledger technology will enable new kinds of businesses, as reducing the cost of trust and fixing problems allows new kinds of enterprises to be profitable. The speed of adoption of new technology sorts winners from losers.

Make no mistake: The core generation of value has not changed; banks are trusted third parties. The implication, though, is that much more will be spent on identity, such as Anti-Money-Laundering/Know-Your-Customer backed by indemnity, and asset validation, than transaction fees.

A U.S. political T-shirt about terrorists and religion inspires a closing thought: “It’s not that all cheats are trusted third parties; it’s that all trusted third parties are tempted to cheat.” MDLs move some of that trust into technology. And as costs and barriers to trusted third parties fall, expect demand and supply to increase.


Why Insurers Caught the Blockchain Bug

In April 2015, Lloyd’s of London launched the Target Operating Model (TOM) project. TOM is a central body responsible for delivering modernization to the still heavily paper-based wholesale insurance transactions in the London insurance markets.

You can state, “I Support TOM,” on a registration site or you can “like” TOM on social media. The project has had several “innovation” events. It has an orange logo reminiscent of the 1990s, when orange was the new black. The project has even tried to coin yet another tech mashup term for the London insurance markets surrounding Lloyd’s: InsTech.

This is not the first time the London insurance markets have tried to modernize. They are serial reformers, and their attempts have had varying degrees of success (from total failure to middling impact).

Limnet (London Insurance Market Network) made progress with electronic data interchange in the 1980s and early 1990s. Electronic Placement Support (EPS) worked in the late 1990s, but few used it. Kinnect, at a cost conservatively quoted as £70 million, was abandoned in 2006. Project Darwin, which operated from 2011 to 2013, achieved little. The Message Exchange Limited (TMEL) is a messaging hub for ACORD messages that has had modest success, but most people still use email.

Numerous private exchanges or electronic messaging ventures have gained only partial market shares. Xchanging Ins-Sure Services (XIS), a claims and premiums processing joint venture, was formed in 2000 and runs adequately but still has a lot of paper involved.

A swift walk round Lloyd’s, perhaps passing by the famous Lamb Tavern in Leadenhall Market, reveals a lot of heavy bundles of paper, lengthening the arms of long-term insurers.

Does ontogeny recapitulate phylogeny?

Ernst Haeckel (1834–1919) was a German biologist and philosopher who proposed a (now largely discredited) biological hypothesis, the “theory of recapitulation.” He proposed that, in developing from embryo to adult, animals go through stages resembling or representing successive stages in the evolution of their remote ancestors. His catchphrase was “ontogeny recapitulates phylogeny.”

In a similar way, TOM seems to be going through all the previous stages of former wholesale insurance modernization projects, databases, networks and messaging centers, but it may come out at the end to realize the potential of mutual distributed ledgers (aka blockchain technology).

Information technology systems may have now evolved to meet the demanding requirements of wholesale insurance. And wholesale insurance differs from capital market finance in some important ways.

First, insurance is a “promise to pay in future,” not an asset transfer today. Second, while capital markets trade on information asymmetry, insurance is theoretically a market of perfect information and symmetry—you have to reveal everything of possible relevance to your insurer, but each of you has different exposure positions and interpretations of risk. Third, wholesale insurance is “bespoke.” You can’t give your insurance cover to someone else.

These three points lead to a complex set of interactions among numerous parties. Clients, brokers, underwriters, claims assessors, valuation experts, legal firms, actuaries and accountants all have a part in writing a policy, not to mention in handling subsequent claims.

People from the capital markets who believe insurance should become a traded market miss some key points. Let’s examine two: one about market structure, and one about technology.

TIn terms of market structure: People use trusted third parties in many roles—in finance, for settlement, as custodians, as payment providers and as poolers of risk. Trusted third parties perform three roles, to:

  • Validate — confirming the existence of something to be traded and the membership of the trading community
  • Safeguard — preventing duplicate transactions, i.e. someone selling the same thing twice or “double-spending”
  • Preserve — holding the history of transactions to help analysis and oversight and in the event of disputes.

Concerns over centralization

The hundreds of firms in the London markets are rightly concerned about a central third party that might hold their information to ransom. The firms want to avoid natural monopolies, particularly as agreed information is crucial over multi-year contracts. They are also concerned about a central third party that must be used for messaging because, without choice, the natural monopoly rents might become excessive.

Many historic reforms failed to propose technology that recognized this market structure. Mutual distributed ledgers (MDLs), however, provide pervasive, persistent and permanent records. MDL technology securely stores transaction records in multiple locations with no central ownership. MDLs allow groups of people to validate, record and track transactions across a network of decentralized computer systems with varying degrees of control of the ledger. In such a system, everyone shares the ledger. The ledger itself is a distributed data structure, held in part or in its entirety by each participating computer system. Trust in safeguarding and preservation moves from a central third-party to the technology.

Emerging techniques, such as smart contracts and decentralized autonomous organizations, might, in the future, also permit MDLs to act as automated agents.

Beat the TOM-TOM

Because MDLs enable organizations to work together on common data, they exhibit a paradox. MDLs are logically central but are technically distributed. They act as if they are central databases, where everyone shares the same information.

However, the information is distributed across multiple (or multitudinous) sites so that no one person can gain control over the value of the information. Everyone has a copy. Everyone can recreate the entire market from someone else’s copy. However, everyone can only “see” what their cryptographic keys permit.

How do we know this works? We at Z/Yen, a commercial think tank, have built several insurance application prototypes for clients who seek examples, such as motor, small business and insurance deal-rooms. The technical success of blockchain technologies in cryptocurrencies—such as Bitcoin, Ethereum and Ripple—have shown that complex multi-party transactions are possible using MDLs. And, we have built a system that handles ACORD messages with no need for “messaging.”

Z/Yen’s work in this space dates to 1995. Until recently, though, most in financial services dismissed MDLs as too complex and insecure. The recent mania around cryptocurrencies has led to a reappraisal of their potential, as blockchains are just one form of MDL. That said, MDLs are “mutual,” and a number of people need to move ahead together. Further, traditional commercial models of controlling and licensing intellectual property are less likely to be successful at the core of the market. The intellectual property needs to be shared.

A message is getting out on the jungle drums that MDLs, while not easy, do work at a time when people are rethinking the future of wholesale insurance.

If TOM helps push people to work together, perhaps, this time, market reform will embrace a generation of technology that will finally meet the demands of a difficult, yet essential and successful, centuries-old market.

Perhaps TOM should be beating the MDL drums more loudly.

What Is and What Isn’t a Blockchain?

I Block, Therefore I Chain?

What is, and what isn’t, a “blockchain”?  The Bitcoin cryptocurrency uses a data structure that I have often termed as part of a class of “mutual distributed ledgers.” Let me set out the terms as I understand them:

  • ledger – a record of transactions;
  • distributed – divided among several or many, in multiple locations;
  • mutual – shared in common, or owned by a community;
  • mutual distributed ledger (MDL) – a  record of transactions shared in common and stored in multiple locations;
  • mutual distributed ledger technology – a technology that provides an immutable record of transactions shared in common and stored in multiple locations.

Interestingly, the 2008 Satoshi Nakamoto paper that preceded the Jan. 1, 2009, launch of the Bitcoin protocol does not use the term “blockchain” or “block chain.” It does refer to “blocks.” It does refer to “chains.” It does refer to “blocks” being “chained” and also a “proof-of-work chain.” The paper’s conclusion echoes a MDL – “we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.” [Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, bitcoin.org (2008)]

I have been unable to find the person who coined the term “block chain” or “blockchain.” [Contributions welcome!] The term “blockchain” only makes it into Google Trends in March 2012, more than three years from the launch of the Bitcoin protocol.


And the tide may be turning. In July 2015, the States of Jersey issued a consultation document on regulation of virtual currencies and referred to “distributed ledger technology.” In January 2016, the U.K. Government Office of Science fixed on “distributed ledger technology,” as does the Financial Conduct Authority and the Bank of England. Etymological evolution is not over.

Ledger Challenge

Wuz we first? Back in 1995, our firm, Z/Yen, faced a technical problem. We were building a highly secure case management system that would be used in the field by case officers on personal computers. Case officers would enter confidential details on the development and progress of their work. We needed to run a large concurrent database over numerous machines. We could not count on case officers out on the road dialing in or using Internet connections. Given the highly sensitive nature of the cases, security was paramount, and we couldn’t even trust the case officers overly much, so a full audit trail was required.

We took advantage of our clients’ “four eyes” policy. Case officers worked on all cases together with someone else, and not on all cases with the same person. Case officers had to jointly agree on a final version of a case file. We could count on them (mostly) running into sufficient other case officers over a reasonable period and using their encounters to transmit data on all cases. So we built a decentralized system where every computer had a copy of everything, but encrypted so case officers could only view their own work, oblivious to the many other records on their machines. When case officers met each other, their machines would “openly” swap their joint files over a cable or floppy disk but “confidentially” swap everyone else’s encrypted files behind the scenes, too. Even back at headquarters, four servers treated each other as peers rather than having a master central database. If a case officer failed to “bump into” enough people, then he or she would be called and asked to dial in or meet someone or drop by headquarters to synchronize.  This was, in practice, rarely required.

We called these decentralized chains “data stacks.” We encrypted all of the files on the machines, permitting case officers to share keys only for their shared cases. We encrypted a hash of every record within each subsequent record, a process we called “sleeving.” We wound up with a highly successful system that had a continuous chain of sequentially encrypted records across multiple machines treating each other as peers. We had some problems with synchronizing a concurrent database, but they were surmounted.

Around the time of our work, there were other attempts to do similar highly secure distributed transaction databases, e.g. Ian Griggs and Ricardo on payments, Stanford University and LOCKSS and CLOCKSS for academic archiving. Some people might point out that we weren’t probably truly peer-to-peer, reserving that accolade for Gnutella in 2000. Whatever. We may have been bright, perhaps even first, but were not alone.

Good or Bad Databases?

In a strict sense, MDLs are bad databases. They wastefully store information about every single alteration or addition and never delete.

In another sense, MDLs are great databases. In a world of connectivity and cheap storage, it can be a good engineering choice to record everything “forever.” MDLs make great central databases, logically central but physically distributed. This means that they eliminate a lot of messaging. Rather than sending you a file to edit, which you edit, sending back a copy to me, then sending a further copy on to someone else for more processing, all of us can access a central copy with a full audit trail of all changes. The more people involved in the messaging, the more mutual the participation, the more efficient this approach becomes.

Trillions of Choices

Perhaps the most significant announcement of 2015 was in January from IBM and Samsung. They announced their intention to work together on mutual distributed ledgers (aka blockchain technology) for the Internet-of Things. ADEPT (Autonomous Decentralized Peer-to-Peer Telemetry) is a jointly developed system for distributed networks of devices.

In summer 2015, a North American energy insurer raised an interesting problem with us. It was looking at insuring U.S. energy companies about to offer reduced electricity rates to clients that allowed them to turn appliances on and off — for example, a freezer. Now, freezers in America can hold substantial and valuable quantities of foodstuffs, often several thousand dollars. Obviously, the insurer was worried about correctly pricing a policy for the electricity firm in case there was some enormous cyber-attack or network disturbance.

Imagine coming home to find your freezer off and several thousands of dollars of thawed mush inside. You ring your home and contents insurer, which notes that you have one of those new-fangled electricity contracts: The fault probably lies with the electricity company; go claim from them. You ring the electricity company. In a fit of customer service, the company denies having anything to do with turning off your freezer; if anything, it was probably the freezer manufacturer that is at fault. The freezer manufacturer knows for a fact that there is nothing wrong except that you and the electricity company must have installed things improperly. Of course, the other parties think, you may not be all you seem to be. Perhaps you unplugged the freezer to vacuum your house and forgot to reconnect things. Perhaps you were a bit tight on funds and thought you could turn your frozen food into “liquid assets.”

I believe IBM and Samsung foresee, correctly, 10 billion people with hundreds of ledgers each, a trillion distributed ledgers. My freezer-electricity-control-ledger, my entertainment system, home security system, heating-and-cooling systems, telephone, autonomous automobile, local area network, etc. In the future, machines will make decisions and send buy-and-sell signals to each other that have large financial consequences. Somewhat coyly, we pointed out to our North American insurer that it should perhaps be telling the electricity company which freezers to shut off first, starting with the ones with low-value contents.

A trillion or so ledgers will not run through a single one. The idea behind cryptocurrencies is “permissionless” participation — any of the billions of people on the planet can participate. Another way of looking at this is that all of the billions of people on the planet are “permissioned” to participate in the Bitcoin protocol for payments. The problem is that they will not be continuous participants. They will dip in and out.

Some obvious implementation choices are: public vs. private? Is reading the ledger open to all or just to defined members of a limited community? Permissioned vs. permissionless? Are only people with permission allowed to add transactions, or can anyone attempt to add a transaction? True peer-to-peer or merely decentralized? Are all nodes equal and performing the same tasks, or do some nodes have more power and additional tasks?

People also need to decide if they want to use an existing ledger service (e.g. Bitcoin, Ethereum, Ripple), copy a ledger off-the-shelf, or build their own. Building your own is not easy, but it’s not impossible. People have enough trouble implementing a single database, so a welter of distributed databases is more complex, sure. However, if my firm can implement a couple of hundred with numerous variations, then it is not impossible for others.

The Coin Is Not the Chain

Another sticking point of terminology is adding transactions. There are numerous validation mechanisms for authorizing new transactions, e.g. proof-of-work, proof-of-stake, consensus or identity mechanisms. I divide these into “proof-of-work,”  i.e. “mining,” and consider all others various forms of “voting” to agree. Sometimes, one person has all the votes. Sometimes, a group does. Sometimes, more complicated voting structures are built to reflect the power and economic environment in which the MDL operates. As Stalin said, “I consider it completely unimportant who in the party will vote, or how; but what is extraordinarily important is this — who will count the votes, and how.”

As the various definitions above show, the blockchain is the data structure, the mechanism for recording transactions, not the mechanism for authorizing new transactions. So the taxonomy starts with an MDL or shared ledger; one kind of MDL is a permissionless shared ledger, and one form of permissionless shared ledger is a blockchain.

Last year, Z/Yen created a timestamping service, MetroGnomo, with the States of Alderney. We used a mutual distributed ledger technology, i.e. a technology that provides an immutable record of transactions shared in common and stored in multiple locations. However, we did not use “mining” to authorize new transactions. Because the incentive to cheat appears irrelevant here, we used an approach called “agnostic woven” broadcasting from “transmitters” to “receivers” — to paraphrase Douglas Hofstadter, we created an Eternal Golden Braid.

So is MetroGnomo based on a blockchain? I say that MetroGnomo uses a MDL, part of a wider family that includes the Bitcoin blockchain along with others that claim use technologies similar to the Bitcoin blockchain. I believe that the mechanism for adding new transactions is novel (probably). For me, it is a moot point if we “block” a group of transactions or write them out singly (blocksize = 1).

Yes, I struggle with “blockchain.” When people talk to me about blockchain, it’s as if they’re trying to talk about databases yet keep referring to “The Ingres” or “The Oracle.” They presume the technological solution, “I think I need an Oracle” (sic), before specifying the generic technology, “I think I need a database.” Yet I also struggle with MDL. It may be strictly correct, but it is long and boring. Blockchain, or even “chains” or “ChainZ” is cuter.

We have tested alternative terms such as “replicated authoritative immutable ledger,” “persistent, pervasive,and permanent ledger” and even the louche “consensual ledger.” My favorite might be ChainLedgers. Or Distributed ChainLedgers. Or LedgerChains. Who cares about strict correctness? Let’s try to work harder on a common term. All suggestions welcome!