This is an on-going work on the Requirements Working Group
Delivery versus payment, or DVP, is a common form of settlement for securities. The process involves the simultaneous delivery of all documents necessary to give effect to a transfer of securities in exchange for the receipt of the stipulated payment amount. Alternatively, it may involve transfers of two securities in such a way as to ensure that delivery of one security occurs if and only if the corresponding delivery of the other security occurs. This is done to avoid settlement risk such as where one party fails to deliver the security when the other party has already delivered the cash when settling a securities trade.
During the settlement process, obligations incurred during the trading process are met. Specifically, the physical delivery and/or book-keeping transfers of securities and of cash agreed to during trading occurs.
In this example, Alice and Bob have previously agreed to trade securities for cash. They have agreed to settle the trade via DvP on the ledger. They have put these items of value—the securities and the cash—onto the ledger through Trent, a mutually-trusted third-party custodian
User | As a . . . | Wants to . . . | Because . . . |
---|---|---|---|
Alice | Seller of Securities | Sell securities for cash in a contingent all-or-nothing exchange | She wants to minimize the risk that she delivers the agreed-upon securities into Bob's account but he fails to transfer the agreed-upon cash into her account |
Bob | Buyer of Securities | Buy securities with cash in a contingent all-or-nothing exchange | He wants to minimize the risk that he pays the agreed-upon cash into Alice's account but she fails to deliver the agreed-upon securities into his account |
Trent | Custodian of Cash and Securities | Provide all-or-nothing exchange of securities and cash if and only if matching delivery and payment instructions are received | Alice and Bob need a trusted third party to act as a settlement intermediary to minimize Alice's cash payment risk and Bob's securities delivery risk |
In order to clarify the business process scope of the DvP use case, the following table outlines select stages of the lifecycle of a securities trade. Some or all of the prior stages to Post Trade - Settlement - DvP are assumed to have already taken place in the trade lifecycle ahead of the start of the DvP use case. To be clear, then, this use case does not cover all aspects of Post Trade, of which there are many.
Process Hierarchy | Notes | ||
---|---|---|---|
L1 | L2 | L3 | |
Pre-Trade | |||
Trade | This is the step in which the (contra) parties agree to exchange securities for currency. The agreement is known as the trade. | ||
Post-Trade | Clearing | Aggregating, netting and batching may take place at this stage. If no aggregating, netting and/or batching is occurring ahead of the settlement step, then it is considered Real-Time Gross Settlement (RTGS). | |
Settlement | DvP | During the settlement step, physical delivery and/or book-keeping transfers of the securities and of the cash agreed to during the trade step. Delivery (of the securities) free of payment (DfP) is an alternative settlement mechanism to DvP. Securities are delivered in settlement of a trade without dependency upon the corresponding payment. As such, DfP has a different risk profile for parties to the trade than DvP. |
Each DvP has two legs. Each leg is a transfer of a quantity of cash or securities from one location to another. The two legs of a single DvP are processed as one - a single, indivisible atomic step. If and only if both legs are valid, do they go through. If either is invalid, then neither is applied.
The table below shows a sequence of in-order steps to support the user stories defined above. It can be summarized as:
Step No. | Leg1 | Leg2 | Signatories to Transfer | ||||||
---|---|---|---|---|---|---|---|---|---|
Source Location | Type | Quantity | Destination Location | Source Location | Type | Quantity | Destination Location | ||
1 | Foreign Key of Bob's Off-Ledger Cash Account with Trent | Foreign Key of Bob's Off-Ledger Funding Transaction with Trent | Foreign Key of Bob's Off-Ledger Quantity | OFF LEDGER LOCATION FLAG | OFF LEDGER LOCATION FLAG | USD | 10,000,000.00 | Bob's On-Ledger Location | Bob, Trent |
2 | Foreign Key of Alice's Off-Ledger Securities Account with Trent | Foreign Key of Alice's Off-Ledger Funding Transaction with Trent | Foreign Key of Alice's Off-Ledger Quantity | OFF LEDGER LOCATION FLAG | OFF LEDGER LOCATION FLAG | T-BILL | 10 | Alice's On-Ledger_Location | Alice, Trent |
3 | Alice's On-Ledger Location | T-BILL | 10 | Bob's On-Ledger Location | Bob's On-Ledger Location | USD | 10,000,000.00 | Alice's On-ledger location | Alice, Bob, Trent |
4 | Alice's On-Ledger location | USD | 10,000,000.00 | OFF LEDGER LOCATION FLAG | OFF LEDGER LOCATION FLAG | OFF LEDGER TYPE FLAG | 10,000,000.00 | Foreign Key of Alice's Cash Account with Trent | Alice, Trent |
5 | Bob's On-Ledger Location | T-BILL | 10 | OFF LEDGER LOCATION FLAG | OFF LEDGER LOCATION FLAG | OFF LEDGER TYPE FLAG | 10 | Foreign Key of Bob's Off-Ledger Securities Account with Trent | Bob, Trent |
The following are a set of high-level set of requirements:
On-ledger certainty means an agreed-to, point-in-time record of which securities and cash are in which locations and in what amounts as well as status of in-flight transfers.
Alice, Bob and Trent are users of the ledger. They are parties to the DvP transfers taking place. They require on-ledger certainty in order to:
That certainty allows them to avoid both on-ledger and off-ledger:
They must be able to discover and/or be informed with certainty of the state of the processing of transfers. That is the case for both in-flight transfers and completed and/or rejected transfers. Therefore, transfers cannot remain in in-determinant states for unpredictable amounts of time. Silent failure of a transfer, for example, is also not acceptable.
It is necessary to provide on-ledger certainty in the face of standard distributed processing challenges (For example: network timeouts, partial success, partial failure, rollback, distributed denial of service (DDOS), failovers, restarts, rogue validator nodes, security breaches, possible duplicate messages sent/received.)
In order to provide on-ledger certainty, guarantees of bounded processing times are required. In addition, clarity is required for what happens to in-flight transfers when these guarantees are breached in general, and what happened to specific in-flight transfers in question.
These SLAs are typically expressed in terms of throughput, latency, volume and scalability. These SLAs typically vary by line of business, local market practices, and security type/asset class being traded.
Line of Business | Local Market | Security Type / Asset Class | Throughput | Latency | Volume | Scalability |
---|---|---|---|---|---|---|
TBD | TBD | TBD | TBD | TBD | TBD | TBD |
The user stories above assume an Over-The-Counter (OTC) trade between a pair of broker/dealers and a separate custodian. This is a simplifying assumption, recognizing that variations, complications and caveats exist based upon line of business, local market, security type, actor, role and regulatory jurisdictions.
Likewise, for purposes of data protection and record retention requirements, a simplified proxy is used. This is based upon a reading of the United States' Federal Government's Securities and Exchange Commission's 2003 interpretation of the 1934 Exchange Act law and associated Rules 17a-3, 17a-4 as it applies to electronic record keeping.
To enable regulators to monitor broker/dealers' compliance with laws, a comprehensive record of each individual securities transaction and the securities business in general must be preserved and made available.
In order to focus on the core of DvP over blockchain, a number of simplifying assumptions are being made:
These complexities may be addressed in other use cases at a later date.
TBD