What the SFC generative AI requirements cover
Hong Kong licensed corporations (LCs) using generative AI in their regulated activities need controls for senior management oversight, model risk, cybersecurity and data, and third-party providers. The Securities and Futures Commission’s (SFC) 12 November 2024 circular sets out those four core principles. Buying a tool from a vendor, using an open-source model or having a person check its answers does not remove the firm’s responsibility.
This checklist is for compliance leaders, responsible officers and technology teams assessing an AI deployment. It covers the 2024 circular and relevant 2026 cybersecurity developments, checked against SFC primary sources on 30 October 2026. Customer due diligence, beneficial ownership and AML record-retention rules remain in our separate SFC AML requirements guide.
Paragraph 6 covers AI language models and AI-based third-party products used in relation to an LC’s regulated activities, including relevant activities of virtual asset trading platform operators (VATPs). The model may come from the firm, its group, an external provider or an open-source project. An internal workflow can be in scope; the test is not simply whether a client sees a chatbot.
A statutory duty is legally binding under legislation. An SFC expectation below is a regulatory requirement or supervisory standard expressed in a circular, often linked to the Code of Conduct or internal-control guidelines. The circular is not a standalone statute. The Code of Conduct states that it does not have the force of law, but paragraph 1.4 says the SFC considers whether a failure reflects adversely on fitness and properness. Guidance and illustrative examples help firms implement those standards. Our suggested owners, evidence records and test cases are good practice, not prescribed SFC templates.
Assessing AI-assisted KYC specifically? See how AgentKYZ combines case preparation with qualified human review, then use the checks below to assess the proposed deployment.
Effective dates and 2026 developments
- 12 November 2024: generative AI circular, effective immediately. Paragraph 31 requires firms to review existing controls and comply. The SFC’s stated pragmatic approach to assessment is not a fixed grace period or a deferred effective date. The June 2026 circular expressly refers firms back to this framework.
- 2 June 2026: AI-enabled cyberattack circular. It addresses LCs, SFC-licensed virtual asset service providers and their associated entities. It gives practical guidance and supervisory expectations on cyber preparedness, whether or not a firm itself uses generative AI. It specifies no separate future commencement date or universal numerical patching deadline. See paragraphs 1 to 8.
- 9 July 2026: internet-trading authentication circular. In-scope internet brokers and virtual asset service providers should implement robust authentication as soon as practicable, no later than 8 July 2027; large internet brokers are expected to do so immediately. Monitoring, notification and incident-response enhancements are expected immediately, with a pragmatic approach to system updates. Client awareness measures should follow as soon as practicable. These are distinct timelines in the implementation section.
- 29 July 2026: cross-sectoral Cyber Mapping results. This joint circular reports supervisory findings on interconnected systems and providers. It anticipates the next exercise starting in 2027/2028; it does not create a universal AI compliance deadline.
The SFC’s circular index is the place to check for subsequent publications. Do not use the July 2027 authentication deadline as permission to defer the 2024 AI controls.
Governance checklist: scope, accountability and notifications
For each numbered check, record done, gap or not applicable, the reason, an accountable owner, an evidence link and a remediation date. The evidence suggestions below are our working-paper format. Unless marked statutory duty or guidance, the checks summarise SFC expectations from the 2024 circular.
1. Identify the use case and assess its risk
Describe what the AI does, who uses its output and what an error could change. Apply controls proportionate to the impact and risk under paragraphs 6 to 8. Providing investment recommendations, advice or research to investors or clients is generally high-risk. Footnote 3 excludes after-sales client servicing from that description, but does not make every servicing tool low-risk.
An AI-generated KYC summary needs its own assessment. It is not automatically a high-risk investment-advice use case, nor automatically low-risk because a reviewer reads it. The 2024 appendix also urges extra caution with agentic AI, while recognising that it is not always high-risk if properly designed and implemented.
Suggested owner: business lead with compliance and risk. Keep a use-case record showing the permitted tasks, users, data, model, risk assessment and approval boundaries. A use-case register is our recommendation; it complements the specific software inventory required under paragraph 28.
2. Put competent people in charge throughout the lifecycle
Confirm that senior management oversees development, validation, approval, monitoring, use and retirement. Business, risk, compliance and technology staff need relevant competence; legal and compliance should assess whether deployment could undermine other obligations. Delegating validation to a group company leaves the LC accountable. For delegated functions involving high-risk use cases, ensure sufficient local management oversight and ongoing monitoring of the deployment. See paragraphs 9 to 12.
Suggested owner: accountable senior manager. Keep approved policies, responsibilities, staff training records and approval minutes. Existing enterprise-wide cybersecurity, data and provider-risk frameworks can cover the requirements: footnote 13 does not require duplicate AI frameworks.
3. Assess notification duties before changing the business
Statutory duty: paragraph 30 and footnote 23 remind firms planning high-risk AI uses of section 4 and Schedule 3 of the Securities and Futures (Licensing and Registration) (Information) Rules. These cover notification of significant changes to the nature of business and types of services. The SFC’s ongoing-obligations page lists a seven-business-day notification limit for those changes and requires submission through WINGS-LIC. Have compliance determine the trigger and applicable timing for the actual change, including any separate licensing conditions.
Guidance: early discussion with the SFC, preferably during business planning and development, is encouraged. That is distinct from the statutory notification and is not a blanket prior-approval requirement for all AI tools.
Suggested owner: compliance or the responsible officer. Keep the notification assessment, rationale, submission record where required and any SFC correspondence. Do not let the vendor decide whether your firm must notify.
Model-risk checklist: validation and human oversight
4. Validate the whole workflow before approving it
Test from user input to final output, including retrieval augmented generation (RAG), filters and prompt-management tools. Validate before use and after material changes; include cybersecurity and data controls. Document testing, calibration where performed, validation and monitoring results. See paragraph 13.
Where the firm develops or customises a model, separate Model Development from validation, approval and ongoing review where practicable, considering the use case and risk. Fine-tuning, RAG, content filtering and relevant tool integrations count as development under paragraph 14. Certain off-the-shelf configurations do not, but Model Management still applies under paragraph 15.
Suggested owner: model-risk or validation lead. Keep a test plan, acceptance criteria, results, defects and approval. Our suggested cases include conflicting source documents, missing evidence and equivalent questions phrased differently. Check citations against the documents: the appendix warns that RAG and citations can still be wrong. Vendor benchmark scores alone may be insufficient.
5. Apply high-risk review and client disclosures
For high-risk use cases, have a human review output for factual accuracy before it reaches the user, test robustness to prompt variations, and continue validation and monitoring to improve factual accuracy to a level commensurate with the use case. Footnote 16 allows the SFC to consider flexibility for particular circumstances; it is not a self-granted exemption. See paragraphs 18 and 19.
For AI used in the client interface, paragraph 17 calls for prominent disclosure that the client is interacting with AI and that its output may be inaccurate. For high-risk uses, make those disclosures whenever the client interacts with the AI, rather than only once upfront.
Suggested owner: business lead and compliance. Keep the review procedure, reviewer competence records, sampled decisions and copies of the disclosures in context. A qualified reviewer needs access to the underlying evidence and authority to reject an answer.
6. Monitor performance and control changes
Set ongoing reviews appropriate to the use case, including after market changes or new fine-tuning data. Revalidate material changes to design, assumptions, inputs, calculations or outputs. Continue testing high-risk deployments even with a human in the loop. Paragraphs 13, 16 and 19 also make clear that the LC remains accountable for output and should assess claims that a product eliminates hallucination.
Suggested owner: model owner with risk oversight. Keep performance results, failures, change assessments and approvals. As good practice, define thresholds for escalation or suspension, and require provider change notices so the firm can assess whether revalidation is needed. The circular does not prescribe a universal monthly or annual model-review interval.
Cybersecurity and data checklist
7. Control where confidential data goes
Encrypt non-public data at rest and in transit. Assess and mitigate risks from sensitive information entered in prompts or fed into the model, and from browser-extension leakage. Ensure training-data quality, identify and mitigate biases that could materially affect the use case, and maintain effective confidentiality controls throughout the lifecycle. See paragraphs 22 to 25. Paragraph 23 also points to the SFC’s data-risk circular and the Privacy Commissioner’s AI personal-data framework; AI controls do not displace applicable privacy law.
Suggested owner: data owner and information security. Keep a data-flow map and access-control assessment covering prompts, outputs, training data and services storing embeddings or vectors. Check provider terms for reuse of input data, including for training, as discussed in appendix paragraph 16. Our recommended evidence also includes agreed hosting, retention and deletion arrangements.
8. Test prompt injection and adversarial attacks
Cover attacks against the model and its training or fine-tuning data. Conduct adversarial testing periodically to the extent practicable. Paragraphs 20 and 21 address attacks that leak information, override system prompts, corrupt responses or execute malicious code.
Suggested owner: information security with the model owner. Keep test results and remediation records. Our suggested tests include an uploaded document instructing the model to reveal another client’s data, a retrieved webpage attempting to change system instructions, and a request to invoke an unauthorised tool. Test the application’s permissions as well as the model’s response.
9. Make suspension and incident escalation workable
Ensure intrusions can be identified promptly and model use suspended where appropriate under paragraph 20. The June 2026 circular adds explicit emphasis on rapid containment, regular incident exercises and recovery. Its paragraph 18 reminds firms to notify the SFC promptly of material cybersecurity incidents under the applicable Code of Conduct and VATP Guidelines. Code paragraph 12.5 requires immediate reporting for the events it specifies; do not wait for a completed root-cause report.
Suggested owner: incident-response lead and compliance. Keep an escalation tree, suspension procedure and exercise results. As good practice, test who can revoke a connector’s access, preserve evidence and move work to an approved fallback without waiting for the next management meeting.
Third-party AI and continuity checklist
10. Perform due diligence for your actual use case
Assess the provider’s skills, resources and controls, then monitor them. Where model transparency is limited, assess its risk-management framework to the extent practicable and test whether the output suits your use case. Assess privacy and intellectual-property exposure and the provider’s protections or indemnities. Ensure cybersecurity responsibilities are well-defined and clearly understood by the firm and provider. See paragraphs 26 and 27.
Suggested owner: vendor-risk lead with legal and information security. Keep the diligence assessment, assurance scope, contract and unresolved gaps. A certification or marketing statement does not establish suitability for your workflow. If a provider’s framework cannot be sufficiently assessed, footnote 21 says to reflect that limitation in mitigation, including monitoring depth and frequency.
11. Inventory the components, not just the model vendor
Assess supply-chain vulnerabilities and leakage at each relevant third-party component: embedding models, vector stores, prompt-management software, orchestration and evaluation tools. Maintain the third-party software inventory for cybersecurity monitoring required by paragraph 28.
Suggested owner: technology owner. Keep a dependency map, software inventory and ownership of each control. With open-source models lacking an identifiable provider, paragraph 26(b) still requires the other applicable controls; the absence of a vendor does not remove model-management responsibilities.
12. Prepare for provider failure or suspension
Assess dependence on provider availability and the operational impact of a disruption. Establish contingency plans, especially for critical operations, under paragraph 29.
Suggested owner: operations and business continuity. Keep the dependency assessment and contingency plan. Our recommended test is to disable the AI service in a controlled exercise and verify how staff retrieve records, complete urgent work and communicate delays. A second model is only a useful fallback if its data flows, permissions and output have also been assessed.
Add the 2026 cybersecurity controls
The 2 June 2026 circular addresses AI-enabled attacks against the firm’s systems as well as vulnerabilities in the firm’s own AI. Paragraph 3 places responsibility on senior management, including the Manager-in-Charge of Information Technology. Use these five workstreams alongside the model checklist:
- Patching and asset visibility. Maintain a sufficiently current asset inventory to support same-day prioritisation and containment decisions. Identify externally exposed, business-critical and third-party-dependent components. Review urgent patching outside normal cycles and the resources needed for a surge in fixes. Paragraphs 6 and 9 do not impose a universal same-day patch deadline.
- Access and privileged actions. Apply least privilege to connectors and tools; use network segmentation and microsegmentation where feasible. Treat retrieved documents, emails and webpages as potentially adversarial. Prevent them from changing system instructions or directly triggering privileged actions, and apply maker-checker controls to high-impact actions. See paragraphs 10 and 11.
- Detection. Strengthen anomaly monitoring for client trading and system activity, and improve threat-intelligence gathering. Paragraph 12 requires attention to the evolving threat environment, rather than reliance on an unchanged set of alerts.
- Supply chain. Update initial and ongoing assessments of providers supporting critical operations and business-critical components to cover AI-enabled threats. Paragraph 13 applies beyond the language-model supplier.
- Response and recovery. Review incident plans, consider pre-planned containment, test procedures regularly and protect backups under paragraphs 14 to 17. Footnote 8 specifies at least daily backups of the relevant records and data for LCs engaged in electronic trading and VATPs; do not generalise that provision to every firm.
The June appendix describes illustrative controls, including phishing-resistant multi-factor authentication (MFA) for privileged accounts, red-team exercises and incident-notification terms with providers. Its opening scope matters: LCs engaged in electronic trading, particularly large retail brokers, Type 13 depositaries and VATPs are generally expected to implement all the listed measures. Other licensed firms should consider them proportionately. Calling the whole appendix optional good practice would understate that distinction.
The separate 9 July authentication circular targets internet trading. Its definition includes Type 1, 2 and 3 internet brokers and Type 9 managers to the extent they distribute their funds through internet-based trading facilities, as well as SFC-licensed virtual asset service providers. It does not make every Type 9 manager an internet broker.
For client login and device registration or binding, the SFC does not consider one-time passwords (OTPs) a phishing-resistant solution. The circular gives passkeys and properly bound devices as examples of robust authentication, with the applicable additional factor. Existing bound devices do not have to be rebound. Plan against the 8 July 2027 outer deadline, the immediate expectation for large internet brokers and the earlier actions described above. Assess this separately from privileged-account controls in the June appendix.
Finally, the 29 July Cyber Mapping findings reinforce the value of mapping shared providers and dependencies. The authorities plan to use the results in supervision. Mapping concentration risk is useful for an AI dependency assessment, but this publication is not a new mandatory AI register or an instruction for every firm to submit a cyber map now.
Assess an AgentKYZ workflow against the checklist
AgentKYZ offers a practical starting point for AI-assisted KYC: agents prepare the case under your approved policy, qualified compliance reviewers check the evidence and reasoning, and your authorised team retains the decision. The case file brings together source documents, risk assessment, reviewer reasoning and an audit trail. See our workflow and review software.
Those features support human oversight and reviewable case evidence. They do not replace model validation, provider due diligence, cybersecurity testing or your firm’s regulatory notifications. AgentKYZ does not guarantee SFC compliance or approval, and is not endorsed by the SFC.
For a deployment discussion, bring one defined use case, its risk assessment, proposed data flows and the assurance evidence your control functions require. Ask to review the applicable hosting, access, retention and model-provider arrangements before transferring live files. Agree the tasks AI may perform, the reviewer’s responsibilities, exception handling and who can stop the workflow.
Explore human-reviewed KYC services for your Hong Kong firm. If your group also operates in Singapore, assess that entity separately using our MAS AI risk management guide; its implementation dates do not change the SFC’s requirements.