The Seven Deadly Sins of Finance

Building a better financial architecture in institutional crypto

Nearly fourteen years on since the Bitcoin whitepaper, and the earlier work by Haber and Stornetta, I think it’s still not fully understood why blockchains and otherdecentralized ledgers (DLT’s) are such a big deal for finance, and this probably has something to do with a lack of general appreciation for the many shortcomings in the infrastructure underpinning global finance, and how it helps solve them. The origins of cryptocurrency as a currency mechanism make this harder, because the mental model for many people outside the space is still based on payment mechanisms, when the core innovation is about accounting and settlement — which is related to payments, but more fundamental, deeper down the stack if you will.

If you crack open any financial architecture — whether the systems underpinning a bank, or the broader operating model and standards — you will stumble upon a host of sins that make the systems expensive to operate reliably. Heroic amounts of effort and billions of dollars a year per bank goes into making this work well and scale, because it’s an uphill battle. Without understanding this, you might just look at blockchains and said they are just a wildly inefficient distributed database, rather than a potential hugely impactful charge for finance.

Let’s start by accounting for our sins.

The Seven Deadly Sins

1. Ambiguity about ownership

Bearer instruments like physical cash or a barrel of oil settle when their holders change. While this can lead to a host of complications like storage costs, risk of physical loss, leakage or damage, etc., asset transfer is unambiguous, and it’s really just down to whether the transfer was compelled and with inadequate or zero compensation, or fair. While settlement can be a separate process and thus could fail, generally speaking either your barrel of oil shows up or it doesn’t, and if it doesn’t, it’s likely in someone else’s driveway rather than nowhere. Somebody holds it.

Financial contracts like, for instance, derivatives, or a repo, or even just a sale of stock, is not like this. For instance, you absolutely can fail to deliver stock that you had borrowed or short a stock you don’t own, and there are rules and controls to deal with these cases. In the early 2000’s the OTC derivatives market novation process, whereby contracts are reassigned from one dealer to another, resembled a massive game of musical chairs with significant doubt about what would happen when the music stopped. More broadly, there are also plenty of instances in the economy where records of who owns what — like land titles — are incomplete, contradictory or theoretically knowable if you walk over to a courthouse and start opening cabinets but practically hard to determine.

Sin #1: it’s not always clear who is the owner.

2. Ambiguity about provenance

Financial provenance, like the same idea in the art world, is incredibly important, because while a dollar might be fungible, not every source of funds is equally legitimate. The funds might come from corruption, criminal activity, or a sanctioned individual’s personal bank account. Thus the history of who owned that asset matters, and you need clarity both about the “who” — think corporate registries and requirements to know Ultimate Beneficial Owners (UBO’s) which help peer through layers of shell companies — and the sequence of transfers that preceded the present transaction. Otherwise you could be helping someone launder money or whisk away the proceeds of corruption, or you might be funding some undesirable activity like terrorism or the war efforts of a nation state under sanctions.

Sin #2: it’s not always clear where the asset came from.

3. Multiple authorities

The above problems are compounded by the fact that everybody has their own databases with the relevant information needed to make the system work. Actually, it’s worse than that: everyone has lots of databases, serving various parts of their enterprises, all of which have overlapping copies of that same information. Dual-entry would be a blessing: often the same information is captured dozens of times in the bowels of IT systems at every party to the transaction, plus regulators, exchanges, clearinghouses and other monitoring parties for good measure.

People in IT like to talk about “golden sources” of information.

There is no such thing.

Sin #3: everyone keeps and updates their own records of who owns what; descriptions of the assets (i.e. reference data); the transaction history; and who is who.

4. Reconciliation

If you live in a world where it’s critically important to know who owns what and where it came from and this information is fragmented and duplicated, what do you do? You spread all the copies on the table side-by-side and check for discrepancies. This can be automated or manual or a mix, but the fundamental operation is the same: you show me yours and I’ll show you mine, and we then identify all the breaks. This takes armies of people, and for data that is unstructured (or worse, not digitized) you need even more eyeballs on the problem. And because of sin #3, that we have many potential authorities, it’s not a two-way reconciliation, but a multi-way reconciliation. If three parties think the option strike price is $52, and two think it’s $51, do we go by majority rule? Do we weight the opinions of some more than others?

Sin #4: everyone spends a lot of time comparing their records with everyone else’s.

5. Settlement failures

OK, so now we have some decent common understanding of who owns what, what those things are, who is who and where things came from. Done, right? No! Because now that we’ve agreed to move the asset from Point A to Point B via a process that does not instantaneously settle and update the records at the same time, we have to allow for the possibility that a cashflow we were expecting or a stock due to be delivered never shows up. We have to reserve capital to cover these errors; we need to report them to regulators in some cases; and most of all we need even more people in the Operations settlements team to stay on top of this, make inquiries as to where that lost lot of Apple stock has gotten to, and — the best part — every once in a while something truly horrible happens in the market, and the doubts about whether that promised delivery will ever show up start to affect market sentiment. In the face of a market meltdown, a payment error and the inability to pay — because you are insolvent — look exactly the same to panicked market participants. The music stops, and somebody tries to take a chair that is not there.

Sin #5: even when we know who should own it, we sometimes still don’t get it.

6. Identity

Resolving questions around provenance require clarity about the identity of individuals and corporate entities around the world. As the owner of one of many independent ledgers, you have legal obligations (KYC/KYB) to know who you are dealing with before you update your ledger to reflect an asset movement. Unfortunately this is not so easy. You not only get fragility points like incomplete addresses and misspelled names, possibly in many different languages, but you also now are dealing with sensitive data, and everybody is shuttling it around and comparing it. The more personally identifiable data points in the mix, the more damage that could be done in the event of a hack. So let’s not just dial up the budget for Operations to pay for all those people running reconciliations, let’s also add hundreds of millions of dollars to the IT Security budget. Oh, and did we mention you need to reconcile this sensitive information with your counterparties?

Sin #6: we need to know way too much about everybody in order to make this all work.

7. Trust

Very few institutions can be entrusted with the responsibility or have adequate resources to deal with the above complexities, so we need to identify who we trust and then delegate a lot of authority to them to do all these things, and then we need to very closely monitor and supervise them and if necessary penalize them in case they screw up, which they will, because this is a giant, smelly hairball. After many years on Wall Street, I don’t think the banks get enough credit for dealing with the impossible task put before them, but I also understand a lot of the deep resentment expressed by Occupy Wall Street because sitting at the crossroads of the economy is a great way to scoop up dollars as they flow past, and if it goes wrong, this central importance means too big to fail institutions will get bailed out to protect others.

Sin #7: establishing trust means granting large, fallible central parties excessive power.

Of course, one of the great tragedies of 2022 was it showed that “institutional crypto” had managed to replicate pretty much every single one of these sins, only without regulatory oversight or adequate resources to defend against the failures. The old world’s operational costs and risks came along for the ride.

A better way

The point of all this is not to make you feel sorry for the banks and other financial institutions, but rather to establish why disconnected, centralized ledgers are such an incredible pain point for them. I also think the institutional crypto industry needs to think about whether it has an opportunity to pilot a better financial architecture founded upon the technologies behind the assets they are trading. To this end, let’s look at the notable attributes of a decentralized ledger, which comes about from fusing settlement and ledger updates into a single operation, without a trusted central party, in parallel to The Seven Deadly Sins:

1. Digital assets are bearer assets

This is a dimension of the whole “Bitcoin is digital gold” idea — whatever you think about that as an investment thesis, what is true is that tokenized assets behave a lot like traditional bearer assets. If you have the keys to a wallet, you can sign transactions and effect a transaction that moves the asset from your wallet to another wallet, and by so doing, you simultaneously update the records of who owns what.

Note that digital assets do not have to have digital underliers. The asset might be intangible like a stock or bond or IP rights, or it might represent all or part of the ownership of a tangible thing like a warehouse. What the digital twin points to in the physical world can be captured in the record as metadata, e.g. for a land title the exact property lines. So long as there is a legal basis for accepting that a transfer in ownership of the digital assets applies to the physical object and that this right can be enforced in the courts, it’s enough. In technical terms, a digital asset is an asset pointer. It might point to a unit of cryptocurrency or a house, but the idea is the same.

2. The blockchain is an immutable record of provenance

If all the ledger did was reliably record who owns what at the present moment, this would already help a great deal. But wait! There’s more! Because the blockchain has the full history of transactions, you also get provenance. You know everyone who has ever owned that asset, whether a celebrity who briefly had that NFT or a sanctioned businessperson. This requires secure means of linking accounts to identities, covered below, but it vastly simplifies the problem if we have a reliable record of transfers.

3. Everyone can refer to a single source of truth

By its very nature, a shared ledger updated via consensus can serve as a single source of truth. You don’t need to make copies, you just have to look at the blockchain. While it is impractical at least for now to have a single global ledger for absolutely everything, it’s definitely possible for all participants in a business process to agree to share a single decentralized ledger, whether private or public, and then refer to it. For the first time, the idea of a golden source has meaning: if it’s on-chain, it’s golden; if it’s a copy offline, it’s not.

4. Reconciliation is minimal (but not zero)

That last point about “a copy offline” might have raised an eyebrow. Why would you have such a thing? Isn’t this going to demand reconciliation and lead to conflicts all over again? This is most likely to come up in contexts where the query performance of the blockchain is unacceptable for a particular use case: caches, denormalized database tables, data lakes allowing joins across multiple sources, some of them not on-chain, could all demand other copies. Ideally these copies should always be disposable derivatives of the chain: you could blow them away, rebuild from source and be back in safe territory. But … what if there’s a bug in the code that builds these “views” of blockchain data? What if some legacy process requires us to actually amend information in what should be a one-way copy? This will likely lead to at least some reconciliation still being required. Related, where a digital asset is a digital twin of a real-world asset that has its own off-chain databases, any on-chain metadata that isn’t just a pointer back to a golden registry of information about those assets is going to have to be compared and reconciled.

5. Settlement is atomic

This is the heart of the innovation: settlement and changing the ledger always go together, and these changes are indisputable and irreversible. Just as with the barrel of oil, it’s either in your possession or it’s not. By combining these operations, you ensure that failed transactions just “roll back” to the old state, and neither possession nor the ledger change. There is no possibility of settlement fails if settlement and the ledger update are combined, especially if the promise to deliver is itself encoded in a smart contract, e.g. the logic to deliver interest payments to bond holders. The most that can happen is something you actually really do what to see and in fact make blindingly obvious: insolvency. If the funds are just not there to make the payment, this should be apparent to all parties. Ideally you would not only effect the asset transfers on chain, but you would encode all payment obligations on-chain. The amount to deliver might be uncertain — think the floating leg of a fixed-float swap — but the fact that a payment is due on that particular day from account A to B and the economic details about what oracle or other calculation agent will be consulted can absolutely be recorded on-chain and modeled to assess counterparty risk.

When the asset ownership and the liabilities are all on-chain, you have eyes on both sides of the balance sheet. For a credit risk department and collateral management, this would be transformational. It implies the need for privacy-preserving technologies in many instances, something I am covering as part of a related series of posts here, but the concept that you could reliably know the web of obligations and the assets that support them is massive and would give you not only operational leverage from reduced costs, but would liberate capital currently placed in reserve based on uncertainty about the counterparty’s ability to deliver on their promises.

6. Identity is pseudonymous

In a blockchain-based architecture, the wallet address is all you know about the sources and destinations of funds. As this is not linked to a person or a corporate registry by the infrastructure, you have pseudonymity rather than known identity or anonymity: you know it’s the same party you sent funds to yesterday, but nothing else. However, the fact that the wallet can bear any kind of token means it can bear NFT’s that encode either references to identities off-chain or some identifying information, possibly concealed with privacy-preserving technology. Furthermore, cryptographic mechanisms like digital signatures mean these identities can bear attestations by other parties like government agencies or auditors, and you can also link zero-knowledge proofs verifying statements about the identity. This lets you get away from central parties knowing many personally identifiable attributes of a party: you can move toward establishing that requirements have been met in a verifiable way. You don’t need to know my home address and citizenship; you just need to know I don’t live in a sanctioned location. You don’t need to know my income and bank balance; you just need to know I am an accredited investor.

Most business logic thus can operate on pseudonyms without ever lifting the covers on the identity of the actual party. This means there is less that can be stolen or leaked, and will make for a structurally safer system from a privacy perspective.

7. Trust is constrained

Blockchains are designed to operate in environments where you cannot assume that participants have good intentions: they might try to steal assets, take control of the system or otherwise subvert it. By stripping away the expectation of trustworthiness, this allows anyone to participate in the network, knowing that the consensus mechanism and other controls will weed out bad actors. This allows everyone to share state without necessarily needing to pick a central database owner that all participants are willing to trust — something even more challenging to do in a multinational setting. A technology that did not have this final attribute would be very hard to deploy globally and be adopted widely enough to be useful, so while a lot of people who are passionate about crypto put a lot of weight on this aspect of the system, from the perspective of designing a better financial architecture it’s just the thing that gives you critical mass. You’re no longer talking about all sharing Galaxy Digital’s database, or the SWIFT network; you’re just agreeing on protocols and data formats, which while still complex, is far easier than getting international political agreement or agreement among competitors.

Where to begin?

I would like to wrap up with a call to action. While institutional crypto is still small, it is sufficiently large and complex enough to merit many of the same controls as traditional finance. The challenge and the call is to implement those controls in a way that is an order of magnitude better than the traditional system: to learn the lessons of traditional finance’s operational problems and create a superior solution, inspired by the technologies that are an integral part of crypto infrastructure. This is going to require cooperation between the trading desks, market makers, prime brokers and asset managers that really has no precedent: the various standards committees, self-regulatory organizations, accounting bodies and other industry forums that have helped traditional finance work through similar problems barely exist. It means grappling with unsexy topics like symbologies, registries, messaging and data formats as well as working out the rules of the road and expectations of good operators in the space. But if this can be done within this nascent industry, the lessons learned could be the basis for a much larger revolution in finance, and those who engaged with it early would be uniquely positioned to both drive standards and operate more efficiently than their competitors.