Authorization and Certificate Token (ACT): Application Design in Regulated Financial Services
TechFlow Selected TechFlow Selected
Authorization and Certificate Token (ACT): Application Design in Regulated Financial Services
ACT is based on NFTs and serves as a hybrid of soulbound tokens and semi-fungible tokens, specifically designed for regulated financial services on public blockchains.
Navigating Web3 tides with focused insights
Author: James QU, CTO of PlatON
Centralized and decentralized governance alternate throughout history, depending on which model proves more effective and relevant at any given time. In tribal societies during the Stone Age, people had to cooperate closely to survive dangerous wildlife and natural disasters. Today, an individual can enjoy high-quality music and fine wines at home—luxuries once reserved for kings a century ago. We live in an era suited for decentralization, where individuals have greater freedom and contribute increasingly as independent actors rather than primarily as members of groups or employees within corporations.
Nevertheless, when the legal environment or social consensus mechanisms in certain domains are not yet mature, centralized models remain necessary as transitional buffers. Traditional finance is one such domain—it is highly regulated for investor protection, taxation, and governance purposes, and generates substantial revenue for governments.
ACT (Authorization and Certificate Token), based on NFTs, is a hybrid of Soul Bound Tokens (SBTs) and Semi-Fungible Tokens (SFTs), specifically designed for regulated financial services on public blockchains.
This ACT framework is specifically designed for controlling data flows. We consider financial services such as trading to be simplified forms of data flow, which is why we have chosen the financial services industry as our initial focus.
Using the licensing structure of the Monetary Authority of Singapore (MAS) as an example, consider the following.
Basic License Elements
Appendix A defines different basic elements for various categories of financial services. For instance, there are five main categories: banking, capital markets, financial advisory, insurance, and payments. Within the banking services category, we define nine basic elements (types or statuses), labeled B001 to B009, ranging from local banks to financial holding companies (banking).
The relationship is illustrated below:
Each of the above basic license elements should have a clearly defined scope of service, especially when we introduce traditional services onto public blockchains like PlatON and tokenize associated financial services.
For example, B001 (Local Bank) may be permitted to mint fiat-pegged stablecoins, whereas B007 (Money Broker) may not mint stablecoins but only conduct exchange transactions.
Another example: KYC, AML, and CFT procedures. All the above financial institutions must first complete standard regulatory compliance procedures offline before onboarding any customer. Only after passing these reviews will regulators issue Soul Bound Tokens (SBTs) to the qualified institution’s wallet. We refer to these as mandatory SBTs.
Grouping Basic License Elements—An SBT-Based Licensing Model
Imagine how an institution obtains its certification from a government agency. First, mandatory SBTs—such as qualifications meeting all required standards—are verified. Once confirmed, based on application and assessment, one or more license SBTs are minted to the target institution's wallet. These financial service SBTs can be defined as a set of basic license elements. If a license has time-bound validity (expires after a specific period) or other dynamically changing permissions, semi-fungible tokens can also be treated as SBTs.
As I explained in my previous article, for financial license SBTs, the issuing authority (the government agency) should retain full control.
1. <issuer, other, IC> : Issuer mints SBTs to others, issuer has complete control
A typical license might look like this—an SBT or multiple SBTs granting a bundle of basic license elements.
Here, "control" refers to operations such as minting, burning, and modifying—for example, extending validity periods. Consider implementing an extended SBT protocol that uses owner-restricted methods to extend validity.
Example below (subject to refinement during implementation):
Institutions Holding License SBTs Can Construct Customer Service SBT Structures
Institutions may assemble similar structures. They can issue different types of SBTs within them to indicate:
1. KYC verification passed by the customer
2. Financial service profile
3. Risk assessment level
4. Other information
Likewise, those SBTs related to customer services contain a completely different set of basic service elements, which must align with the granted license.
Take broker-dealer transaction services as an example—the details are shown below.
It has been over two years, yet the above process has not yet been fully implemented. We hope community development teams will join discussions and help with implementation.
Additionally, we look forward to seeing better and more practical 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 Monetary Authority of Singapore Banking Act (BA1970)
2.https://www.mas.gov.sg/regulation/capital-markets
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
