Constraints for Tokenized Securities
Although, so far, the rules applicable to issuing and holding utility tokens were largely undefined - or at least very vague - in most countries, an STO consists in the issuance of a security that uses the blockchain technology as its registry, proof of ownership and transfer infrastructure. Such instrument is regulated in every country and, as a consequence, STOs have to comply with the related regulations of the country where the security token is issued as well as those of the countries where it is distributed (sold).
|Characteristics||Utility Token||Security Token|
|Regulation||Non existing or vague in most cases||Stringent as existing securities laws should be taken as reference|
|Lifecycle||Simple||As complex as a security|
|Secondary Market||Nearly no constraints||As complex as a security|
Another significant difference between ICOs and STOs is related to the token lifecycle. ICOs - dealing with utility tokens - result in the issuance of tokens having a relatively simple life cycle: once the token is shared among a decentralized network, its governance is mostly the results of its token economics. As to security tokens, it is quite different, as the issuer - or its appointed agent - generally remains liable for applying a number of controls to his token after issuance and during the entire “life” of its security token. In addition, he might need to apply a number of corporate actions (dividend/interests payments, … ) or corporate events (calling for an AGM/EGM, …) to its token which further increase the need for the issuer to keep in touch with (keep some control on) the investors in his token.
One could identify two main types of control requirements related to the issuance, the holding and the transfer of security tokens: - One relates to regulations applicable to the security considered, that are independent of the security token itself (i.e. general rules). For example, the need to identify the investor, to collect a proof of his identity, to check his name against blacklists, i.e. generally speaking, control requirements related to AML/KYC, or other applicable regulatory rules. - Then some controls might be explicitly related to the security that is issued, for example, restrictions about the investor type and location or about the amount of money that can be invested in a certain period. These might be linked to the regulatory environment under which the issuer has decided to issue his token or simply linked to eligibility criteria defined by the issuer for instance, for commercial reasons (e.g. restricting the access of a certain share class, having specific fees characteristics, to investors of a specific country).
Addressing these different control requirements will require a high level of reusability and flexibility when designing the token. The T-REX standard has been developed for this reason. It provides a set of generic tools helping token issuers to apply and manage the necessary controls and permissions to security tokens through a flexible, decentralized validation system (the transfer manager), allowing them to add all the rules that need to be addressed to approve holding and transacting in their tokens.