Author: SlowMist Security Team

With the official passage of the "Stablecoin Regulation," the Hong Kong Monetary Authority (HKMA) released the "Regulatory Guidelines for Licensed Stablecoin Issuers (Draft)" on May 26, 2025, aimed at ensuring the stability, security, and compliance of the local stablecoin ecosystem. The guidelines detail the regulatory requirements and operational standards that licensed stablecoin issuers must continuously adhere to.

Recently, an increasing number of institutions have consulted the SlowMist Security Team regarding the compliance implementation of smart contracts. To assist issuers in better understanding and deploying a compliant smart contract system, we have specially released the "Smart Contract Implementation Guide for Hong Kong Stablecoin Issuers" to provide clear technical pathways and practical recommendations, supporting the healthy development of the Hong Kong stablecoin ecosystem.

Part One: Infrastructure and Compliance Strategy

This section aims to lay the foundation for the high-level architecture of the stablecoin system, driven entirely by the fundamental requirements of the HKMA framework. The choices made here will determine the entire implementation path, ensuring that compliance is deeply embedded in the tech stack from the design phase.

1. Selection of Underlying Distributed Ledger Technology

Regulatory Directive

Licensees must assess the robustness of the underlying distributed ledger technology (DLT) they use. This assessment covers security infrastructure, resilience against common attacks (such as 51% attacks), transaction finality assurance, and the reliability of consensus algorithms.

SlowMist Technical Interpretation

This is not merely a technical preference but a core compliance task. The choice of underlying blockchain must undergo formal due diligence, and the entire assessment process must be thoroughly documented to provide sufficient justification during regulatory reviews. The selection process for the underlying ledger effectively sets the tone for the security and stability of the entire stablecoin system.

The HKMA's emphasis on ledger robustness essentially advises issuers to avoid adopting unproven, overly centralized, or questionable emerging blockchains. The responsibility for proving their security and stability lies entirely with the issuer. If an issuer chooses a chain whose security has not been widely validated, they must design and implement additional compensatory controls.

Implementation Guidelines

• Prioritize Mature Public Chains: It is recommended to prioritize mature and highly secure public blockchains such as Ethereum and Arbitrum. These networks possess inherent advantages due to their proven resilience, large network of validating nodes, and ongoing public oversight. Their high attack costs (economic security) directly address regulatory concerns regarding resilience against 51% attacks and transaction finality assurance.

• Strict Evaluation of Alternatives: If considering the use of consortium chains or other types of distributed ledgers, a rigorous and quantifiable comparative analysis must be conducted, such as a SlowMist security audit, to demonstrate that their security standards are not lower than, or even superior to, mainstream public chains.

• Risk Assessment Documentation: The assessment report must comprehensively cover the ability to withstand common attacks, the type of consensus algorithm, and risks associated with code defects, vulnerabilities, exploits, and other threats, analyzing how these risks could potentially impact the issuance, redemption, and daily operations of the stablecoin. This document is a key file to prove the prudence of the technology selection to regulatory authorities.

2. Core Token Standards and Regulatory Functionality Expansion

Regulatory Directive

The regulatory document does not specify a particular token standard (such as ERC-20). However, it mandates the implementation of a series of core management functions, including minting, burning, upgrading, pausing, resuming, freezing, blacklisting, and whitelisting operations.

SlowMist Technical Interpretation

The HKMA has effectively defined a "regulatory-enhanced" token standard that far exceeds the ERC-20 standard. This standard not only requires basic token circulation functions but also emphasizes operational security, controllable permissions, and traceable risks. To maximize security while meeting compliance requirements, the most efficient and secure development path is to use widely audited, community-recognized standard libraries (such as OpenZeppelin) and expand functionalities based on them.

Implementation Guidelines

• Base Standard: Use ERC-20 as the base standard to ensure token fungibility and interoperability within a broader ecosystem.

• Functionality Expansion: The following functional modules must be integrated to meet regulatory requirements:

• Pausable: To implement global pause and resume functionality for all token activities, which is a core tool for responding to major security incidents.

• Mintable: To ensure that licensed issuers mint new tokens through controlled processes, ensuring that the token issuance strictly corresponds to sufficient fiat reserve assets.

• Burnable: To provide the functionality for token destruction. In specific implementations, this function will be under strict permission control, rather than allowing any user to destroy tokens at will.

• Freezable: To pause the token transfer functionality of specific accounts (e.g., in cases of suspicious transactions).

• Whitelist: To implement additional security measures, allowing only addresses that have undergone due diligence and approval to participate in core operations (e.g., receiving newly minted tokens).

• Blacklist: To implement transaction bans on addresses involved in illegal activities (e.g., money laundering, fraud), prohibiting them from sending/receiving tokens. Blacklist management must be linked with AML/CFT systems for real-time monitoring of suspicious transactions.

• AccessControl: This is the foundation for implementing a fine-grained, role-based permission management system. All management functions must be controlled through this module to meet the requirements of segregation of duties.

3. Main Compliance Models: Choice of Blacklist and Whitelist

Regulatory Directive

Regarding ongoing monitoring, the AML/CFT consultation document proposes various measures, including "blacklisting wallet addresses identified as sanctioned or related to illegal activities," or adopting a stricter "whitelist system for stablecoin holders' wallet addresses, or using a closed-loop model."

SlowMist Technical Interpretation

This is the most critical decision point in the entire system architecture, directly determining the openness, practicality, and complexity of compliance operations for the stablecoin.

• Blacklist Model: A "default open" model. All addresses are allowed to trade freely by default, and only those explicitly identified and added to the on-chain blacklist will be restricted.

• Whitelist Model: A "default closed" closed-loop model. Any address cannot hold or receive tokens unless it has undergone explicit due diligence and approval by the issuer and has been added to the on-chain whitelist.

While the whitelist model provides AML control capabilities, for a stablecoin intended for widespread use, a strict whitelist system means that the stablecoin can only circulate among pre-approved participants, making it more like a closed banking ledger system rather than a flexible digital currency.

Therefore, the blacklist model, also explicitly mentioned by regulators, combined with the strong off-chain analytical tools required by regulators, constitutes a more balanced solution. It meets regulatory requirements while retaining the practicality of the asset.

In design, the system can be built to be upgradeable or to implement both models simultaneously, allowing for smooth transitions or switches to the whitelist model in the future if regulations tighten or business models change.

Implementation Guidelines

• Blacklist Model (Default Recommended Option):

• Advantages: Higher practicality, able to seamlessly interoperate with a broad decentralized finance (DeFi) ecosystem, providing users with a lower barrier to entry and a smoother experience.

• Disadvantages: Compliance heavily relies on strong, real-time off-chain monitoring and analytical capabilities to promptly identify and block illegal addresses.

• Implementation Method: Add logical checks in the smart contract's transfer function to ensure that both the sender (from) and receiver (to) addresses are not recorded on the blacklist.

• Whitelist Model

• Advantages: Provides the highest level of AML/CFT control, achieving prevention before issues arise rather than remediation afterward.

• Disadvantages: Greatly limits the universality and adoption rate of the stablecoin, imposing significant operational overhead for managing the whitelist, which may hinder its acceptance as a widely used medium of exchange.

• Implementation Method: Add logical checks in the smart contract's transfer function, requiring that both the sender (from) and receiver (to) addresses must exist on the whitelist. It is recommended to develop a dedicated web user backend system for operations to enhance convenience.

Part Two: Smart Contract Implementation

This section provides a detailed blueprint for the core functionalities of smart contracts, transforming complex regulatory requirements into specific code-level logic, security patterns, and operational protocols.

1. Design a Fine-Grained Access Control System

Regulatory Directive

The design of high-risk operations must "prevent any single party from unilaterally executing related operations (e.g., through multi-signature protocols)." Different operations' responsibilities should be adequately isolated.

SlowMist Technical Interpretation

This means that a robust, role-based access control system (RBAC) is mandatory. Any form of a single "owner" or "administrator" private key is non-compliant.

Implementation Guidelines

A clear set of roles must be defined, and these roles should be assigned to different entities or employees controlled by multi-signature wallets to achieve segregation of duties, minimizing the risk of single points of failure or collusion. Each role should be limited to specific functions, all operations must require multi-signature authorization, and ensure that no single employee holds multiple high-risk roles simultaneously. All operations must be logged and subject to annual third-party audits, with permission allocation supervised by administrators or the board.

• MINTER_ROLE: Responsible for handling the minting operations of the stablecoin, including creating token units upon receiving valid issuance requests and ensuring that minting corresponds to the increase in the reserve asset pool.

• BURNER_ROLE: Responsible for handling the burning operations of the stablecoin, including destroying token units upon receiving valid redemption requests.

• PAUSER_ROLE: Responsible for pausing the operations of the stablecoin, such as temporarily stopping transfers, minting, or redemptions when an abnormal event (e.g., security threat) is detected.

• RESUME_ROLE: Responsible for resuming the operations of the stablecoin, such as re-enabling transfers, minting, or redemptions after the resolution of a pause event.

• FREEZER_ROLE: Responsible for freezing and unfreezing specific wallets or tokens, such as temporarily freezing assets when suspicious activities (e.g., money laundering risks) are detected.

• WHITELISTER_ROLE: Responsible for managing the whitelist, including adding or removing allowed wallet addresses, such as restricting minting to whitelist addresses only.

• BLACKLISTER_ROLE: Responsible for managing the blacklist and removing addresses from the blacklist, such as blacklisting suspicious wallets to prevent transfers.

• UPGRADER_ROLE: If an upgradeable model is adopted, responsible for upgrading the smart contract, such as updating contract code to fix vulnerabilities or add features.

Table 1: Role-Based Access Control Matrix (RBAC Matrix)

The table below provides a clear and intuitive specification for developers and auditors, explicitly mapping each privileged operation to its required roles and control types.

2. Issuance (Minting) Mechanism

Regulatory Directive

Issuance must be "prudent and robust." Minting must "match the corresponding increase in the relevant reserve asset pool." Issuers should only issue to their customers upon receiving funds and valid issuance requests.

SlowMist Technical Interpretation

The smart contract itself cannot and does not need to enforce the "full reserve" requirement. Instead, it acts as a controlled ledger where minting permissions are a key control point. Compliance with full reserves is an off-chain operational process that can be verified through audits. Regulation ties the minting behavior to the two off-chain events of "valid issuance requests" and "received funds." Therefore, the on-chain minting function must be designed to be callable only by a trusted entity (i.e., the issuer itself) that can verify that these off-chain conditions have been met.

Implementation Guidelines

• Pre-checks: Before executing minting, the function must check whether the target address (to) is on the blacklist or in a frozen state.

• Operational Process:

• Off-chain due diligence: Customers complete all necessary off-chain Know Your Customer (KYC) and Customer Due Diligence (CDD) processes. Additionally, AML/CFT regulations require that for customers establishing business relationships or conducting occasional transactions exceeding a specific threshold (e.g., HKD 8,000), CDD must be performed.

• Funds Reception: Customers transfer equivalent fiat funds into the bank account designated by the issuer.

• Internal Verification: The issuer's internal system confirms receipt of funds and updates the accounting records of reserve assets accordingly.

• On-chain Execution: The operations team creates and signs a multi-signature transaction, calling the smart contract's minting function to send the newly minted stablecoins to the customer's pre-registered and verified wallet address.

3. Redemption (Burning) Mechanism

Regulatory Directive

Licensees must process redemption requests "as soon as practicable and within one business day of receiving the request." The withdrawal of reserve assets must "match the corresponding reduction in the face value of the designated stablecoins in circulation."

SlowMist Technical Interpretation

Redemption is a two-step process involving on-chain and off-chain interactions. During the redemption process, considering the risk of fiat transfers potentially failing, the token burning operation must occur after confirming fiat settlement, not before. This protects the issuer from prematurely burning tokens due to a final failed redemption.

If the issuer burns tokens first and the bank transfer fails, it will result in liabilities without corresponding assets; conversely, if the issuer pays fiat first but cannot burn the corresponding tokens, it will also incur losses.

Therefore, in the redemption operation, users must first transfer the tokens to a designated address controlled by the issuer, after which the issuer will execute the burn after completing the fiat payment. This model allows users to "lock" their tokens for redemption, while the issuer only burns the tokens after fulfilling the fiat payment obligation, providing a safer operational process for both parties.

Implementation Guidelines

• Redemption Preparation: Users must first transfer the tokens they wish to redeem to the designated address controlled by the issuer.

• Operational Process:

• Off-chain Request: Users submit an off-chain redemption request through the issuer's platform. Before processing the request, the issuer must conduct appropriate customer due diligence (CDD).

• System Verification: The issuer's system verifies the validity of the request and checks whether the user has completed the corresponding token transfer operation on-chain.

• Fiat Payment: The issuer transfers equivalent fiat funds to the user's pre-registered and verified bank account.

• On-chain Burning: After confirming the success of the fiat transfer, the multi-signature wallet holding the BURNER_ROLE calls the burn function to destroy the corresponding number of tokens from the specified address.

4. Implementing Emergency Controls: Pausing and Freezing

Regulatory Directive

The contract must support operations such as pausing, resuming, blacklisting, removing from blacklist, freezing, and unfreezing. These are key components of the event management framework.

SlowMist Technical Interpretation

The regulatory document lists "pausing" and "freezing" as two separate items, indicating that regulators expect issuers to have flexible, layered event response capabilities. Pausing is a means to respond to major crises (e.g., contract exploitation), while freezing is a precise tool for handling specific legal or compliance issues (e.g., court orders against individual accounts). The two functions are fundamentally different and must be implemented separately:

• Pause: A global "emergency stop switch" that can instantly halt all core functions of the contract, including transfers, minting, and burning.

• Freeze: An account-level restriction that prevents a specific address from sending or receiving tokens but does not affect the normal activities of other addresses in the network.

Implementation Guidelines

• Pause Function: Can only be called by a multi-signature wallet holding the PAUSERROLE to globally suspend contract functions. Trigger conditions include detecting abnormal events (e.g., network attacks or reserve asset mismatches), requiring approval from the board or senior management. The resume function is handled by a separate RESUMEROLE to achieve segregation of duties.

• Freeze Function: Called by a multi-signature wallet holding the FREEZER_ROLE to impose transfer restrictions on specific addresses. Trigger conditions include suspicious activities (e.g., AML alerts or court orders), requiring off-chain verification before execution. Unfreezing is handled by the same role but requires additional audit verification and the issuance of relevant announcements to prevent abuse.

5. Address Screening and Blacklist Mechanism

Regulatory Directive

Licensees should take measures, such as "blacklisting wallet addresses identified as sanctioned or related to illegal activities." This is a core control measure for ongoing monitoring, and issuers should adopt technologies such as blockchain analysis tools to identify transactions related to illegal or suspicious activities.

SlowMist Technical Interpretation

This must be a mechanism enforced on-chain. Simply issuing warnings off-chain is insufficient; transactions must be prevented at the protocol level. The requirement for a blacklist necessitates that licensees employ real-time blockchain analysis tools/services (such as MistTrack, Chainalysis, Elliptic). The compliance team uses these tools to draw conclusions, which are securely transformed into multi-signature signed transactions to update the on-chain blacklist.

Implementation Guidelines

• Function Implementation: Implement functions for adding and removing addresses from the blacklist, callable only by a multi-signature wallet holding the BLACKLISTER_ROLE.

• Transfer Restrictions: Addresses on the blacklist are prohibited from transferring/receiving tokens.

• Operational Process: Analysis tools issue alerts, triggering internal compliance reviews. After the compliance team reviews and confirms, a transaction to add to the blacklist is initiated by the BLACKLISTER_ROLE multi-signature wallet.

6. Upgradeability of Smart Contracts

Regulatory Directive

All smart contract architectures related to stablecoins may adopt "upgradeability." Each time a smart contract is "upgraded," an audit must be conducted.

SlowMist Technical Interpretation

The design for upgradeability is a core requirement of the regulatory framework for technical flexibility and risk management. It allows issuers to update logic without interrupting the existing contract state to address vulnerability fixes, functionality expansions, or regulatory changes.

However, this also introduces high risks: the upgrade process may be abused, leading to unintended changes in contract behavior or the introduction of new vulnerabilities. Therefore, upgrades must be treated as high-risk operations, designed to prevent unilateral execution by any single party (e.g., through multi-signature protocols) and integrated with a role-based access control system (RBAC).

The regulatory emphasis on audit requirements means that upgrades are not just code replacements but controlled events embedded with strict change management processes, ensuring that the new logic contract is verified by a third party before deployment, free of vulnerabilities or security flaws.

Implementation Guidelines

• Proxy Model: For EVM-type smart contracts, the mature ERC-1967 proxy model can be adopted to achieve upgradeability.

• Access Control: The upgrade function must only be called by a multi-signature wallet holding the UPGRADER_ROLE.

• Change Management Process: According to regulatory requirements, a strict change management process must be completed before proposing any upgrades, which includes a comprehensive, independent third-party security audit of the new logic contract.

7. On-chain Event Logs for Analysis and Reporting

Regulatory Directive

Licensees must establish robust "information and accounting systems" to "timely and accurately record all business activities, including on-chain and off-chain information," and "maintain appropriate audit trails."

SlowMist Technical Interpretation

The smart contract is the primary source of truth for all on-chain activities. It must emit detailed events for every significant state change, allowing off-chain systems to log, monitor, and generate reports. These events create an immutable and permanent log on the blockchain. This log serves as the primary data source for all off-chain monitoring, accounting, and reporting systems, providing a solid foundation for audits.

Implementation Guidelines

In addition to the transfer (Transfer) and approval (Approval) events required by the ERC-20 standard, the contract must define and emit custom events for all management actions and state changes:

• Token Minted / Burned events

• Contract Paused / Resumed events

• Blacklist Added / Removed events

• Whitelist Added / Removed events

• Address Frozen / Unfrozen events

• Role Granted / Revoked events

• Contract Upgraded events

Part Three: Operational Security and Lifecycle Management

This section elaborates on the critical operational security procedures surrounding smart contracts. These procedures are as important as the code itself and are necessary for achieving comprehensive security and compliance.

1. Secure Key Management Framework

Regulatory Directive

This is one of the most detailed and stringent areas specified in the regulatory documents. Licensees must implement strong controls over the entire lifecycle of private keys, including generation, storage, usage, backup, and destruction. "Critical seeds and/or private keys" (e.g., keys for upgrades, role management, large-scale minting) require higher security standards, including offline generation in an "air-gapped environment" and storage in Hardware Security Modules (HSM).

SlowMist Technical Interpretation

The Hong Kong Monetary Authority is essentially requiring the application of "traditional financial-grade" security postures to crypto-native operations. The costs and complexities associated with implementing this level of key management are significant, and it will become a core operational component for any licensed issuer. This security model far exceeds the practice standards of typical DeFi projects. The regulatory documents provide a detailed checklist for key management, explicitly mentioning HSMs, air-gapped environments, key ceremonies, and multi-signatures. This effectively mandates the construction of a multi-layered defense key management framework: accounts stored in hardware wallets serve as signers of a multi-signature wallet, which itself holds management roles on the smart contract. For the highest security roles, these hardware wallets must be managed in designated, physically secure air-gapped environments. The entire framework builds a multi-layered defense system against key leakage.

Implementation Guidelines

• Key Generation: Must be completed through a "key ceremony" documented in detail, conducted in a physically secure, completely isolated air-gapped environment.

• Key Storage: All management roles must be controlled by multi-signature wallets. The private keys used by the signers of these multi-signature wallets must be stored in HSMs or other secure hardware wallets. For the most critical roles, the corresponding keys must be kept in air-gapped systems, physically isolated from any online environment.

• Key Usage: Multi-signature policies must be enforced. For transactions involving "critical private keys," relevant personnel may need to be present to operate.

• Backup and Recovery: Backups of key shards or mnemonic phrases must be stored in multiple secure and geographically dispersed locations within Hong Kong (or other regulatory-approved locations) and must use tamper-evident packaging.

2. Comprehensive Deployment Process and Runtime Monitoring

Regulatory Directive

Licensees must engage "qualified third-party entities to audit smart contracts," with an audit frequency of at least once a year, and audits must be conducted during each deployment, redeployment, or upgrade. Audits must ensure that the contract is implemented correctly, functions as expected, and has no vulnerabilities or security flaws at a "highly trusted level." Licensees should implement measures to monitor the usage of mnemonic phrases and/or private keys (e.g., IP checks, behavior monitoring, key activity alerts, device screening, on-chain monitoring, access control monitoring, etc.). Additionally, licensees should take appropriate measures to monitor threat intelligence to identify emerging threats. Threat intelligence should be analyzed to enable timely mitigation measures.

SlowMist Technical Interpretation

The deployment process and runtime monitoring are direct extensions of the regulatory framework for managing technical risks, emphasizing the prevention of vulnerabilities from the outset and the continuous monitoring of operational risks. The pre-deployment audit requirement treats smart contracts as critical infrastructure, necessitating multi-layer validation (such as unit testing, independent audits, and code freezing) to ensure defect-free operation, reflecting the regulatory pursuit of "highly trusted" standards to avoid code defects or exploits affecting the issuance, redemption, or daily operations of stablecoins. Runtime monitoring focuses on real-time threat detection, combining private key usage monitoring (such as behavior analysis) and threat intelligence analysis to form a closed-loop response mechanism. This not only meets the needs of the event management framework but also ensures that the system can dynamically respond to emerging risks. Overall, the technical implementation of this section should integrate on-chain and off-chain tools to create traceable audit trails, transforming passive defenses into proactive compliance.

Implementation Guidelines

Before formal deployment, a "pre-deployment checklist" must be developed and strictly enforced:

• Comprehensive Testing: Ensure unit test coverage exceeds 95%, with core code coverage at 100%, and ensure output unit test coverage reports are provided.

• Independent Audit: Complete an independent security audit report from at least one, preferably two, reputable auditing firms.

• Code Freezing: After the audit, freeze the code until it goes live, making no further code changes.

• Regression Testing: Execute unit tests and conduct regression testing before formal deployment.

• Compliance Sign-off: Obtain formal sign-off from the internal compliance team, confirming that the contract logic meets all relevant regulatory requirements.

• Deployment Drill: Prepare detailed deployment scripts and conduct a complete deployment drill on a test network that is fully consistent with the mainnet environment.

• Authorized Deployment: The final deployment operation must be executed by an authorized wallet.

After deployment, appropriate monitoring measures should be taken to implement timely mitigation measures for the usage of privileged roles and emerging threats:

• On-chain Activity Monitoring: Monitor the usage of management roles (e.g., using SlowMist's security monitoring system MistEye to add key role activity monitoring) to promptly detect unauthorized occurrences.

• Threat Intelligence Monitoring: New emerging threats should be promptly identified (e.g., using threat intelligence subscriptions from SlowMist's security monitoring system MistEye) and analyzed to enable timely mitigation measures.

3. Technical Support for Business Continuity and Exit Planning

Regulatory Directive

Licensees must develop a "business exit plan to achieve an orderly liquidation of their licensed stablecoin business." This plan must include procedures for liquidating reserve assets and distributing proceeds to holders.

SlowMist Technical Interpretation

This means that smart contracts must consider their own "decommissioning" process from the design stage, requiring mechanisms and states that enable orderly shutdowns. The requirement for an exit mechanism implies that the lifecycle of a smart contract does not end at deployment; rather, it must have a clearly defined, protocol-level "termination" protocol. This is a novel concept for many developers accustomed to building "permanent" contracts and thus promotes a "designed for termination" mindset. An orderly liquidation process requires a clean, final, and undisputed record that clearly states who owns what at the moment of shutdown. If the shutdown occurs in a chaotic state with ongoing transactions, this goal will be difficult to achieve. Therefore, a function that can freeze the contract state is a direct technical embodiment of this regulatory requirement. The on-chain state thus becomes the final, auditable source of truth in the hands of the liquidator.

Implementation Guidelines

• Develop a Business Exit Plan: The plan should cover various scenarios that could lead to an orderly termination and include monitoring measures for the actual or potential occurrence of these scenarios.

• On-chain Exit Process:

• The smart contract should be paused to stop all token transfer activities to maximize the liquidation proceeds of reserve assets and minimize the impact on overall market stability.

• Utilize the redemption and whitelist functions to assist stablecoin holders in submitting redemption requests.

Part Four: Appendix: Regulatory Requirements Cross-Reference Table

This table directly maps each technical feature of the smart contract system to the specific regulatory text that mandates it:

Related Information

[1]Hong Kong Monetary Authority. (2025, May 26). Consultation paper on the proposed AML/CFT requirements for regulated stablecoin activities. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526ConsultationPaperontheProposedAMLCFTReqforRegulatedStablecoinActivities.pdf_

[2]Hong Kong Monetary Authority. (2025, May). Draft guideline on supervision of licensed stablecoin issuers. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf

Citations in the text

[1] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.5_

[2] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.5_

[3] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 20, 6.5.3_

[4] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 20, 6.5.3_

[5] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.4_

[6] ConsultationPaperontheProposedAMLCFTReqforRegulatedStablecoinActivities.pdf, p. 13, 3.6.2

[7] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 20, 6.5.3_

[8] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.4_

[9] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 10, 3.1.1_

[10] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 12, 3.4.1_

[11] ConsultationPaperontheProposedAMLCFTReqforRegulatedStablecoinActivities.pdf, p. 9, 3.2.1

[12] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 11, 3.2.3_

[13] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 11, 3.2.5_

[14] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 38, 6.8.2_

[15] ConsultationPaperontheProposedAMLCFTReqforRegulatedStablecoinActivities.pdf, p. 13, 3.6.2

[16] ConsultationPaperontheProposedAMLCFTReqforRegulatedStablecoinActivities.pdf, p. 11, 3.4.2

[17] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 20, 6.5.2_

[18] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.5_

[19] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 51, 8.1.1_

[20] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 22, 6.5.8_

[21] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 23, 6.5.8(ii)_

[22] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 23, 6.5.8(iv)_

[23] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 22, 6.5.8(ii)_

[24] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 24, 6.5.8(vii)_

[25] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 25, 6.5.8(x)_

[26] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 21, 6.5.5_

[27] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 24 6.5.8(ix)_

[28] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 34 6.5.20(ii)_

[29] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 42, 6.8.16_

[30] ConsultationonDraftGuidelineonSupervisionofLicensedStablecoinIssuers.pdf, p. 42, 6.8.16_

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。