Author: PlatON CTO James QU
Click to read: Several interesting application scenarios of soul-bound tokens
Authorization and Certification Token ACT: Application Design in Regulated Financial Services
Centralized and decentralized governance have alternated between cycles of history, depending on which governance is more effective and important at the time. In Stone Age tribes, people needed to work closely together to fight dangerous wildlife and natural disasters. Now, one can enjoy high-quality music and fine wine at home like a king a hundred years ago. We live in an era suitable for decentralization. People have more freedom, and they make more contributions as individuals, and relatively less as group members and corporate employees.
To sum up, when the legal environment or social consensus mechanism in some fields is not yet mature, we still need a centralized model as a buffer for transition. One of them is traditional finance, which generates huge profits for governments as it is highly regulated for investor protection, taxation and governance purposes.
ACT (Authorization and Certificate, authorization and certificate token) is based on NFT. It is a mixture of Soul Bound Token and Semi fungible Token. It is designed for regulated financial services on the public chain. Designed for service.
This ACT framework is designed for data flow control, we believe that financial services such as transactions are a simplified data flow, which is why we chose the financial services industry.
Borrowing from the Monetary Authority of Singapore’s Financial Services Licensing Structure, an example is shown below.
Basic License Elements
Different basic elements are defined in Appendix A for different categories of financial services. For example, there are five categories covering banking, capital markets, financial advice, insurance and payments. In the banking services category, we define nine basic elements (types or states): from B001 to B009, from local banks to financial holding companies (banking). The relationship is shown in the following figure:
Each of the above basic license elements should have a clear definition of service scope, especially the token-related financial services that we will use when introducing traditional services to public chains such as PlatON.
For example, B001 local banks may allow the minting of fiat-pegged stablecoins, while B007 currency brokers may not allow the minting of stablecoins and can only be traded through exchange services.
Another example is KYC, AML, and CFT procedures. All the above-mentioned financial institutions must comply with standard regulatory procedures offline before listing any customer. Only after passing the program review, will the Soul Binding Token (SBT) issued by the regulatory agency be transferred to those Qualified institutional wallet. We call it mandatory SBT.
Grouping of Basic License Elements – SBT-Based License Model
Just imagine how to obtain a certification body license from a government agency. First, verify mandatory SBT, e.g. eligibility for all mandatory standards. Once confirmed, based on the application and evaluation, one or more license SBTs will be minted into the wallet of the target institution. These financial services SBTs can be defined as a set of basic license elements. Semi-fungible tokens can also count as SBT if the license has a time limit (expires after a certain time), or any other dynamically changing permissions.
As I explained in my previous article, for the financial license SBT, the government agency (the mint of the SBT) should have full control.
1. : Issuer mints SBTs to others, issuer has complete control
A typical license might look like the following, granting a basic set of license elements as one SBT or multiple SBTs.
Control here refers to operations such as minting, destroying and modifying, such as extending the validity period. Consider here an extended SBT protocol with owner-limited extended validity methods. The example is as follows (to be improved in the implementation process):
Institutions with a license SBT can build a customer service SBT structure
Institutions may assemble similar structures. There they can post different types of SBTs to point out:
1. KYC certification passed by the customer
2. Overview of Financial Services
3. Risk Analysis Level
4. Other information
Likewise, those SBTs related to customer service have a completely different set of basic service elements that should be consistent with the license granted. Taking broker trading services as an example, the following is a detailed description.
More than two years have passed, but the above process has not been fully realized. Hopefully a community development team will join the discussion and implementation. Also, expect to see better viable designs.
Appendix A: Basic Elements of a Financial License (MAS Financial Institution Directory)
1. Banking
2. Capital Market
3. Financial advice
4. Insurance
5. Pay
Appendix B: Fundamentals of Financial Services
1. Banking services, based on the Monetary Authority of Singapore Banking Act (BA1970)
2. https://www.mas.gov.sg/regulation/capital-markets
3. https://www.mas.gov.sg/regulation/Insurance
4. https://www.mas.gov.sg/regulation/payments