Technical guidance: Smart contract implementation guide for Hong Kong stablecoin issuers

With the formal passage of the Stablecoin Ordinance, the Hong Kong Monetary Authority (HKMA) issued the "Draft Guidelines for the Supervision of Licensed Stablecoin Issuers" on May 26, 2025, aiming to ensure the stability, security and compliance of the local stablecoin ecosystem. The guidelines detail the regulatory requirements and operating standards that licensed stablecoin issuers must continue to comply with.

Recently, more and more institutions have consulted the SlowMist security team on the compliance implementation of smart contracts. In order to help issuers better understand and deploy compliant smart contract systems, we have specially released the "Smart Contract Implementation Guide for Hong Kong Stablecoin Issuers" to provide clear technical paths and practical suggestions to support the healthy development of the Hong Kong stablecoin ecosystem.

Part I Infrastructure and Compliance Strategy

This section aims to lay the high-level architectural foundation for the stablecoin system. These architectural decisions are driven entirely by the most fundamental requirements in the Hong Kong Monetary Authority (HKMA) framework. The choices made here will determine the entire implementation path, ensuring that compliance is deeply embedded in the technology stack from the beginning of the design.

1. Choice of underlying distributed ledger

Regulatory Directives

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

SlowMist Technology Explanation

This is not a simple choice of technology preference, but a core compliance task. The selection of the underlying blockchain must undergo formal due diligence, and the entire evaluation process must be documented in detail to provide sufficient justification during regulatory review. The selection process of the underlying ledger actually sets the tone for the security and stability of the entire stablecoin system.

The HKMA’s emphasis on ledger robustness is essentially an admonition to issuers to avoid adopting emerging blockchains that are unproven, overly centralized, or have questionable security. The burden of proving their security and stability lies entirely with the issuer. If the issuer chooses a chain whose security has not been widely verified, it must design and implement additional compensatory controls.

Implementation Guide

• Prioritize mature public chains : It is recommended to prioritize mature and highly secure public blockchains such as Ethereum and Arbitrum. Such networks have natural advantages due to their proven resilience, large network of verification nodes, and continuous public supervision. Their high attack costs (economic security) can directly respond to regulatory concerns about resisting 51% attacks and ensuring transaction finality.

• Rigorous evaluation of alternatives: If a consortium chain or other type of distributed ledger is considered, a rigorous and quantifiable comparative analysis, such as a SlowMist security audit, must be conducted to prove that its security standards are not lower than, or even better than, those of mainstream public chains.

• Risk Assessment Document: The assessment report must comprehensively cover its ability to resist common attacks, the type of consensus algorithm, and the risks associated with code defects, vulnerabilities, vulnerability exploits and other ^threats2 , and analyze in detail how these risks may potentially affect the issuance, redemption and daily operations of stablecoins. This document is a key document to demonstrate to regulators the prudence of technology selection.

2. Core Token Standards and Regulatory Function Expansion

Regulatory Directives

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

SlowMist Technology Explanation

The Hong Kong Monetary Authority has in fact defined a "regulatory-enhanced" token standard that has functions far beyond the ERC-20 standard. This standard not only requires basic token circulation functions, but also emphasizes operational security, controllability of permissions, and risk traceability. In order to maximize security while meeting compliance requirements, the most efficient and safest development path is to adopt a widely audited, community-recognized standard library (such as OpenZeppelin) and expand functions on this basis.

Implementation Guide

• Basic Standards : ERC-20 is adopted as the basic standard to ensure the homogeneity of tokens and interoperability in the wider ecosystem.

• Functional expansion: The following functional modules must be integrated to meet regulatory requirements:

• • Pausable: Used to implement the global pause and resume function of all token activities. This is a core tool for responding to major security incidents.

  • Mintable: It is used to implement the requirement that licensed issuers mint new tokens through a controlled process and ensure that the amount of tokens issued strictly corresponds to sufficient legal currency reserve assets.

  • Burnable: Provides the function of destroying tokens. In the specific implementation, this function will be strictly controlled by permissions, rather than allowing any user to destroy them by themselves.

  • Freezable: Used to suspend the token transfer function of a specific account (such as those involved in suspicious transactions).

  • Whitelist: Used to implement additional security measures, allowing only addresses that have passed due diligence and approval to participate in core operations (such as receiving newly minted ^tokens4 ).

  • Blacklist: Used to implement transaction bans on addresses involved in illegal activities (such as money laundering, fraud), prohibiting them from sending/receiving tokens. Blacklist management needs to be linked with the AML/CFT system to monitor suspicious transactions in real time.

  • AccessControl: This is the basis for implementing a refined, role-based permission management system. All management functions must be controlled through this module to meet the requirements of separation of duties5 ^.

3. Main compliance mode: blacklist and whitelist selection

Regulatory Directives

Regarding ongoing monitoring, the Anti-Money Laundering/Countering the Financing of Terrorism (AML/CFT) consultation paper proposes a variety of measures, including “blacklisting wallet addresses identified as being sanctioned or associated with illegal activities” or a more stringent “whitelisting of wallet addresses of stablecoin holders, or a closed-loop model” ⁶ .

SlowMist Technology Explanation

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

• Blacklist mode : A "default open" mode. All addresses can trade freely by default, and only those addresses that are clearly identified and added to the on-chain blacklist will be restricted.

• Whitelist mode: A closed-loop mode that is “closed by default”. Any address cannot hold or receive tokens unless it has been explicitly investigated and approved by the issuer and added to the on-chain whitelist.

Although the whitelist model provides AML (anti-money laundering) control capabilities, for a stablecoin designed to be widely used, a strict whitelist system means that stablecoins can only circulate between pre-vetted participants, making it more like a closed bank ledger system than a flexible digital currency.

Therefore, the blacklist model, which is also explicitly mentioned by the regulator, combined with the powerful off-chain analysis tools required by the regulator, constitutes a more balanced solution. It not only meets regulatory requirements but also retains the practicality of assets.

In terms of design, the system can be built to be upgradeable, or to implement both modes simultaneously, so that it can smoothly transition or switch to the whitelist mode when regulations are tightened or business models change in the future.

Implementation Guide

• Blacklist mode (default recommended solution) :

• • Advantages: It has higher practicality and can interoperate seamlessly with the vast decentralized finance (DeFi) ecosystem, providing users with a lower usage threshold and a smoother experience.

  • Disadvantages: Compliance is highly dependent on powerful, real-time off-chain monitoring and analysis capabilities to promptly detect and block illegal addresses.

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

• Whitelist mode

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

  • Disadvantages : Greatly limits the versatility and adoption of stablecoins, brings huge operational overhead to managing whitelists, and may make it difficult for them to become a widely accepted medium of exchange.

  • Implementation method: Add logic checks in the transfer function of the smart contract, requiring that both the sender (from) and receiver (to) addresses of the transaction must be in the whitelist. It is recommended to develop a dedicated Web user backend system for operation to increase the convenience of operation.

Part 2 Smart Contract Implementation

This section provides a detailed blueprint for the core functionality of smart contracts, translating complex regulatory requirements into specific code-level logic, security models, and operating protocols.

1. Design a sophisticated access control system

Regulatory Directives

High-risk operations must be designed to “prevent any single party from being able to unilaterally execute the relevant operations (e.g., via a multi-signature protocol)” ^7. Responsibilities for different operations should be adequately segregated.

SlowMist Technology Explanation

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

Implementation Guide

A clear set of roles must be defined and assigned to different entities or employees controlled by multi-signature wallets to achieve separation of duties and minimize the risk of single points of failure or collusion8 ^. Each role should be limited to specific functions, all operations require multi-signature authorization, and ensure that no single employee holds multiple high-risk roles at the same time. All operations must be logged and subject to annual third-party audits, and the allocation of permissions is overseen by administrators or the board of directors.

• MINTER_ROLE: Responsible for handling the minting operations of stablecoins, including creating token units upon receiving a valid issuance request and ensuring that minting matches corresponding increases in the reserve asset pool.

• BURNER_ROLE: Responsible for handling the burning of stablecoins, including destroying token units upon receiving a valid redemption request.

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

• RESUME_ROLE: Responsible for resuming stablecoin operations, such as re-enabling transfers, minting, or redemptions after the suspension event is resolved.

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

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

• BLACKLISTER_ROLE: Responsible for managing blacklists and removing blacklists, such as blacklisting suspicious wallets to prevent transfers.

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

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

The following table provides a clear, intuitive specification for developers and auditors to use, explicitly mapping each privileged operation to its required role and control type.

2. Issuance (coinage) mechanism

Regulatory Directives

Issuance must be “prudent and robust”. Minting must be “matched with a corresponding increase in the underlying reserve asset pool”. Issuers should issue to their customers only after receiving funds and a valid issuance request9.

SlowMist Technology Explanation

Smart contracts themselves cannot and do not need to enforce the "full reserve" requirement. Instead, they play the role of a controlled ledger, where the minting authority is the key control point. Full reserve compliance is an audit-verifiable operation that occurs off-chain. Regulation binds minting to two off-chain events: "valid issuance request" and "received funds". Therefore, the on-chain minting function must be designed to be called only by a trusted entity (i.e., the issuer itself) that can verify that these off-chain conditions have been met.

Implementation Guide

Pre-check: Before executing the minting function, the function must check whether the target address to is in the blacklist or frozen state.

Operation process:

• Off-chain Due Diligence: Clients complete all required off-chain KYC and CDD processes10. In addition, AML/CFT regulations require CDD11 for clients who establish a business relationship or conduct occasional transactions above a certain threshold (e.g. HK$8,000).
• Funds Receiving: The customer transfers the equivalent amount of legal currency to the bank account designated by the issuer.
• Internal Verification: The issuer’s internal systems confirm receipt of funds and update the accounting records of reserve assets accordingly.
• On-chain execution: The operations team creates and signs a multi-signature transaction, calls the smart contract’s mint token function, and sends the newly minted stablecoins to the customer’s pre-registered and verified wallet address.

3. Redemption (destruction) mechanism

Regulatory Directives

Licensees must process valid redemption requests “as soon as practicable and within one business day of receipt of the request”12. Withdrawals of reserve assets must be “matched by a corresponding reduction in the par value of the designated stablecoin in circulation”13.

SlowMist Technology Explanation

Redemption is a two-step process involving on-chain and off-chain interactions. During the redemption process, considering the risk of failed fiat transfers, token destruction must be performed after the fiat settlement is confirmed, not before. This protects the issuer from prematurely destroying tokens due to a redemption that ultimately fails.

If the issuer destroys the tokens first and the bank transfer fails, it will incur liabilities without corresponding assets; conversely, if the issuer pays fiat currency first but fails to destroy the corresponding tokens, it will also suffer losses.

Therefore, in the redemption operation, the user needs to transfer the token to a designated address controlled by the issuer, and then the issuer will destroy it after completing the fiat currency payment. This model allows users to "lock" their tokens for redemption, and the issuer will only destroy the tokens after fulfilling the fiat currency payment obligation, thus providing a safer operation process for both parties.

Implementation Guide

Redemption preparation: Users first need to transfer the tokens to be redeemed to a designated address controlled by the issuer.

Operation process:

• Off-chain request: The user submits an off-chain redemption request through the issuer’s platform. Before processing the request, the issuer must conduct appropriate customer due diligence (CDD) on the customer.
• 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 the chain.
• Fiat currency payment: The issuer transfers the equivalent amount of fiat currency to the user's pre-registered and verified bank account.
• On-chain destruction: After confirming that the fiat currency transfer is successful, the multi-signature wallet holding BURNER_ROLE calls the destruction function to destroy the corresponding number of tokens from the specified address.

4. Implement emergency controls: suspension and freeze

Regulatory Directives

The contract must support actions such as pause, resume, blacklist, unblacklist, freeze, and unfreeze. These are key components of the incident management framework14.

SlowMist Technology Explanation

The regulatory document lists "pause" and "freeze" as two separate items, indicating that regulators expect issuers to have flexible, layered incident response capabilities. A pause is a means of responding to major crises (such as contract exploitation), while a freeze is a precise tool for dealing with specific legal or compliance issues (such as a court order against a single account). The two are functionally distinct and must be implemented separately:

• Pause: A global "emergency stop switch" that instantly stops all core functions of the contract, including transfers, minting, and destruction.
• Freeze: An account-level restriction that prevents a specific address from sending or receiving tokens, but does not affect the normal activity of other addresses in the network.

Implementation Guide

Pause function: Only called by a multi-signature wallet holding the PAUSER_ROLE, it is used to globally suspend the contract function. Trigger conditions include the detection of abnormal events (such as network attacks or reserve asset mismatches), which require approval from the board of directors or senior management. The recovery function is handled by a separate RESUME_ROLE to achieve separation of duties.

Freeze function: Called by a multi-signature wallet holding FREEZER_ROLE to restrict transfers to a specific address. Trigger conditions include suspicious activities (such as AML alerts or court orders), which require off-chain verification before execution. Unfreezing is handled by the same role, but requires additional audit verification and related announcements to prevent abuse.

5. Address screening and blacklist mechanism

Regulatory Directives

Licensees should take steps such as “blacklisting wallet addresses identified as sanctioned or associated with illegal activity”15. This is a core control for ongoing monitoring and issuers should employ technical solutions such as blockchain analysis tools to identify transactions associated with illegal or suspicious activity16.

SlowMist Technology Explanation

This must be an on-chain enforcement mechanism. It is not enough to simply issue a warning off-chain, the transaction must be prevented from occurring at the protocol level. The blacklist requirement requires licensees to adopt real-time blockchain analysis tools/services (such as MistTrack, Chainalysis, Elliptic). The compliance team uses the conclusions drawn by these tools to securely transform transactions signed by multiple signatures to update the on-chain blacklist.

Implementation Guide

• Function implementation: Functions that implement blacklist addition and blacklist removal, and can only be called by a multi-signature wallet holding BLACKLISTER_ROLE.
• Transfer restriction: blacklisted addresses are prohibited from transferring/receiving tokens.
• Operation process: The analysis tool issues an alarm, triggering an internal compliance review. After the compliance team reviews and confirms, the BLACKLISTER_ROLE multi-signature wallet initiates a blacklist addition transaction.

6. Upgradability of Smart Contracts

Regulatory Directives

All smart contract architectures related to stablecoins may adopt “upgradeability”17. Whenever a smart contract is “upgraded”, it must be audited18.

SlowMist Technology Explanation

Upgradability by design is a core requirement for technical flexibility and risk management in the regulatory framework. It allows issuers to update logic without disrupting the existing contract status to respond to bug fixes, functional expansion or regulatory changes.

However, this also brings high risks: the upgrade process can be abused, causing unexpected changes in contract behavior or introducing new vulnerabilities. Therefore, upgrades must be treated as high-risk operations and should be designed to prevent unilateral execution by a single party (such as through multi-signature protocols) and integrated with role-based access control systems (RBAC).

The audit requirements emphasized by regulators mean that upgrades are not just code replacements, but also controlled events embedded in strict change management processes to ensure that new logic contracts are verified by third parties before deployment and are free of vulnerabilities or security flaws.

Implementation Guide

• Proxy model: For EVM-type smart contracts, the mature ERC-1967 proxy model can be adopted to achieve upgradability.
• Permission control: The upgrade function must only be called by a multi-signature wallet holding UPGRADER_ROLE.
• Change Management Process: In line with regulatory requirements, a rigorous change management process must be completed before any upgrade is proposed, which includes a comprehensive, independent, third-party security audit of the new logic contract.

7. On-chain event log for analysis and reporting

Regulatory Directives

Licensees must establish robust “information and accounting systems” to “record all business activities, including both on-chain and off-chain information, in a timely and accurate manner” and “maintain appropriate audit trails”19.

SlowMist Technology Explanation

Smart contracts are the primary source of truth for all on-chain activity. They must emit detailed events for every significant state change so that off-chain systems can log, monitor, and generate reports. These events create an immutable and permanent log on the blockchain. This log is the primary data source for all off-chain monitoring, accounting, and reporting systems, providing a solid foundation for audits.

Implementation Guide

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

• Token Minting / Burning Events
• Contract Paused / Resume Event
• BlacklistAdded / BlacklistRemoved events
• WhitelistAdded / WhitelistRemoved events
• AddressFrozen / AddressUnfrozen Events
• RoleGranted / RoleRevoked events
• Contract Upgrade (Upgraded) Event

Part III Operational Safety and Lifecycle Management

This section details the critical operational security procedures surrounding smart contracts. These procedures are just as important as the code itself and are necessary to achieve comprehensive security and compliance.

1. Secure key management architecture

Regulatory Directives

This is one of the most detailed and stringent areas of regulation. Licensees must implement strong controls over the entire lifecycle of private keys, including generation, storage, use, backup, and destruction20. “Important seeds and/or private keys” (e.g., keys used for upgrades, role management, large-scale coin minting) require a higher level of security standards, including offline generation in an “air-gapped environment”21 and storage in a hardware security module (HSM)22.

SlowMist Technology Explanation

The HKMA is essentially asking for a “traditional finance level” security posture to be applied to crypto-native operations. The cost and complexity of implementing this level of key management is enormous and will become a core operational part of any licensed issuer. This security model goes far beyond the standard practices of typical DeFi projects. The regulatory document provides a detailed checklist for key management, explicitly mentioning HSM (hardware security modules), air-gapped environments, key ceremonies, and multi-signatures. This effectively mandates the construction of a defense-in-depth key management architecture: accounts held in hardware wallets act as signers of multi-signature wallets, which themselves hold administrative roles on smart contracts. For the highest security roles, these hardware wallets themselves must be managed in a designated, physically secure, air-gapped environment. The entire architecture builds a multi-layered defense system to resist key compromise.

Implementation Guide

• Key generation: must be completed through a well-documented “key ceremony”23 in a physically secure, air-gapped environment that is completely isolated from the outside world.
• Key storage: All administrative roles must be controlled by a multi-signature wallet. The private keys used by the signers of these multi-signature wallets must be stored in an HSM or other secure hardware wallet. For the most critical roles, their corresponding keys must be kept in an air-gapped system, physically isolated from any online environment.
• Key usage: Multi-signature policies must be enforced. For transaction signatures involving “important private keys”, the relevant personnel may need to be present in person24.
• Backup and Recovery: Backups of key shards or mnemonics must be stored in multiple secure and geographically dispersed locations within Hong Kong (or regulatory-approved locations) and in tamper-resistant packaging25.

2. Complete deployment process and runtime monitoring

Regulatory Directives

Licensees must engage a “qualified third-party entity to audit smart contracts” at least annually and upon each deployment, redeployment or upgrade. The audit must ensure that the contract is implemented correctly, functions as expected, and does not contain any vulnerabilities or security flaws “at a high level of confidence”26. Licensees should implement measures to monitor the use of mnemonics and/or private keys (e.g. IP checks, behavior monitoring, critical activity alerts, device screening, on-chain monitoring, access control monitoring, etc.)27. And licensees should take appropriate measures to monitor threat intelligence to detect emerging threats. Threat intelligence should be analyzed so that mitigation measures can be implemented in a timely manner28.

SlowMist Technology Explanation

The deployment process and runtime monitoring are direct extensions of the regulatory framework for technical risk management, emphasizing the prevention of vulnerabilities at the source and continuous monitoring of operational risks. Pre-deployment audits require that smart contracts be treated as critical infrastructure and must be ensured to be defect-free through multiple layers of verification (such as unit testing, independent audits, and code freezes), which reflects the regulatory pursuit of "highly trusted" standards to avoid code defects or vulnerability 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 behavioral analysis) and threat intelligence analysis to form a closed-loop response mechanism. This not only meets the needs of the incident management framework, but also ensures that the system can dynamically respond to emerging risks. Overall, the technical implementation of this part needs to integrate on-chain and off-chain tools to form a traceable audit trail, thereby transforming passive defense into active compliance.

Implementation Guide

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

• Comprehensive testing: Ensure that the unit test coverage is above 95%, the core code coverage is 100%, and ensure the output of unit test coverage reports.
• Independent Audit: Complete at least one, and preferably two, independent security audit reports from reputable audit firms.
• Code freeze: After the audit is completed, the code will be frozen until it goes online, and no code changes will be made.
• Regression testing: Before official deployment, perform unit testing and regression testing.
• Compliance Sign-off: Obtain formal sign-off from the internal compliance team to confirm that the contract logic meets all relevant regulatory requirements.
• Deployment drill: Prepare detailed deployment scripts and conduct a complete deployment drill on a testnet that is exactly the same as the mainnet environment.
• Authorized deployment: The final deployment operation is performed by the authorized wallet.

After deployment, appropriate monitoring measures should be implemented to monitor the use of privileged roles and implement mitigation measures for emerging threats:

• On-chain activity monitoring: Monitor the usage of management roles (for example, use the SlowMist security monitoring system MistEye to add key role activity monitoring) to promptly detect unauthorized situations.
• Threat intelligence monitoring: Emerging threats should be detected promptly (for example, using the threat intelligence subscription of SlowMist security monitoring system MistEye), and the threat intelligence should be analyzed so that mitigation measures can be implemented in a timely manner.

3. Provide technical support for business continuity and exit planning

Regulatory Directives

Licensees must prepare a “business exit plan to effect the orderly wind-down of their licensed stablecoin business”29. This plan must include procedures for liquidating reserve assets and distributing proceeds to holders.

SlowMist Technology Explanation

This means that smart contracts must consider their own "retirement" process from the beginning of their design, and they need to have states and mechanisms that enable orderly shutdown. The requirement for an exit mechanism means that the life cycle of a smart contract does not end at deployment, but must have a clearly defined, protocol-level "end of life" protocol. This is a novel concept for many developers who are accustomed to building "perpetual" contracts, and it has also promoted a "design for termination" mindset. An orderly liquidation process requires a clean, final, and undisputed record of who owns what at the moment of shutdown. This goal will be difficult to achieve if the shutdown is carried out in a chaotic state where transactions are still ongoing. Therefore, a function that can freeze the state of the contract is a direct technical manifestation of this regulatory requirement. The on-chain state thus becomes the final, auditable source of truth in the hands of the liquidator.

Implementation Guide

Develop a business exit plan: The plan covers the various scenarios that could lead to an orderly termination and includes measures to monitor the actual or potential occurrence of these scenarios.

On-chain exit process 30:

• Smart contracts should be suspended to stop all token transfers to ensure maximum reserve asset liquidation gains and minimize impact on overall market stability.
• Relying on the redemption function and whitelist function, assist stablecoin holders to submit redemption applications.

Appendix to Part IV: Cross-reference Table of Regulatory Requirements

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

Related Materials

[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/20250526_Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.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/20250526_Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf

References

[1]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5

[2]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5

[3]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3

[4]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3

[5]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.4

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

[7]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3

[8]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.4

[9]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 10, 3.1.1

[10]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 12, 3.4.1

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

[12]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 11, 3.2.3

[13]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 11, 3.2.5

[14]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 38, 6.8.2

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

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

[17]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.2

[18]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5

[19]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 51, 8.1.1

[20]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 22, 6.5.8

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

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

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

[24]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 24, 6.5.8(vii)

[25]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 25, 6.5.8(x)

[26]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5

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

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

[29]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 42, 6.8.16

[30]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 42, 6.8.16