Swen’s Secret Super Standards of Settlement Infrastructure (SSSSSI) to Control For Oliver Cromwell Risk
Exposing the Disconnect Between DLT Buzzwords and Flawed System Design—or How Misunderstood Tokenization Increases Risk and Inefficiency
After reading the RSN proposal, I couldn’t help but question how such a fundamentally flawed system could be considered for publication. The Regulated Settlement Network (RSN) introduces systemic instability, settlement risk, and unnecessary complexity while failing to align with established legal and operational standards. Here’s why this matters.
It is, by far, the most inherently flawed proposal for a market infrastructure I have seen in my life. In fact, I would encourage SIFMA to lobby against the RSN in order to protect the market from the significant risk it would bring.
And there is a key concern here: introducing blockchain technology and tokens in name only is not only ineffective—it creates new risks. This widespread misconception includes treating wallets like accounts and tokens as replacements for book-entry settlement and saying nothing changes. This approach is flawed, and I think this is a good use case to demonstrate the problem.
So, I thought I would do what I can as a concerned citizen to explain why that is, hoping it can help others who are looking at using DLT in some shape or form for financial instruments.
How Will I Do It?
I will share three well-guarded secrets of securities and cash settlements that you must know if you want to succeed in making a useful contribution to this field, including tokenization problems.
In short: Swen’s Secret Super Standards of Settlement Infrastructure (SSSSSI)!
A Collection of Important Statements from RSN:
"Each token would relate to a single asset, would never leave the issuing RSN Member’s Partition, would never be transferred from one RSN Member to another and would be subject at all times to the control of the minting Member."
"The RSN would coordinate the debiting of the applicable tokens in the wallet held by the transferor on the applicable Member’s Partition and the crediting of corresponding tokens to the wallet held by the transferee on that Partition."
"As long as these tokens exist, they would relate to security entitlements held by a customer or participant at the RSN Member at which it has established a securities account. No token could exist separately or independently from the Partition of the institution that minted it."
"The RSN FMI would interact with the tokens solely for purposes of triggering the Members to make changes to their ledgers."
RSN cannot legally function as a securities intermediary under UCC 8 since it does not maintain accounts or hold assets, as required by Article 8 for securities. RSN’s role is best described as a technology vendor providing coordination and messaging services. But the lawyers at Sullivan & Cromwell seem to have missed that second part. They do say:
"The Article 8 rules applicable to the indirect holding system apply to ‘security entitlements’—that is, the rights and property interest of an ‘entitlement holder’ with respect to a ‘financial asset’ held through a ‘securities account’ at a ‘securities intermediary.’"
But the RSN has no accounts and does not create security entitlements for anybody. A securities transaction for a settlement at DTC then looks like this:
CSD Partition:
Burned: Tokens representing Broker-Dealer 2’s entitlement.
Minted: Tokens representing Broker-Dealer 1’s entitlement.
Broker-Dealer 2 Partition:
Burned: Tokens representing the seller’s entitlement.
Broker-Dealer 1 Partition:
Minted: Tokens representing the buyer’s entitlement.
Therefore, a separate RSN ledger is meaningless. What matters is the CSD partition. In other words, the RSN and DTC have to be the same entity to effect the outcome they describe, or everyone—including DTC—has to delegate total authority to RSN to effect changes. In other words, RSN cannot control asset movements unless it controls them, but the legal and business model tries to sit in a regulatory neverland where it controls everything but has no obligations to anyone.
I suppose this is what they mean when Sullivan & Cromwell wrote this:
"We refer to securities positions represented in a Member’s Partition and updated on Members’ ledgers to reflect transactions settled on the RSN through the use of tokens as ‘Tokenized Securities.”
And look at the tokenization model: it has no resemblance to a token. The tokens are used instead of messages today, functioning as credit/debit entries in a central database with the extra complexity that we need to derive the state by matching assets.
For example: I delivered assets identified by CUSIP ABC, while the counterparty received CUSIP 123. Resolving such mismatches requires complex lookup tables, adding unnecessary risk. I think the team behind RSN invented a new form of settlement risk that has not existed to this day in the domestic U.S. securities settlement system. That’s an extraordinary achievement.
But if you say, “Oh no, all these tokens have the same CUSIP,” well, then it’s using tokens like saying I have two different ERC20 tokens, but they represent the same asset. If you do that, then we need a new database that tells me that different system identifiers link to the same actual assets. And if we say, “Oh, that’s what RSN will do,” then I would say: they created this problem—why should we pay them to fix it? I’d rather sue them instead.
With that said, let’s dive into the first of
Swen’s Secret Super Standards of Settlement Infrastructure (SSSSSI 1):
The difference between being the account owner or the account provider determines a firm’s perspective on who can make updates to the records.
Doesn’t sound great, but I can’t think of anything better right now. I had a lovely chat with somebody from Digital Asset, and if you’re reading this, this is for you. The discussion went as follows: Would one consider a web server that adheres to a protocol (like HTML) their own system? Yes, why not. If that’s the case, why would one not consider a ledger their own system, even if it is subject to synchronized updates?
Sullivan & Cromwell seems to have a hunch there could be a problem here but then argues this should be fine:
“Because no transaction could be reflected on an RSN Member’s Partition without its specific consent, updating the same RSN Member’s Partition without further action by that RSN Member should be permissible under existing regulatory guidance (and, in fact, would ensure that the RSN Member’s records are consistent with its actual assets and liabilities).”
Hmm no that misses the point. The difference between being the account owner or account provider determines who controls updates to the records.
If I maintain the account—whether for myself or a client—I have the final say. Forcing automated updates, as RSN proposes, undermines this control.
If someone else, like DTC, maintains the account for me, I might accept automated bookings because it’s their responsibility to ensure accuracy.
However, the RSN legal analysis fails to address how this distinction plays out when client accounts are added to internal ledgers.
Currently, the U.S. securities market primarily operates on an omnibus account model, where pooled accounts at institutions like DTC simplify recordkeeping. Each broker-dealer or custodian manages client positions internally without requiring the settlement system to track individual ownership.
RSN’s proposed design effectively shifts the market from pooled accounts (omnibus accounts) to individual accounts for each end-user (segregated beneficiary accounts), because this is the basis for creating its benefits. But in the way it is proposed it’s an inbuilt instability mechanism.
No Centralized Override:
Unlike traditional centralized systems where a central authority can step in to ensure continuity, RSN is designed around decentralized, member-controlled partitions. This decentralization introduces fragility because there’s no single entity to resolve disputes or outages.
Interdependencies Amplify Risk:
RSN aims to be interoperable with systems like the Fed or CSDs, but these systems have their own rules for finality. If RSN members fail to approve updates in a timely manner, these external systems might process transactions independently, creating irreconcilable discrepancies.
Systemic Instability:
The outcome of this could potentially destabilize the entire network.
Take this example. The RSN suggests that transactions become final if all parties involved agree:
"Under the RSN Rulebook, the RSN FMI would release all the payment instructions once all the RSN Members involved in the transaction have approved the specific funds transfer (via cryptographic approval sent to the RSN FMI after the funds transfer has been proposed), after performing their compliance checks."
Ok, this drives me insane because Oliver Cromwell (which is what I like to call Sullivan & Cromwell) puts “cryptographically signed” almost every time they refer to a message, as if that is what makes something blockchain. Sending a SWIFT message is also subject to encryption, and one could also call the outcome similar to a cryptographically signed transaction, especially since they use shared ledger technology in a way that would not require a cryptographically signed transaction. It’s like sending emails via fax.
RSN must enforce a unified token lifecycle (burn, move, mint) across all participants and ensure finality rules are consistent. However, this would require significant restructuring of existing systems like DTC, which is not only highly unlikely but using a token construct to mimic today’s workflow would be inefficient as explained before.
Coming back to their statement that payments are released after compliance checks: this means the slowest party in the chain determines settlement timing. If JPMorgan sends me cash but RSN requires my AML approval, the payment is effectively pending. This adds unnecessary friction and risk to a process that is currently instantaneous and definitive as far as RTGS systems like Fedwire are concerned.
While the first standard focuses on account ownership, the second delves into the legal concept of settlement finality and its implications for RSN.
Swen’s Secret Super Standards of Settlement Infrastructure (SSSSI 2):
And this is something Oliver Cromwell brushed off and if they did so I think it sent the project off trail:
“As described above, the point of settlement finality is generally expected to be when the RSN Ledger is updated in connection with a transaction.”:
Generally expected. This is the magic word. Generally not always. Most central bank RTGS system would then be the exception not the standard. There are probably fewer central banks than banks so from this perspective one could say Oliver Cromwell made only a small error in not explaining this better.
SSSSSI 2: Settlement Finality is a legal concept at the FMI level and is not always identical with ledger states or updates to such states.
So for instance, when there is an outage by a Fed Member, the rules state
“Payment under this section 5 is final and irrevocable regardless of whether the Reserve Banks can effect related accounting entries in the Master Accounts [..]. The Reserve Banks will endeavor to make all such accounting entries to Protracted Outage Participants’ (and Issuers’) Master Accounts before the next Fedwire Funds Service Funds Transfer Business Day but have no obligation to do so.”
Every FMI will be required to define their moment of finality today, and these are partly legal fictions and thus not identical across the involved systems. The Fed will not wait for RSN to make a payment final. And what would happen if one participant were to cancel this pending instruction in RSN? Nothing, because it has no relevance unless the Fed were to delegate operations of Fedwire to RSN. And how likely is that?
And this brings me to my third of
Swen’s Secret Super Standards of Settlement Infrastructure (SSSSI 3):
RSN’s design allows unilateral cancellation (e.g., if you don’t have sufficient securities). This makes the system itself unreliable and creates an incentive to avoid settlement fails in the system by simply deleting the settlement obligation. A simple way to put it: Kicking the can down the road is not a good design principle for settlement infrastructure.
“The requirement of transaction-specific approvals for orderly settlement is context-specific and not absolute.”
In traditional securities systems, it is often preferred to subject a cancellation to counterparty approval, creating an orderly and predictable process. This approach undermines trust and creates systemic instability, where transactions can fail, and the system is not the place to manage it. Participants would instead have to rely on off-system resolution.
The Principles for Financial Market Infrastructures (PFMI) outline 12 standards for ensuring stable and efficient settlement systems. I manage with just three. That’s German efficiency for you.