Reviewing the Regulated Settlement Network (RSN) - Part 2
Breaking Down the Technical Gaps and Redundancies in the RSN Proposal
After sharing some initial views on the regulated settlement network (RSN) proposal, I want to provide more thoughts after reading their technical report, focusing on their first use case: a simple OTC DvP settlement for a bond.
Interestingly, the use case section has a curious footnote:
"The use cases and assumptions defined below do not necessarily reflect the views of the Federal Reserve Bank of New York or any other parts of the Federal Reserve System, including with respect to the Federal Reserve’s legal authority to participate in RSN or any similar arrangement."
I find it surprising, given that the report already states on its very first page:
"The content of this report, including any potential regulatory or supervisory frameworks for the RSN, and the Federal Reserve’s legal authority to participate in RSN or any similar arrangement, does not necessarily reflect the views of the Federal Reserve Bank of New York or any other parts of the Federal Reserve System."
Why would the Fed ask to highlight this—assuming that’s what happened? It also raises the question: if the Fed was skeptical enough to demand repeated disclaimers, why didn’t they press for improvements to the use cases? Perhaps this could be explained by the specific function involved. According to the report:
"The New York Innovation Center (NYIC) at the Federal Reserve Bank of New York served as a technical observer in this PoC to gain knowledge on the use of shared ledger technology as infrastructure to conduct transfers between regulated financial institutions. The NYIC was focused on observing the participants’ research and experimentation with tokenized settlement assets."
This framing suggests that the NYIC’s role was intentionally limited to technical observation, leaving the crafting and evaluation of use cases entirely to the project participants. If the Fed saw itself as a passive observer rather than an active collaborator, it’s perhaps unsurprising that they opted for repeated disclaimers. Besides, I don’t blame them after reading the report.
Even before getting to the use case, the document makes rather unsophisticated statements and presents them as critical design choices:
"To support the composability of applications and functionality, a key requirement was to ensure that the privacy requirements of one use case did not infringe upon another, even when both are processed within the same transaction."
Wait—what? Two use cases within the same transaction? How can there be multiple use cases in an OTC settlement?
The report attempts to clarify:
"For instance, in the context of performing central clearing and netting functions, the FMI did not need to have visibility into the ongoing net positions of all participants or the specific actions that the central counterparty might take to address a failed delivery. The RSN FMI only needed to be aware of the net assets and amounts that required settlement at the conclusion of a netting window."
So, in other words, the RSN isn't providing central clearing but rather settlement services. It would simply receive settlement instructions from the CCP. This shouldn’t come as a surprise since regulators typically don’t want the principal risk-taking activities of a CCP housed in the same entity as the more operationally focused CSD.
But here’s the obvious fact: the clearing activity is not the same transaction as the settlement process. So why is the RSN discussing functionality to "avoid awareness of things it shouldn’t know" when clearing operates entirely outside its scope? If the RSN isn’t providing central clearing, what purpose is served by declaring a need to avoid visibility into processes it has no involvement with?
“This linkage ensures atomicity between the movement of deposits and assets, providing simultaneous settlement and removing risk of partial settlement.”
Why would they think that? Partial settlement is typically not understood as one party delivering their part while the other doesn’t. Settlement-related counterparty risk is managed through DvP processes, which ensure that delivery and payment are linked. However, DvP processes can still allow for partial settlements, which are designed to reduce the financial impact of settlement fails. This report adopts a very unusual and seemingly misguided interpretation of partial settlement.
Then they present a Bond DvP Settlement Sequence Diagram. There’s nothing in the described process that requires DLT. A centralized database or mainframe could implement the same flowchart. From their description, the RSN doesn’t utilize core DLT features like trustless validation, consensus, or immutable audit trails. Instead, it reverts to traditional workflows that could just as easily run on legacy systems.
DLT typically enables one-sided instructions. In most DLT systems, a single party initiates a transaction, which is validated and confirmed through consensus. This eliminates the need for reciprocal, manually synchronized instructions like RvP (Receive versus Payment). The RSN insists on RvP, which is unnecessary in a well-designed DLT system and it would be interesting to discuss this option even if it seems counterintuitive initially.
However, their process raises more than a few eyebrows. For securities settlement:
One counterparty must submit a Delivery vs Payment (DvP) instruction.
The other counterparty must submit a Receive vs Payment (RvP) instruction.
If both banks (in their example) submit DvP, the transaction would fail because the system wouldn’t know which party is delivering and which is receiving. So it should be a DvP and RvP instruction respectively. Perhaps this is what they mean.
They claim that "the initiation of the settlement process is encoded within the Daml smart contracts." This suggests that the contract is automating the process—but is it really?
Daml waits for both trading parties to confirm their respective DvP/RvP proposals.
Once confirmation is received, Daml initiates the settlement process.
But why confirm again? If the trade is already matched in DTC and both parties have agreed to it, why is RSN asking for another confirmation? RSN seems to reintroduce manual or redundant confirmation steps, unnecessarily delaying settlement.
The description of the smart contract in this process is baffling:
The trade is matched in DTC.
RSN runs its own matching process on the same trade.
The smart contract waits for confirmations from both parties (again).
After this second confirmation, RSN declares the trade settled.
If a transaction is rejected and there’s no mechanism for resolution in the documentation provided:
The process breaks down. The transaction could be stuck in an endless loop or canceled indefinitely without resolution.
No visibility into issues. Without clear feedback or structured exception-handling workflows, participants wouldn’t know why a transaction failed, let alone how to fix it. This undermines the supposed efficiency and transparency benefits of the RSN.
Real-world problems escalate. In the real world, mismatches or disagreements are resolved through exception management workflows. The RSN appears to lack these entirely, leaving participants stranded.
If the system cannot handle disagreements beyond simply canceling transactions, it’s fundamentally flawed.
And the instruction flow is surprising. There are two banks wishing to settle a trade. If Bank A and Bank B have already submitted instructions to DTC, those instructions already contain all the necessary information (security CUSIP, amount, counterparties, settlement date, etc.). There’s nothing additional for the RSN to add—yet it creates additional settlement instructions to DTC. But who or what are they instructing?
There are no third accounts: DTC directly processes Bank A’s instruction to debit its account and credit Bank B’s account.
There’s no third account belonging to DTC that requires coordination.
DTC doesn’t need another instruction because it already processes Bank A and Bank B’s original instructions directly.
How would RSN be informed about SSI information and the respective account structure at DTC, and for what purpose?
The described process is such an oversimplification of what actually happens, it doesn’t seem to add any relevant functionality that address any problem and instead creates redundant process steps in an otherwise highly STP (Straight-Through Processing) process activities.
I really don’t get it.
Respectfully, I think you're missing the forest through the trees here. A couple of points:
- A DLT-adjacent technology was likely a political prereq from higher-ups to do something in digital assets even if you could, in theory, design the system on a traditional database setup
- A DLT-adjacent technology is also helpful from the perspective of onboarding other types of assets (bonds, repos, whatever). DAML is a built-out language that exists, even if, from a performance standpoint, they might need to move somewhere else for a production launch
- The Fed put those disclaimers in to stop the idiots who fearmonger about the most banal of technologies in wCBDC because they see a big scary acronym they saw on Twitter (also why CBDC is considered out of scope despite central bank reserves being functionally the same thing for the purposes of this POC)
- There is zero chance the market will accept an actual web3/decentralized solution (and for good reason since that would be 100x more difficult a political sell and arguably would never truly graft appropriately in a fully regulated environment) - they'll recreate the current system with DTCC/Fed and co, and eventually pare down the intermediaries in the system piece by piece if its successful
- The lack of automation is because it's a POC, an actual implementation would be way more automated, and parties like the CCP and CSD would almost certainly be directly onboarded (in addition to the banks themselves having their own partition)
I think you're underrating how much of a culture shift this potentially still represents in tokenization for banks/traditional institutions even if they are still learning to walk here