2018 September 03 - Volume.2 Issue.35

Goto Previous Issue - Next Issue

2018 September 03 - Volume.2 Issue.35

Goto Previous Issue - Next Issue

Single Points of Failure and Trust in Financial Market Infrastructure

Sara Feenan – Clearmatics

As a continuation of our series on distributed Financial Market Infrastructure, this article focuses on single points of failure and the less discussed single points of trust and how these are bugs, not features in systemically important infrastructure. The first section focuses on single points of failure with an analysis on central counterparties (CCPs), then we move onto single points of trust in market infrastructure and finally, how a blockchain can solve for some of these issues.


A central counterparty, as described by the Bank of International Settlement (BIS), is “an entity that interposes itself to become the buyer to every seller and the seller to every buyer and thereby guaranteeing the performance of open contracts.” Long before that, in the late 19th century, CCPs were member-owned, self-regulating entities conceived to reduce transaction costs. They devised incentives for their members to adhere to their rules, including penalisation for not doing so. Evaluation of solvency was introduced as a way to pre-empt failing to meet obligations, and then followed calculation and posting of initial and variation margin. They emerged as a fix. Now, to some, they represent the biggest systemic risk in finance.

Fast forward: CCPs fared relatively well during the Great Financial Crisis, acting as a shock absorber. According to a Bank of Canada report (2010), the benefits primarily being reduced counterparty credit risk, which, according to the Counterparty Risk Management Policy Group II (2005), is the single most important variable in determining whether a financial disturbance becomes a financial shock. As a result, leaders at the G20 Pittsburgh Summit in 2009 agreed to move standardised OTC contracts into the cleared model.

Since then, central clearing has evolved. According to BIS trends (2015) The share of centrally cleared transactions has increased significantly and the industry has grown more concentrated based on the Herfindahl index. The range of financial institutions that channel their transactions through CCPs has broadened and CCPs offer clearing services for derivatives, cash and repo markets. The trend towards more interconnectedness is clear.

CCPs need to be unassailable in the face of a crisis. Currently, if a financial shock produces losses that outweigh the CCP's prefunded and callable resources, a CCP could be forced into resolution and fail. Such a failure would likely have catastrophic effects and introduces tail risk. So much so, at the beginning of last year, the Financial Stability Board laid out a plan for living wills for CCPs. While much has been done to investigate recovery and resolution measures in the case of a failure, these entities are an avoidable source of systemic risk.

Of course, it's not just Central Counterparties that create systemic risk; payment systems suffer downtime too, as can Real Time Gross Settlement systems. The £277bn-a-day CHAPS system responsible for inter-bank payments suffered on outage, the failure of an architecturally centralised payment system with had a direct knock-on effect on consumers, as house purchases were delayed. The Bank of England is undergoing an upgrade of its RTGS system, where it plans to become compatible with innovative payment systems, such as those built using blockchain technology, designed to increase fault tolerance and remove single point of failure.

It is now the right time to explore a different market structure that increases resilience by reducing the need for, or avoiding all together, single points of failure via architectural centralisation, or single points of trust via political centralisation.


Trust is necessary in the current global financial services markets, without the technical mechanism design in place to enforce appropriate behaviour and maintain true integrity.

To reiterate the theme of evolving market infrastructure and practice, more regulation is being introduced. More recently, Mifid II, which aims to make markets more efficient, resilient and transparent.

In particular, designates that trading venues be given non-discriminatory access to the CCP of their choice. Data in the BIS trends report noted that as of 2014, 83% of CCPs were directly owned or managed by the company operating the exchange, creating group-wide political centralisation.

CCP stress tests to evaluate domino effects of entity failure are indicative that CCPs are both an architecturally centralised single point of failure and a politically centralised single point of trust. Mifid II goes some way towards mandating architectural and political decentralisation.

With all the best intentions, Mifid II will only work if it encourages competition, as per the 2001 Giovanni report.  The vertical and horizontal integration in the post-trade space results inmonopolistic behaviour where single points of trust engage in opaque fee structures and unjustly mandate lack of competition.


Central counterparties were introduced as a way to reduce transaction costs in markets. Transaction costs can be considered to include research, execution, clearing, Margin, DvP or PvP settlement, reconciliation and asset servicing.

A blockchain that performs consensus on state changes of settlement instructions and stores a local copy of the global state on each node can produce seismic efficiencies for clearing, settlement and reduces the need for reconciliation. We will cover this in more detail in further posts in the coming months. This would greatly reduce the total cost to transact for the participants in the market, without the need to create a behemoth of concentrated risk as we see today in the structure of CCPs.

Rolling back to an ownership structure that is member-owned in these systemically important operations would reduce the monopolistic behaviour that has emerged in market infrastructure and would encourage fair pricing and transparency in line with the trend in regulation towards investor protection and removal of information asymmetries.

Understandable is the desire for central banks to oversee monetary policy for issuance of fiat currency, but when it comes to providing settlement finality it comes as no surprise that many are looking to blockchain technology as a means to build a more resilient system. The Bank of England released the results of its proof of concept for the renewal of its RTGS system, in which Clearmatics' worked closely with the Bank, which we will cover in further posts.

A joint report by European Central Bank and the Bank of Japan for their project entitled Stella has also looked into this class of technologies for liquidity saving mechanisms for TARGET2 and BOJ-NET, their respective RTGS systems. They found that the certificate authority used by the particular platform could be seen as a single point of failure.

The Bank of Canada also released a report for the project Jasper, in which they concluded It may be necessary at some point to update the PFMIs to include principles outlining regulatory authorities’ requirements for structuring a DLT for a market infrastructure. Monetary Authority of Singapore’s Project Ubin compared platforms, and was also aware of the perils of a single point of failure.

Much has been said about the ability of blockchain to remove a single point of failure from a system that is by design distributed, immutable and cryptographically secured, but less has been said about the single point of trust. A centralised authority, whether politically or architecturally, is a single point of trust.

Even in an architecturally decentralised system, political centralisation reintroduces risk that the operating entity fails. This, as has been shown in the above analysis on CCPs, has led to a bloated and opaque oligopolistic systemic risk.

The opportunity to use a blockchain to improve market infrastructure in line with the regulatory trends is vast. But so are the opportunities in getting it wrong by making shortcuts in design choices.

Financial Institutions Building Towards Compliant Crypto Services

Tom Robinson, Chief Data Officer/ Co-Founder – Elliptic

The past year has seen a fundamental shift in institutional interest in cryptocurrencies. The “blockchain, not bitcoin” narrative adopted en masse by the innovation departments of banks has become less compelling, as permissioned blockchain projects struggled to maintain momentum. Then came the cryptocurrency price boom of late 2017, with the market capitalisation of all cryptocurrencies quadrupling to more than $800bn over a two month period. This generated a new level of awareness of cryptocurrencies from the general public through to sophisticated investors, many of whom began asking their brokers for exposure to this new asset class. Newly-minted crypto millionaires started to approach private wealth managers to diversify their holdings or earn income from their cryptocurrency assets. Cryptoasset funds also began to emerge, seeking institutional services such as custody. Amidst all this, cryptocurrency exchanges began to report profits dwarfing those of investment banks: earnings of $200m were announced by Binance for the first quarter of 2018.

The risk-benefit analysis of engaging with cryptocurrencies had suddenly changed. For institutions, the dangers had always been clear: that the seemingly anonymous currencies of choice for Silk Road drug vendors and cybercriminals would expose them to money laundering or terrorist fundraising risks that would be difficult or impossible to mitigate. But that is exactly what is now being achieved: institutions are overcoming these compliance challenges, spurred on by the opportunity to meet soaring client demand for cryptoasset services.

At Elliptic, we help companies to detect potential money laundering through blockchain analysis. This allows the source and destination of cryptocurrency transactions to be determined - be they legitimate services such as regulated exchanges, or criminal entities such as dark marketplaces. These techniques have become best-practice across the cryptocurrency industry, and suspicious transaction reports based on blockchain analysis by exchanges are regularly submitted to financial intelligence units - leading to convictions for money laundering and other offences.

Many of the financial institutions seeking to launch their own cryptocurrency services have approached us, to learn how they might adopt these same capabilities. This has given us unique insights into the types of services that these institutions are looking to launch, the specific challenges they have identified, and the solutions that they are putting in place.

Many banks have already been indirectly exposed to cryptocurrencies for several years. Every cryptocurrency exchange offering crypto-to-fiat trading needs to have a bank account to hold client funds. These exchanges and their banking providers are acting as the gateways into and out of cryptocurrencies and the economies that they enable, and there is a risk that they could allow the transmission of  proceeds of cybercrime into the mainstream financial system. One exchange alleged to have done exactly that was the Russia-based BTC-e, which is believed to have helped its users to cash-out hundreds of millions of dollars in cryptocurrencies that originated from theft, ransomware and other criminal activity.

This has been a major challenge for the cryptocurrency industry, as most banks have avoided these risks by simply refusing to work with exchanges. Those that are have addressed the risks by taking on the role of pseudo-regulators, and ensuring that the exchange is implementing an effective compliance program that includes customer identification, transaction monitoring and other measures.

In addition, the bank will often monitor the exchange’s cryptocurrency transactions on the blockchain, using tools and services provided by companies such as Elliptic.

This allows them to independently determine whether the exchange is preventing criminal proceeds from flowing through their platforms. Such screening isn't restricted to exchanges - banks have also used this capability to screen cryptocurrency source of funds for clients that have raised capital through ICOs.

The new products and services now being considered by institutions go beyond indirect exposure to cryptocurrencies and involve them storing, transmitting and exchanging these assets. A broad range of activities are being considered: from retail exchanges competing with market leaders such as Coinbase, to proprietary trading desks and institutional custody services. Custody is probably the most pursued opportunity, perhaps due to the institutional demand for cryptoasset storage through a “qualified” custodian. There is also perhaps greater regulatory clarity around custody, compared to the exchange of cryptoassets - some of which may or may not be securities.

Whatever the specific activity pursued by these institutions, it will almost certainly involve the receipt and transmission of cryptocurrencies, either on their own behalf or on behalf of their clients. Like any asset, cryptocurrencies can be used to transfer proceeds of crime and in order to counter this, institutions are looking to combine traditional anti-money laundering measures with the transaction analysis that transparent blockchains uniquely allow. They are proposing to use blockchain analysis to screen counterparty wallets before transacting with them, as well as to monitor and screen ongoing transactions for the ultimate source or destination of funds. This would incorporate cryptocurrency address white- and black-listing to ensure that funds are not received from, or sent to, illicit actors. These black-lists might contain addresses associated with terrorist fundraising campaigns, dark marketplaces, or sanctioned entities (OFAC has announced its intention to include cryptocurrency addresses in its SDN list). White-listed addresses might belong to clients on whom due diligence had been performed, or to other trusted institutions.

A challenge identified by many institutions, and unique to cryptoassets, is the lack of control over who mines their transactions and receives their transaction fees. In theory a miner could be a terrorist organisation or a sanctioned entity, and any payment by a regulated institution to such actors could have very negative consequences. Even if a miner could be identified as an entity to avoid, the institution would not normally be able to choose which miner added its transaction to the blockchain and therefore received the fee. One solution being considered is to only submit transactions to a subset of identified and trusted miners.

We are still in the early days of institutional engagement with cryptoassets. Business cases are being developed and risk assessments performed, but there is no guarantee that any of these services will see the light of day. Nevertheless, significant investments are being made to begin to develop the institutional infrastructure that could support the increased liquidity, greater legitimacy and more widespread adoption of cryptocurrencies. Novel anti-money laundering techniques that leverage the transparency of the blockchain are playing a key role in enabling this.

Opportunities, Challenges Remain on Blockchain Security Models

David Huseby, Security Maven – Hyperledger

The history of computer security--or more accurately the history of controlling access to digital data and resources--has remained static since the dawn of multi-user computing right through to today. Despite radical changes in technology and monumental shifts from mainframes to personal computers to mobile computers, nearly every security system we use is centralized.

It is centralized in the sense that there is a central arbiter of permissions that users must authenticate with and check with whenever they wish to log in, read a file, send a network packet, display some graphics, or any other computing action you can think of. This is precisely why blockchains (a.k.a. distributed ledgers) are considered so radical and garner so much excitement. We can now create the first widely used computing platforms with a decentralized, or distributed, security system.

This represents an entirely new way of reasoning about security and maintaining security and designing secure systems. Any change of this magnitude, however, brings with it its own set of serious challenges.

Centralized security systems most often use a design called an access control list (ACL).  The access control list contains all of the rules that define the security checks in the system: Alice has a password of “foo” and can read files that say she is the owner.  Whenever Alice logs in, she executes a security protocol that requires her to enter her password. The system checks the password and then starts a session if it matches.

Theoretically, everything is neat and tidy and in one place. More importantly, a centralized security system, like the one described, can be effectively defended. It is a citadel on top of a hill, protected by firewalls and process boundaries and the operating system kernel. The attack surface is narrow in scope and well defined. Security professionals like myself can build threat models that guide our systems and software engineering to have a high degree of in-built defenses.

But some would say that it is a flawed design because it creates concentrated, high value targets with neon signs saying, “please hack me.” The news of massive security breaches in large organizations such as the US Government Office of Personnel Management (21.5 million people affected), Equifax (145 million people affected), and Aadhaar, the digital identity system of India (1 billion people affected), all proves that, even with the theoretically simple centralized model, impenetrable security is very difficult the achieve.

A decentralized security system, such as the one used by Bitcoin, is often called the “capabilities model” of security. The fundamental idea is that all users possess a small piece of unique, unforgeable data that, when presented to a system, grants them the capability to access data or resources.

Think of it like the key to your car. You possess it, and when you stick it in the ignition and turn it, the car starts. You don’t have to call the dealer or manufacturer and identify yourself so that they will start your car for you. No, you have the key and soyou start your car. Typically capabilities are random numbers large enough that it is infeasible for someone else to guess it. But there is still a problem. If the capability is just a random number, how will the computer system recognize the capability as valid?

The answer is to use public-private key pairs as the capabilities tokens. The public keys can be shared with the nodes in a decentralized system and any requests for resources will be done by digitally signing the request with the private key. The nodes in the systems can verify the validity of the request with the public key they already possess. This is essentially how Bitcoins are transferred.

This decentralized approach represents a radical departure from the prevailing security design of the past 60 years of computing. This new model successfully breaks up the attack surface and eliminates the centralized, high-value target problem, but it creates another, far more dangerous problem of pushing all of the security into the hands of the person who possesses the private key.

In the past, the centralized systems relied only on humans to remember their passwords and the rest of the security rested with professionals protecting the central servers. With cryptography-based capabilities, nearly all of the security rests with the end user.

End user management of private keys is the greatest challenge that distributed ledgers face going forward. Most end users of blockchain applications are not security professional and are not sophisticated enough to take proper measures for securing their private keys. The current state of the art is for users to use an application called a “wallet” that is no more sophisticated than a password manager. If the user loses their master password, all of their keys are lost. If their computer dies and they don’t have backups, all of their keys are lost.

There is just no good solution yet, and so we have seen a push back towards centralization where companies provide wallet services to smooth out the user experience. This is the worst of both worlds because a centralized wallet service gathers lots of private keys in one place and again brings us back to an era of high value targets. Massive heists of cryptocurrencies soon followed.

Of the 59 major thefts of cryptocurrencies listed on the blockchain graveyard website, 68% of them were the result of a server penetration, insider, or app vulnerability. That tells me that centralizing key management to improve the user experience is probably the wrong direction to go in.

Hundreds of millions of dollars of cryptocurrencies have been stolen, but it doesn’t affect just money. Now that blockchains are being deployed in many different industries from logistics to supply chain, we’re now faced with a potentially broader impact of similar breaches. Suddenly we need to teach every factory robot, or barcode scanner, or label printer how to securely store private keys. We also have to design systems for people who care for those machines to initialize and enroll them into every distributed ledger they need to talk to.

Security has always been hard and that is unlikely to change. However, the move to a decentralized capability security model offers us an opportunity to find a solution for end users that drastically reduces the security risks to the whole system. We just need to figure out the best ways to create, store, and use cryptographic key material. I hope that soon somebody will have a “just use your finger” Steve Jobs iPhone demo type of breakthrough for key management because, if that happens, we will witness the most significant advancement is computer system security since the invention of strong cryptography.

Evolving Language: Decentralized Financial Market Infrastructure

Tim Swanson – Post Oak Labs

Beginning in late 2014 through early 2015 a small group of startups in the US and UK independently began to lay the ground work for what is often marketed as “permissioned” distributed ledgers.  Or DLT as it became known.

I am acutely aware of their journey because I wrote the key, widely cited paper that unfortunately popularized that exact term (a term first invented by Robert Sams from Clearmatics).

I say unfortunately because that DLT acronym – while well-intentioned – quickly became a gimmicky “marketing term” by many of the large consultancies around the world trying to capitalize – and frankly scare - clients into buying high-priced toys, none of which gained any meaningful traction.  Conjoined with images of a Candyland nirvana, there were (and are) a slew of “me too” vendors that flooded the market in late 2015 and early 2016 all searching for big pay days and funding from deep pocketed enterprises that had no clue as to what DLT as an acronym actually meant; subsequently some of these flash-in-the-pan ambulance chasing vendors have repivoted to doing things like an ICO or just fading away entirely.

How to visualize this?  If shrink-wrapped box packaging was still en vogue, we could imagine “Now with DLT!” brightly stamped in neon colors on the side of the latest version of some wares.

For example, some finger-pointing can be done at various software companies, though not all of them.  Lured by a number of their clients who wanted to remove reconciliation but maintain the same intermediated business model, more than a few vendors deconstructed the concept of a byzantine fault-tolerant, globally shared state capable of enabling P2P transfer of value into something arguably less meaningful: bilateral states using the same old financial intermediation to solve the double-spend problem.  In some cases it was boiled down to digitally signed message passing integrated into legacy market structure.  Useful yes, but not revolutionary.  Calling it a “distributed ledger” makes boring software products sound sexy but it ultimately confuses anyone who makes the effort to figure out what it all means.

And because there’s plenty of blame to go around: various coin maximalists religiously latched onto and dutifully created umpteen strawmen arguments using contorted disingenuous views of what DLT meant to them.  The two specific cartoonish examples that stick out the most are the horse-buggy meme and the naive “sewer rat” analogy that is occasionally regurgitated on reddit.  Why are these shortsighted?  Because at the time of their genesis, they both assumed that the only type of blockchain (or distributed ledger) that can or should exist, is the Bitcoin blockchain or derivative thereof.  It is entirely self-serving, dogmatic, and void of empirical reflection.

In all instances – big consultancies, starry-eyed startups, large software companies, and ideological zealots – they eventually butchered the acronym into an indistinguishable pile of mush.  By late 2015 as this was happening, I explained that it was basically the same thing that happened during the “no gluten” marketing mania of the early-2010s.  No one could really tell you what gluten is, but every food vendor was quick to add that their products do not have it.  A bit like cloudwashing endured too.

Due to their collective inability to manage expectations, by mid-2017 nearly the entire “DLT” ecosystem found itself in the abyss of the trough of disillusionment.  A handful never fully fell in and a couple have clawed their way out, without the aid of retail coin flippers or religious troll armies.  Others attempted quick fixes or rebrand such that they were no longer classified as a DLT company hoping that definitionally they couldn’t be in the trough of disillusionment.

A good couple books could be written on the trials and tribulations of the vendors that made the headlines during these first few years.  Eventually the DLT term has fallen out of disfavor for something only slightly less abused: “enterprise chains.”  It’s only marginally better than DLT in that it is shorter when written out and hasn’t been gentrified by VCs or demonized by coin peddlers.

But it’s not really accurate because the tools that are being built, aren’t just for use by enterprises.


This brings us to: DLT is an acronym that has served its initial use and should evolve with the times.

What then, can we use to describe the utilization of technology to re-architect organizational processes and business models?  Automating networks is generic and while accurate, is not nuanced enough.

While it would take a bit more length than this article form allows for, there are some salvageable ideas worth transplanting in the years ahead.

For starters, there is something rather mundane but simple: automating the principles for financial market infrastructures (PFMI).  As I – and others – have described elsewhere, PFMI are decades old standards by which operators (and overseers) of financial market infrastructure ought to follow; in most jurisdictions operators are legally required to follow them.  Basically a list of do’s and don’ts for running systemically important things like payment and settlement systems.   Like, how to identify risks and hold those who touch risk accountable when something goes wrong.  This is a bundle of seemingly boring but existentially important frameworks.

Which principals can be automated or should be automated?  Unfortunately, that’s beyond the scope of this short article.

What is being briefly proposed – and built – is what can be labeled “dFMI”: decentralized financial market infrastructure.

Funnily enough, FMI today is typically distributed and not fully centralized.  In the case of the EU there is a supranational payment system, but this is an exception to the rule that each developed, and most developing, country has one or more payment, clearing, and settlement system for both cash and securities.  The majority of these systems were set up and created heavy intermediation (single point of trust) due in part to technological limitations of the 1970s.  The CSDs such as DTCC and even exchange operators exist the way they do today – as systemically important institutions – partly because of an era in which mainframes and ‘minicomputers’ were the only available options.

What if we could safely and securely disintermediate market structure, reduce single points of trust, and remove monopoly rents, all while following PFMI?

It is a bold vision, but one that does not involve standing on tables saying it is the greatest thing since the invention of the internet or preying on unsophisticated retail investors in order to flog the coin-of-the day to some other retail punter.

It’s easy to be cynical towards an ecosystem that has proportionally attracted as many snake oil salesmen as the various coin groups have the past few years.  And it is hard to fulfill the promises that are hyped at events.  For example, the Sibos “New Kids on the Blockchain” video from 2015 is illustrative of those difficulties: just a couple of the panelists still work for the same company they did at the time and all of the groups represented in the video have had uphill battles to stay afloat today.

In conclusion, instead of playing identity politics with lightning bolts in a social media handle, motivated developers genuinely looking to help transform market structure can crack open a copy of the PFMI handbook and immerse themselves with a world that keeps civilization from falling apart.

Coupled with tools and libraries first conjured up within the ill-defined drama-filled blockchain world, real market structure changes can be made and society will be better off for it.  Best of all, it doesn’t need to involve burning mountains of coal to secure either.

It’s not sin to still use DLT as a term-of-art but dFMI is arguably a more expressive acronym, providing more context for both practioners and users alike.

The Future Role of Self-Sovereign Identity

Drummond Reed & Christophe Cremault– Evernym

Like all successful technology concept, Self-Sovereign Identity (SSI) will gradually permeate society, up to a saturation point when nearly all identity credentials will be held and exchanged via some technology implementing SSI. And just as gradually, consciousness of SSI will fade in the general public as its concepts are adopted ubiquitously. Today, who thinks about the concepts underlying all processors, the Von Neumann architecture, when we use our electronic devices?

But besides its likely disappearing act, what role will SSI play in 10 to 20 years? How will SII affect how we use our devices? How will SII change how we interact between us, between us and the organizations we have contact with, and between these organizations?


SSI requires computing power, network connectivity, and memory. Today, with a bit of effort, one can buy only devices with these characteristics; tomorrow one will need to look hard to find devices that do not have all these features. Cars, computers, phones, watches, locks, kitchen appliances, and more will be smart and connected by default. And will incorporate SSI. Your home will unlock automatically for your 10-year old kid, allow a 3-minute program on the microwave, disable the gas oven and the laundry appliances, notify you if the front door admits someone you cannot identify, and restrict entertainment programs to age-appropriate ones. All because all these devices know at all time precisely who is using them. SSI will allow us to have trusted relationships with our devices and trust them to do the right thing.


We interact with friends, neighbors, colleagues, acquaintances, and total strangers all the time. And we frequently need to disclose identity information to each other. You communicate your spouse birthdate to a friend who wants to give him a gift; give your personal address to your kid’s soccer coach; share some form of government-issued credential and perhaps a good-standing status from your bank to a landlord you are renting a vacation home from; the list is endless. SSI will enable all of us to share accurate, up-to-date, trustworthy information about ourselves and limit the scope of disclosure to precisely what is needed to establish a trusted relationship. For instance, in the example above the landlord may only need to know that your bank likes you, not your account information or its balance. But perhaps she wants to know you are good for a month’s worth of rent – without ever knowing the exact balance. SSI will make all this a daily reality and increase the trust we have in our relationships.


The issue of identity between individuals and organizations has become more difficult in the last century. Larger organizations, increased mobility, and larger population have made the trope of the local banker or grocer knowing his customers personally a thing of the past. When did Amazon last shake your hand?

More seriously, how does the electric company know it’s OK for you to take control of that home’s meter? With SSI, the landlord issues a credential, perhaps itself backed by the tax authorities (she pays property taxes), asserting you are the legitimate tenant at this point in time.

And it may be that only a binary piece of information, “active tenant”, may need to be disclosed.

How does the car rental company in Osaka know that your Alberta driver’s license is currently valid? With SSI, it will be a matter of seconds and will not involve any of Edmonton’s servers. And again, only the fact that the driver’s license is valid now and for the duration of the contract, for a vehicle of the category envisioned, may need to be disclosed. How can you be sure your bank is really calling you? With SSI, your bank will ping your app and offer a credential that will be immediately validated, confirming the origin of the call.

As illustrated in the examples, organizations will not only rely on SSI for identification but will also enrich their customers’ identities with trustworthy credentials, feeding a virtuous circle of adoption.

In addition, some organizations will offer to harden consumers’ identities with credentials backed by biometrics, or even DNA. This is how SSI will contribute in making account takeover, identity theft, and many fraud types, nearly disappear.

SSI will drastically reduce crime and bad actors, but more importantly will enable delightful, trusting relationships between organizations and their customers and prospects.


The identity issues between organizations are often even more difficult than when individuals are involved. After all, organizations are abstract legal constructs.


How does the bank know that Acme company is really opening a bank account? How does Big Belly Burger know that Dagetti Industries is really signing this supply contract? With SSI, a duly authorized employee will produce his a credential he owns, signed by a chain of credentials going back all the way to an incorporation credential issued by the Secretary of State. SSI will allow nearly all legal interactions between organizations that are realized via human action to be secured that way, making such relationships more trusted.


But invisibly to most of us, organizations – or rather their systems – contract with each other in real time with legal ramifications just as strong as when a human being executes a contract. For instance, APIs allow systems from several corporations to cooperate with each other and make purchases to replenish inventory, move assets across the globe, or buy futures in certain commodities.

Today, these API connections are secured with an ad-hoc series of measures that provide some level of trust but occasionally fail because of their brittle nature. For instance, API access keys expire, IP addresses change, etc.

With SSI, systems will be able to share their SSI, an identity created by the organization owning or operating the system, depending on the context. SSI will not only reduce the brittleness of such connections and simplify their management, but more importantly increase the trustworthiness of relationships between systems – and their respective organizations.

The Tokenization of Money: Design Questions Beg Answers

Antony Lewis, Director of Research – R3

Stablecoins.  Stable with respect to what?  And how does the coin achieve stability?  And what does tokenisation mean and why is a token-based lump of money more valuable than a lump of money trapped in the books of a specific bookkeeper?  Here are a few questions I always ask when we discuss "cash on ledger" or "tokenised money".


Who is the issuer?  Is the money issued by a central bank (which is in a privileged position as the only issuer who cannot technically go bankrupt in their own currency), a commercial bank (which is able to create new money up to certain limits), an e-money licensed financial institution (which needs to have a dollar in a special ring-fenced bank account for each dollar it issues to its customers) or a non-financial institution?

All money, as we know it, has an issuer who we collectively believe will make good on their promises, whatever those promises are.  And a relationship is formed between the issuer of that money and the holder of that money.

For a banknote, the deal is that the central bank will "pay the bearer on demand the sum of x" or some variation of that promise (note: banknotes are not convertible into gold, as in, you can't go to a central bank waving a banknote and ask for some gold).  For a deposit held at a commercial bank, the deal is that the bank will convert your deposit into physical cash at an ATM, or they will make a payment to someone else upon instruction from you.  For a Starbucks voucher, the deal is that you can use the voucher in Starbucks to get your caffeine or sugar hit.

What about moving money?  Does one form of money magically become another?  No.  If you deposit a banknote with your bank, then instruct your bank to top up your Starbucks wallet, although money appears to have moved, in fact what's really happened is that you've entered into agreements with specific third parties to convert between different forms of money, issued and managed by three different entities.  You gave your bank central bank money (the banknote) to your commercial bank in exchange for commercial bank money (the balance in your account), and then instructed your bank to make a payment to Starbucks' account, then Starbucks assigned you an equivalent amount of their money (the Starbucks credit).  These are all different forms of money, with different issuers and risk profiles, and different limitations on their use.


With physical cash, there is no requirement to self-identify, and transactions do not pass identity information with them.  Some consider this a feature of cash, others consider it a bug.  An identityless payment system is crucial for maintaining personal privacy, and some argue is this is net beneficial to society.

However usually with electronic money, there is a regulatory burden on the issuer to "know their customer", linking customer real-world identities with account numbers so that all payments, private or commercial, can be traced.  In some specific cases this obligation is waived, for example some pre-paid cards for public transport.  Usually these identityless cards have limits as to how much can be loaded onto each one.

What is interesting is that if the issuer can be separated from the bookeeper, as is the case with tokenised digital money, are there situations where identity is not necessary?  And is identityless money acceptible in today's environment?  And in the case where identity is necessary, who would be responsible for maintaining this: the issuer of the digital cash or the bookkeepers (perhaps themselves an aggregation of anonymous 'miners' and bookkeepers?


The value of the money or tokens will be a combination of what backs it, the trust that holders have about the issuer's claims of what backs it, and the trust that holders have about the issuer's ability to deliver on the promise of the token, so that the users can do whatever it is they need to do with it - usually that the next person will accept it.  Hence, if you don't trust that a commercial bank is sound (however you define sound), you pull your money out.  Note that trust features highly in money.

Some stablecoins are backed 1:1 by an underlying asset, whether that's gold in a vault or deposits in a commercial bank account, or even reserves at a central bank.  Holders need to truse the issuer of the stablecoins that the underlying asset exists.

Other stablecoins might operate a fractional reserve: there is not enough money to fully pay out all the tokens that are outstanding.  This is similar to our current commercial banking model; but through a system of state guarantees, strong supervision and prudent regulation, the banks keep working most of the time.

Other stablecoins are overcollateralised, locking up assets of higher value than the tokens issued are worth in total.

Yet other stablecoins are issued by automated smart contracts, attempting to act like a mini central bank, targetting price stability and issuing more coins when the price of the coins is high, and buying them back (with something else, perhaps bonds or a claim on future profits) with the price of the coins is low.


Account based money is money recorded in accounts managed by bookkeepers.  Money moves via a series of debits and credits.  Your bank balances is account based; the bookkeeper is your bank.  BTC and ETH are more or less account based (as in, the tokens are associated with accounts called addresses), and the bookkeeper is a majority group of voluntary pseudonomyous participants, some of whom are economically incentivised.  Have we seen real digital tokens in the cryptocurrency space yet?  Yes - look up David Chaum's e-cash for real tokens, by which I mean unique pieces of data that represent value.

Now where it gets interesting is when other assets are also tokenised, and we can have multiple assets participating in atomic transactions, resulting in multiple simultaneous changes to assets, whether that's the status of an asset (eg has this invoice been paid yet?) or the ownership of the asset (you now own this lump of cash).  For the first time ever if the invoice and the cash is tokenised, we can have a payment made at precisely the same time as an invoice is marked as "paid" - and both parties can acknowledge this at the same time, and without one or more third parties to transact through.

In summary, in my view, any purely digital asset that needs to cross organisational boundaries will eventually be recorded as tokens on replicated (blockchain) or distributed (eg, Corda) ledgers.  This makes sense for two reasons:

Firstly because these technologies allow multiple parties to have the same view on the status of a digital something without a third party being the golden source.  Both parties can see a live version of the digital asset.

Secondly because once an asset has been tokenised, it is freed from being under the control of a specific bookkeeper (who might only process your transaction on its own terms and when it wants eg during office hours), and the asset can move more easily, is more liquid, more useful, and therefore more valuable. You could say that tokenised assets, compared with assets held in accounts, are "alive" and "free".

Receive Diar Every Monday – The Digital Assets & Regulation Trade Publication

Something went wrong. Please check your entries and try again.


Disclaimer: Unless otherwise specified, the content of the articles published on www.diar.co constitutes intellectual property of Diar Ltd and may not be reproduced or republished in whole or in part without prior written consent. The information contained in the articles published on www.diar.co does not in any way constitute financial or investor advice and is only intended for informative purposes. Readers may not rely on such information to decide on investment or financing options or otherwise rely on such information in making decisions with monetary or financial effects. Diar Ltd does not accept any liability of any kind with regards to the validity of the information or with regards to any damage suffered as a result of reliance on such information. © 2018 Diar Ltd. Contact: newsdesk@diar.co