We enjoyed the clarity of the DTCC’s thoughts on Security Token Platforms and the underlying blockchain platforms on which tokens are recorded. Their guidance aligns with our thinking and the design of Corda. This short post provides highlights, and our commentary.
The digital assets market has had a few weeks to digest the DTCC’s whitepaper — and at R3 we are very much aligned with the important conclusions of the paper.
Let’s be clear — this is not a piece discussing whether a particular token is a security or not: that is the purview of the appropriate financial regulator. This was discussing principles for the post-trade processing of financial securities recorded as tokens on blockchains.
So, given that a token in question is a financial security, how should it be treated? And what should you care about if you’re part of the Token Market Infrastructure (TMI)?
Who is TMI? It is Financial Market Infrastructure (FMI), for tokens. Today, the entire TMI is being built out, with tools and platforms for investors (who want to hold the assets), issuers (companies who issue financial security tokens to raise funds for projects and initiatives), and the intermediaries and infrastructure that supports these activities (advisors, asset issuance platforms, exchanges, custody solutions, etc).
We are all TMI.
So what does the DTCC, arguably one of the most successful financial services infrastructure operators in the world, think about tokens? Especially how they are recorded and managed?
We’ve picked out some important and relevant points.
“Existing regulations applicable to the post-trade processing of traditional securities should be applicable to the post-trade processing of tokenized securities. In some cases those existing regulations might not squarely apply.”
Clearly, something is new here. Existing regulations work for existing technologies, but now we have the ability to control assets using digital signatures, and hold these assets digitally, and have guaranteed bilateral and multilateral automation to improve the way we transact and manage assets.
But with new technologies come new risks:
“… those developing policy should determine the legal and other requirements applicable to a Security Token Platform based on the functions it performs and the risks it poses. These risks include custody risk, principal risk, and operational risk.”
Private keys — short strings of text — are crucial to the ability to transact — especially for cryptocurrencies on public blockchains where there is no recourse. For tokens issued by issuers, there may be ways to cancel tokens and re-issue them to parties who have lost private keys. So risks that an investor or a trusted custodian has a private key copied or lost, needs to be managed. This means new operational processes, technologies, and solutions.
Where can we seek inspiration?
“Regulatory principles developed by international standard setting bodies, such as the “Principles for financial market infrastructures,” or PFMIs, can serve as useful guidance.”
“DTCC believes that a Security Token Platform will not attract institutional investors unless these requirements are adequately met.”
Much of the paper is about whether security tokens should be recorded on permissionless networks (eg Bitcoin, Ethereum, EOS, etc) or permissioned networks (eg Corda).
“Because the identities of their users and contributors are unknown, users have not been qualified through any type of anti-money laundering, know-your-customer, or OFAC process.”
This isn’t about the holders of tokens: it is relatively easy to restrict holders to a pre-vetted whitelist of participants, and various token standards are emerging that allow whitelisting in the smart contracts governing what the tokens can and can’t do.
This is regarding who can write to the ledger, and who is paid a fee for doing so. On a permissionless blockchain network, your transaction can be recorded by a pseudonymous actor in a sanctioned country, and you will be paying them a fee to do so. Are you ready to do business with sanctioned actors, even accidentally? Are you also willing to give up control over the recording of transactions to a group of parties who have not committed to any service level agreements, who you can’t sue if things go wrong, and to whom you have no recourse?
“A permissioned network allows for a centralized governance structure and enables assignment of responsibilities to a network operator. Decision-making may be more centralized for certain aspects of the network and more distributed for other aspects.”
Using a permissioned network seems to be the best approach that allows for the benefits of tokens (assured multilateral automation, frictionless transactions) without the uncertainties of using public permissionless networks.
“DTCC believes any platform that provides post-trade processing of security tokens should bear the following post-trade responsibilities. DTCC believes that these responsibilities are also applicable or highly relevant to most crypto assets. These responsibilities derive from specific, relevant international standards as well as specific regulatory requirements in the U.S. and elsewhere:
· Demonstrable Legal Basis
· Identifiable Governance Structure
· Identifiable Risk Management Procedures and Systems
· Identifiable Procedures and Systems to Ensure Settlement Finality
· Security Token Issuance, Custody and Asset Servicing
· Recordkeeping Requirements”
“Because a node on the permissionless network could be located anywhere in the world, the degree to which the governing law would be enforceable may need complex legal logic covering every regional policy to be built into every smart contract and depend on the location of the nodes. For example, even when the Security Token Platform utilizing a permissionless network is governed by the laws of a particular jurisdiction, if a majority of the nodes are located in jurisdictions that would not recognize such laws (or, even more fundamentally, the legal effect of transactions processed on such platform), the platform effectively would not be governed by the law the parties had agreed to.”
“… in a Security Token Platform utilizing a permissioned network, the legal risk associated with foreign parties can be flagged and mitigated in advance.”
In a permissioned network, well-governed business (sub)networks can be created that align with specific legal jurisdictions, allowing for the benefits of tokenised assets while still maintaining a strong legal basis.
“And on a Security Token Platform utilizing a permissionless network, it is not clear the degree to which node operators have legal obligations to other platform participants, such as a duty to continue platform operations or attempt to remedy (or not exploit) discovered platform vulnerabilities.”
Permissionless networks are anarchic and ungovernable by design — that’s how you make an unstoppable world computer. That is their strength, but also makes them inappropriate for financial securities which operate within governed frameworks.
“Additionally, if a Security Token Platform assumes a critical role in effecting securities transactions as well as custody and asset servicing, the question arises as to whether the platform should have in place adequate measures to address possible unavailability or discontinuance of its activities. The nature of these measures would depend on the structure and operations of the particular platform. For example, it is unclear whether the costs of a Security Token Platform configured to leverage a permissionless blockchain would or should include the operation of the permissionless network, which it does not control.”
It is a scary prospect to rely on a permissionless network with fees determined by a market rate, and who you have no recourse to if the network becomes unavailable.
“It is important to financial markets that transactions be considered “final” at some point in time, to ensure they cannot be unwound. Because settlement finality means a transaction cannot be unwound, the point at which settlement becomes final is determined by both the rules of the market (operational finality) and the governing legal framework in the relevant jurisdiction (legal finality).”
One of the principles from the PFMIs is that of finality — the point in time where a token has changed owner, and crucial in the case of a bankruptcy. We have long argued that the “longest chain rule” consensus mechanism of public blockchains do not give finality to a transaction — instead, participants agree that some number of blocks (which changes depending on network activity) is “good enough”. This isn’t good enough.
“It is an open question who would be responsible for the functions automated by a smart contract, particularly if something goes wrong or there is a change in circumstances necessitating a change to the smart contract, and what would be the legal and regulatory status of such person. To the extent that certain asset servicing functions could not be automated by smart contract, such functions would need to be performed by persons with the appropriate legal and regulatory status to do so, but how such persons would interact with the Security Token Platform, especially in a permissionless network, is unclear.”
Smart contracts are crucial — they define how an asset can behave. We believe that smart contracts should be written in well-known and understood coding languages such as Java.
“Therefore, in addition to a risk management framework, it would be prudent for a Security Token Platform to have a business continuity plan in the event of a wide-scale or major disruption.”
And what if the underlying blockchain, where the assets are recorded, were to have an event — say, chain choke from a popular or viral game? In early 2018, pending (unconfirmed) transactions on Ethereum increased sixfold due to Cryptokitties and drove transaction prices up 100x according to some sources.
“A Security Token Platform should demonstrate how it manages the privacy and confidentiality of appropriate records, particularly records that contain users’ personal or proprietary information, while maintaining their accessibility to regulators and appropriate third parties such as external auditors.”
Ah, the privacy vs transparency chestnut. Corda’s design deliberately avoided the “broadcast all the transactions” design of permissionless blockchains in favour of peer-to-peer “need to know” data transmission. This gives Corda the flexibility to send data to the right parties, at the right time.
“Using the post-trade processing responsibilities of today’s FMIs as a guide, such responsibilities for Security Token Platforms should be promulgated in appropriate rules and regulations, assigned to an entity providing post-trade processing services — whether or not it is vertically integrated into the trading platform — and credibly enforced. Otherwise, a Security Token Platform cannot operate in a manner consistent with the public interest.”
Corda was designed so that identified parties can build permissioned business networks to issue, transfer and manage the lifecycle of digital assets. The goals and capabilities that DTCC is recommending are aligned with the very same design inputs that have informed the design of Corda from the start.
It now seems that the crypto industry is starting to understand the benefits of Corda’s design.
If you are involved in building the token market infrastructure or creating a securities token platform, contact email@example.com and we’d love to chat about how we can support your business.
Reflections on DTCC’s Guiding Principles for Post-Trade Processing of Tokenized Securities was originally published in R3 Publication on Medium, where people are continuing the conversation by highlighting and responding to this story.
Sign up for our newsletter to receive the latest R3 news, updates, and materials