Authorization and Certificate Token ACT: Application Design in Regulated Financial Services Industry
Author: PlatON CTO, James QU
Centralized and decentralized governance have alternated throughout history, depending on which form of governance is more effective and important at the time. In the tribal societies of the Stone Age, people needed to work closely together to combat dangerous wildlife and natural disasters. Now, an individual can enjoy high-quality music and fine wine at home, much like a king did a century ago. We live in an era conducive to decentralization, where people have more freedom and contribute more as individuals, with relatively less contribution as group members or corporate employees.
In summary, when the legal environment or social consensus mechanisms in certain areas are not yet mature, we still need centralized models as a buffer for transformation. Traditional finance is one such area, where investor protection, taxation, and governance purposes are highly regulated, generating enormous profits for the government.
ACT (Authorization and Certificate Token) is based on NFT and is a hybrid of Soul Bound Tokens and Semi-Fungible Tokens, specifically designed for regulated financial services on public chains.
This ACT framework is designed for data flow control, as we believe that financial services such as transactions are a simplified form of data flow, which is why we chose the financial services industry.
Borrowing from the financial services license structure of the Monetary Authority of Singapore, here is an example.
Basic License Elements
Appendix A defines different basic elements for various categories of financial services. For example, there are five categories covering banking, capital markets, financial advisory, insurance, and payments. In the banking services category, we define nine basic elements (types or statuses): from B001 to B009, ranging from local banks to financial holding companies (banking). The relationships are shown in the diagram below:

Each of the basic license elements above should have a clear definition of the scope of services, especially for the token-related financial services we will use when introducing traditional services onto public chains like PlatON.
For example, B001 local banks may allow the minting of stablecoins pegged to fiat currencies, while B007 currency brokers may not allow the minting of stablecoins and can only conduct transactions through exchange services.
Furthermore, regarding KYC, AML, and CFT procedures, all the aforementioned financial institutions must comply with standard regulatory procedures offline before onboarding any clients. Only after passing the procedural review will the soul bound tokens (SBT) issued by regulatory authorities be transferred to the wallets of those qualified institutions. We refer to this as mandatory SBT.
Grouping of Basic License Elements - SBT-Based License Model
Imagine how to obtain a certification license from government agencies. First, verify the mandatory SBT, such as the qualifications for all mandatory standards. Once confirmed, one or more license SBTs will be minted to the target institution's wallet based on the application and assessment. These financial services SBTs can be defined as a set of basic license elements. If the license has a time limit (expires after a specific period) or any other dynamically changing permissions, semi-fungible tokens can also be considered as SBT.
As I explained in the previous article, for financial license SBTs, government agencies (the minters of SBTs) should have complete control.
- \<issuer, other, IC>: Issuer mints SBTs to others, issuer has complete control
A typical license might look like this, granting one or more SBTs to a set of basic license elements.

Here, control refers to minting, burning, and modifying, such as extending the validity period. Please consider using an extended SBT protocol with owner restrictions for extending validity periods. An example is shown below (to be refined during implementation):

Institutions Holding License SBTs Can Build Customer Service SBT Structures
Institutions may aggregate similar structures. They can issue different types of SBTs within them to indicate:
KYC certification passed by the customer
Financial service profile
Risk analysis level
Other information
Similarly, those SBTs related to customer service have a completely different set of basic service elements, which should align with the granted licenses. Taking brokerage trading services as an example, the following details are provided.

More than two years have passed, but the above process has not yet been fully realized. We hope to see community development teams join the discussion and implementation. Additionally, we look forward to seeing better feasible designs.
1. Banking

2. Capital Markets


3. Financial Advisory

4. Insurance

5. Payments

Appendix B: Basic Elements of Financial Services
- Banking services, based on The Banking Act of Singapore (BA1970)
Popular articles














