For certain types of Digital Assets (native non-security tokens such as crypto-currencies or Utility Tokens) issued on DLTs, a transfer of Digital Assets occurs when both the sender and the receiver, after agreeing on the terms of the transaction, settle the transaction on a peer-to-peer basis. They can involve a third party (such as a trustee) to implement conditional mechanisms, but basically the sender initiates a transfer on the DLT, then the receiver observes the receipt of the Digital Asset (confirmation mechanisms can be implemented to allow the receiver to confirm receipt).
The main issues with such a setup of disintermediated peer-to-peer transactions are the following:
-
Lack of regulatory checks: any sender can transfer a Digital Asset to any receiver, which raises concerns about the checks required for any transfer between the sender and the receiver from a legal and regulatory standpoint (KYC-AML, sanctions,-embargoes, etc.).
-
Irreversibility of transactions: such transfers are not reversible: only the receiver can initiate a transfer to return a Digital Asset it is not supposed to hold. No trusted third party can alter a peer-to-peer Digital Asset transaction when it has been fully completed and registered on the DLT.
To avoid such concerns, the CAST Framework provides a setup adapted to regulated transactions on financial instruments registered on a DLT:
1) Pre-approvals and regulatory checks before any operation on Security Tokens:
The Registrar (appointed by the Issuer) bears the responsibility for initiating any transfer of Security Tokens on behalf of the Issuer, under conditional approval of the Settlement Agent. The Instructing Party must first instruct the Registrar to do so, either directly or through its custodians or brokers.
Before processing any transfer, the Issuer and/or its Registrar is responsible for conducting KYC diligence on both the sender and the receiver to ensure that the regulatory conditions are met for such transfer.
The Settlement Agent (appointed by the Issuer) must confirm the termination of the transfer. This confirmation may be conditional on any other obligation related to the transaction (e.g. payment obligation).
As a consequence, under the CAST Framework, a sender and a receiver cannot perform any transaction involving the transfer of Security Tokens without the intermediation of a trusted third-party, the Registrar, duly appointed as such by the Issuer.
This setup ensures that any transaction involving a transfer of Security Token has been checked (from a legal and regulatory standpoint, notably regarding KYC/AML and embargoes-sanctions issues) since its inception.
The responsibilities of both the Registrar and the Settlement Agent are coded directly in the Security Token’s Smart Contract and are documented in the issuance contractual framework.
2) Possibility of adapting to technological or regulatory constraints:
On the occurrence of any regulatory issue (e.g. an Investor red-flagged for embargoes-sanctions reasons) or technological issue (e.g. a temporary disruption of a DLT), the Registrar acting on behalf of the Issuer should have the possibility to block a potential Security Token trade for a given Investor, to freeze a given Investor’s Security Token and to provide technological solutions to switch from one DLT to another or from a DLT to current infrastructures if necessary.