香港证监会第7类受规管活动牌照-提供自动化交易服务｜Type 7 Regulated Activity｜Type 7 自动化交易服务

本文由 仁港永胜（香港）有限公司 拟定，并由 唐生 提供专业讲解。

✅ 点击这里可以下载 PDF 文件：香港 SFC 7号牌：机构融资咨询牌照申请注册指南

✅ 点击这里可以下载 PDF 文件：香港 SFC 7号牌常见问题（FAQ ）

核心信息（“监管定位”）

1）牌照名称

• 牌照中文名称：第7类受规管活动牌照——提供自动化交易服务（Automated Trading Services, ATS）

• 牌照英文名称：Type 7 Regulated Activity – Providing Automated Trading Services

2）发牌 / 监管机构

• 证券及期货事务监察委员会（Securities and Futures Commission, SFC）

• 关键监管抓手：

  • SFO 第95条对“提供或要约提供 ATS”设有禁止性规定（除非获授权/持牌/注册）

  • ATS 提供者可走两条路径：

    • Part V：持牌/注册（Type 7）——常见于在港设立的持牌法团/注册机构

    • Part III：ATS 授权——常见于境外交易所/清算平台向香港提供接入的情形（监管会倾向要求 Part III 授权）

  • SFC 设有 Part III ATS 授权名册（Register）用于公众查询

3）牌照适用（典型业务模型）

Type 7（ATS）本质上是：向客户提供“买卖盘配对/撮合/执行/订单路由/交易后处理”相关的电子交易设施或服务，常见落地为：

• 电子撮合平台（MTF/另类撮合场所形态、但香港不直接使用欧盟术语）

• 经纪商/券商自建交易系统（DMA、智能路由、算法执行、程序化下单前端）

• 为市场参与者提供“交易设施”或“接入权”的系统（含远端接入）

• 清算/结算相关的自动化设施（视具体结构与功能边界而定，需做监管定性）

重要：若平台同时涉及证券交易（Type 1）或期货交易（Type 2）、或提供意见（Type 4/5/6/9）等，通常需要组合持牌（Type 7 并不天然覆盖“经纪业务/要约买卖”）。实务上“Type 7 只是系统牌照”，但业务链条往往还会触发其他 RA（后文第4章、第5章展开）。

4）牌照用途（落地场景）

• B2C：面向客户提供电子交易平台（需要强客户保护、风控、投诉、披露、适当性等全套）

• B2B：向券商/机构提供交易设施、API、接入、算法执行工具（更强调治理、系统稳健、准入、市场操纵防控）

• 跨境向香港提供 ATS：只要“积极营销至香港”，即可能构成“要约提供 ATS”并触发 SFO 第95条监管风险

0｜牌照基本信息（“定调商业计划书”的一章）

0.1 监管一句话定义（面谈必背）

• SFO 第95条：任何人不得提供或要约提供 ATS，除非其获 Part III 授权，或为Part V 持牌/注册（Type 7）等合规身份

• “要约提供”标准：若 ATS 服务积极营销至香港人士，即可能构成要约提供

0.2 监管对 Type 7 的核心关注（六大“高危点”）

1. 系统稳健与韧性（容量、延迟、灾备、监控、变更管理）

2. 市场公平与完整性（撮合规则透明、防操纵、防不公平接入）

3. 治理与问责（董事会监督、三道防线、MIC/RO 责任边界）

4. 客户保护（风险披露、适当性、投诉、记录保存）

5. 外包与第三方依赖（云、撮合引擎、KYC、监控工具、数据中心）

6. 网络安全与数据治理（渗透测试、权限分层、密钥/日志、事件响应）

SFC 可按个案要求对电子设施进行独立评估（independent assessment） ——这对 Type 7 项目非常常见（尤其是平台型 ATS）。

1｜牌照名称（中英文）

• 中文：香港证监会第7类受规管活动牌照——提供自动化交易服务

• 英文：SFC Type 7 Licence – Providing Automated Trading Services

2｜牌照介绍与申请优势（为什么要做 Type 7）

2.1 为什么市场需要 Type 7（商业驱动）

• 客户交易行为线上化：前端 App / Web / API 直连

• 机构交易算法化：VWAP、TWAP、冰山单、智能路由、风控前置

• 市场结构碎片化：多场所报价、多流动性源

• 监管趋势：要求平台具备可审计、可解释、可追责的交易控制体系

2.2 “含金量”体现在哪里

• 对外：银行、券商、流动性提供者、机构客户更愿意对接持牌 ATS

• 对内：能把“交易系统”从“IT 项目”提升为“合规产品”，降低系统性合规风险

• 对监管：Type 7 是“系统型牌照”，SFC 会把它当作市场基础设施/关键节点看待（要求明显高于纯咨询类牌照）

2.3 典型优势（对客户、银行、合作方）

• 客户：透明撮合规则、可追溯交易记录、投诉机制明确

• 银行：更清晰的 AML/KYC 接口与资金流、降低“未知交易平台”风险

• 合作方：对接标准化（API、报表、审计/渗透测试、BCP 证据链）

3｜监管机构与适用法律（必须掌握的法规清单）

3.1 核心法例 / 指引（ATS 专属与通用并行）

1. 《证券及期货条例》（SFO）第95条（ATS 禁止与合规路径）

2. 《自动化交易服务监管指引》（Guidelines for the Regulation of Automated Trading Services）（ATS 的治理/风险/系统标准）

3. 《持牌手册 Licensing Handbook》（申请、适当人选、财务资源、持续责任等）

4. 《胜任能力指引 Guidelines on Competence》（RO/代表的资历框架、考试/豁免逻辑）

5. 《证券及期货（财政资源）规则》（FRR）（资本金/流动资金计算口径与持续维持）

6. SFC 牌照申请网页与流程（WINGS/表格/递交逻辑等）

说明：ATS 项目在实务中还会叠加适用《操守准则》（Code of Conduct）、网络安全/外包/客户资产规则等（后文按模块落地）。

4｜许可范围与业务边界（“可做什么 / 不能做什么”）

4.1 Type 7 典型“可做”

• 提供撮合/配对引擎（订单簿或 RFQ/询价撮合等规则化机制）

• 提供电子交易系统与接入权（前端、API、终端）

• 提供订单路由/算法执行（属于交易设施功能的一部分时）

• 提供交易后生成报表、对账文件、审计追踪数据

4.2 Type 7 常见“不能单独做”（高频踩线）

• 不能单靠 Type 7 就对客户“招揽/建议/促成证券交易”：往往会触发 Type 1/2/4/5/6/9 等

• 不能把 ATS 当作“无监管的撮合市场”：撮合规则、准入、公平性、操纵监控必须制度化

• 若涉及虚拟资产交易平台：可能触发 SFC 的虚拟资产平台监管体系（并非仅靠 Type 7 即可覆盖）

4.3 “积极营销至香港”的跨境风险

• 指引明确：只要服务积极营销至香港人士，即可能构成要约提供 ATS，从而触发 SFO 第95条合规要求

5｜“大牌/小牌”与常见持牌结构（实务最关键）

这里的“大/小牌”是行业话术，监管并无正式概念。我们用“风险画像+业务链条”来拆解。

5.1 常见结构 A：纯系统 ATS（B2B）——“轻业务、重系统”

• 你提供：撮合引擎/接入/算法执行工具

• 你不做：对终端客户招揽、开户、收款、持有客户资产

• 关键：系统稳健、准入规则、公平撮合、日志审计、外包治理

5.2 常见结构 B：面向客户的 ATS 平台（B2C）——“重客户保护”

• 你提供：客户端下单、撮合、执行、交易确认

• 通常还会触发：客户适当性、风险披露、投诉、可能的客户资产安排

• 关键：KYC/适当性/产品治理/客户沟通/争议处理 + 系统全栈证据链

5.3 常见结构 C：券商/期货商 + ATS（Type 1/2 + Type 7）——“最常见组合”

• Type 7 的申请费/年费在特定情况下可被视为“附带”并获豁免（以官方口径为准）

• 关键：把“经纪合规”与“系统合规”拆开治理，但责任要闭环

6｜申请条件概览（监管看什么）

SFC 对 Type 7 的审查，实务上会围绕三句话：

1. 你是谁（股东/董事/UBO 是否适当人选，资金来源是否清晰）

2. 你怎么管（治理、内控、合规、风险三道防线是否真实可运行）

3. 你靠什么跑（系统是否安全稳定、是否可监控、是否可追责、是否可恢复）

Type 7（ATS）监管的本质：你是否向香港人士“提供/要约提供”具备交易功能的自动化设施（而不只是“有没有系统”）。SFC 在 ATS 监管指引中强调，ATS 涉及市场公平、系统稳健与潜在系统性风险，因此会按“市场设施”的思路审视：边界定性 + 治理问责 + 财政资源 + 系统证据链 + 监控与应急能力。

7｜资本金与财政资源要求（最硬的门槛）

7.1 法定最低资本金（Type 7）

根据 SFC 公布的最低资本要求表（对应 FRR 口径），Type 7：

• 最低缴足股本（Paid-up Share Capital）：HK$ 5,000,000

• 最低流动资本（Liquid Capital）：HK$ 3,000,000

实操提示：

• 不是“达到一次就完事”：是“持续维持”要求；一旦跌破必须内部升级、必要时通知与整改（并同步财务申报机制）。

• 新申请时，SFC 通常会要求你提供获牌后首6个月经营开支预测；若你的“超额流动资本”不足覆盖预测开支，需要给出明确的追加资金计划

7.2 财政资源规则（FRR）下的“隐性门槛”

• 流动资本的计算涉及资产折扣、扣减项目、或有负债等，不能用“账面现金”简单替代

• 若你同时持有多类受规管活动：以最高要求为准（不是相加，但取最高门槛）

7.3 建议资本配置（交付级建议）

• 最低法定门槛只是“入场券”，Type 7 平台型项目建议额外预留：

  • 12个月运营现金（人力+云+数据+安全+审计）

  • 第三方评估/渗透测试/灾备演练预算

  • 关键岗位（CO/MLRO/风控/IT Sec）薪酬缓冲

  • 重大事故应急资金池（法律/公关/取证）

8｜董事 / 股东 / UBO 适当人选要求

9｜合规、MLRO 与关键岗位（你必须配齐什么人）

9.1 必配角色（平台型 Type 7 的“底座人力”）

• RO（Responsible Officer）：至少2名，负责监督受规管活动（一般规则）

• MIC（Managers-In-Charge）：核心职能主管（管理问责框架，需清晰划分）

• Compliance Officer（CO）：合规负责人（可与RO部分重叠，但建议独立性设计）

• MLRO：反洗钱负责人（客户准入、交易监控、可疑报告机制等）

• Risk：风险管理（市场风险/运营风险/技术风险/模型风险）

• IT Security / CTO：信息安全与系统治理关键岗位（Type 7 属“系统高风险”）

9.2 三道防线（SFC 面谈“必问题”）

• 第一线：业务/产品/运营自控（订单、撮合、准入、客服）

• 第二线：合规+风险（规则、监控、审计追踪、报告）

• 第三线：内审/独立审查（年度审查计划、缺陷整改闭环）

10｜学历、经验、资质证书与考试要求（RO/董事/合规人员门槛）

10.1 Type 7 的考试要求（一个很多人会误解的点）

根据《胜任能力指引》对“本地监管框架论文（LRP）”及“认可行业资格（RIQ）”的摘要表：

• Type 7：No LRP requirement（无 LRP 要求）

• Type 7：No RIQ requirement（无 RIQ 要求）

解释（实务口径）：

• “无强制指定考试 ≠ 无门槛”。SFC 仍会通过面谈、履历、职责分工、过往经验来判断你是否具备“管理与监督 ATS 的能力”。

• 对平台型 Type 7，SFC 更看重：交易系统治理经验、市场微观结构理解、风控与监控体系、系统事故管理、外包治理能力。

10.2 RO/高管经验建议（交付级建议）

• 至少1名RO具备：交易系统/电子交易/算法执行/市场监控/风控相关的直接管理经验

• 若是面向零售客户的 ATS：RO/负责董事需有更强的客户保护与操守合规经验

• 董事会层面建议设置：技术委员会/风险与合规委员会（形成会议纪要证据链）

11｜ICT / 交易系统 / 安全与外包要求（Type 7 高风险监管点）

11.1 系统控制框架（监管要你证明“可控”）

SFC 对 ATS 的系统期望通常包括：

• 容量管理：峰值负载、压力测试、扩容机制

• 变更管理：版本发布流程、回滚方案、审批与审计轨迹

• 监控告警：延迟、撮合异常、拒单率、失败率、关键指标阈值

• 灾备与业务连续性（BCP/DR）：备份、热/冷切换、演练记录

• 日志与取证：订单全链路日志不可篡改、可回放、可审计

SFC 指引亦明确：ATS 提供者应具备备份与恢复设施、BCP，并进行定期测试；且 SFC 可视情况要求独立评估电子设施的完整性

11.2 外包治理（云/撮合引擎/安全服务）

• 外包不是问题，外包失控才是问题

• 必须形成：外包尽调、SLA、审计权、分包控制、数据主权、退出与替代方案

• 关键外包（撮合引擎、云基础设施、KYC、监控系统）建议：第三方审计报告 + 渗透测试 + 漏洞管理闭环

12｜客户保护机制（适当性、风险披露、客户款项隔离）

这一章取决于你的业务是否面向终端客户、是否触发其他 RA（如 Type 1/2）。这里给“Type 7 平台常见必备件”。

Type 7 的客户保护不是“可选项”，而是你能否获得银行、托管、机构客户信任的核心底座；同时，一旦你在业务链条中触发经纪/招揽/分销/投顾，你必须把 适当性（Suitability）与披露义务一起做齐。

13｜是否可以持有客户资产？（你客户一定会问）

结论先说：Type 7 的本质是“交易设施/系统”监管，不天然等同“可持有客户资产”。
是否持有客户资产取决于：

• 你是否同时从事会触发“客户资产处理”的受规管活动（如 Type 1/2 经纪链条）

• 你的业务设计是否安排你托管资金/证券/虚拟资产

• SFC 是否给你施加“不得持有客户资产”的牌照条件（其他 RA 常见）

仁港永胜唐生建议：如果你希望走“纯系统型 ATS”，通常建议结构上避免客户资产进入你的账，把资金/资产托管放在受监管的银行/券商/托管机构体系中，以降低牌照条件与持续合规负担。

13.1 监管答案的“正确说法”

• Type 7 是“设施型”牌照，并不天然等同“可以/必须持有客户资产”。

• 是否可持有，取决于你的业务链条是否同时触发：经纪（Type 1/2）、托管/客户资产规则安排、以及你与有联系实体/外包方的实际控制关系。

13.2 实务上最稳的两种结构（并说明利弊）

结构 A：纯设施（不碰客户钱/币/证券）（更易控合规成本）

• 你只提供接入、撮合规则、监控与日志

• 客户资产由受监管机构/托管方/券商/银行体系持有

• 优点：持续合规压力较低；银行与机构更易接受

• 风险：你仍需对“公平撮合、系统稳健、异常监控、事故处置”承担责任

结构 B：你持有客户资产（或你方 AE 持有）（合规重、审查深）

• 必须把客户资产隔离、对账、授权、访问控制、事件响应做成“强证据链”

• 银行开户、审计与监管问询会显著增加

• 若资产安排不清晰，极易被要求补件或被施加牌照条件

仁港永胜建议：除非商业模式必须，优先“纯设施+受监管托管/券商/银行”，先拿牌、再按路线图升级资产链条。

14｜申请流程与时序安排（建议按里程碑管理）

14.1 监管流程主线（按“能落地”的里程碑拆）

1. 定性与结构设计：确认是否仅 Type 7，或需叠加 Type 1/2/…

2. 治理与人事就位：RO/MIC/CO/MLRO/CTO/风控

3. 制度包与证据链搭建：合规手册、风控、外包、系统治理、BCP、监控

4. 系统说明书与测试证据：架构图、撮合规则、权限、日志、压力测试、渗透测试

5. WINGS 递交 + RFI 应对：按 SFC 问题清单“逐项闭环”

6. 获批后上线前检查：演练、监控、报表、事故响应、客户条款上线

申请程序与官方要求以 SFC 的申请页面与表格要求为准

SFC 企业持牌申请（LC）有其典型处理周期与关键影响因素（材料完整度、补件轮次、资本注入、人员签证、监管机构核查等）。Licensing Handbook 对处理时间与影响因素有明确描述。

14.1 建议里程碑（Milestones）——按“可交付件”推动审批

M0｜监管定性与结构确认（2–4 周）

• 输出：Perimeter Memo、业务边界表、牌照组合建议（Type 7 vs Part III / 是否叠加 Type 1/2 等）

M1｜公司与人员搭建（4–8 周）

• 输出：组织架构、RO/MIC 任命方案、三道防线、岗位 JD、值勤与替岗安排

M2｜制度包 + 系统证据链（6–12 周）

• 输出：ATS 治理制度包、信息安全、外包治理、变更管理、监控模型、BCP/DR 演练记录、测试报告、日志方案

M3｜WINGS 递交申请（T 日）

• 说明：自 2022 年起，电子表格与申报一般通过 WINGS 递交；SFC 的 Licensing forms 页面明确了相关安排。

M4｜RFI（补件）循环与面谈（8–20+ 周，视复杂度）

• 输出：RFI Answer Pack（“一问一包”）、系统演示脚本、证据索引表

M5｜原则性批准 → 上线前验收（2–6 周）

• 输出：上线验收清单（权限/密钥、监控阈值、客服投诉演练、事故演练复盘）

14.2 SFC 处理时间（官方口径）如何引用到你的项目计划里

Licensing Handbook 提供了新参与者申请处理时间的常用参考（例如 LC 约 15 周、RO 约 10 周等），并列明影响处理时间的因素（补件、人员变更、资本注入、外部监管查询等）。

15｜所需材料清单

15.1 公司与结构类

• 公司注册文件、章程、商业登记证

• 控股结构穿透图（到自然人）

• 董事/股东/UBO 身份与背景资料（含无犯罪/破产声明等）

• 资金来源说明（SoF/SoW）+ 支持文件

• 关联方清单（供应商、做市商、托管、银行、技术服务商）

15.2 人员与胜任能力类

• RO/MIC 任命文件、职责分工矩阵（RACI）

• 履历（突出 ATS/系统治理/交易风控经验）

• 关键岗位岗位说明书（JD）与汇报线（组织架构图）

• 合规培训计划与记录模板

15.3 业务与产品类（商业计划书 BP）

• 业务模式说明（B2B/B2C、目标客户、营销方式）

• 撮合规则与交易流程（端到端流程图）

• 费用模型与利益冲突披露

• 客户协议/平台规则/风险披露文件（草稿可先递交）

15.4 系统与安全类（Type 7 最核心）

• 系统架构图（逻辑/物理/网络分区）

• 撮合引擎说明（订单类型、优先级、成交规则、异常处理）

• 权限分层与最小权限原则（含管理员双人复核）

• 日志与审计追踪（订单全链路、不可篡改策略）

• 压力测试报告、容量评估

• 渗透测试与漏洞修复闭环

• BCP/DR 文件与演练记录

• 事件响应预案（含重大事故上报机制）

15.5 合规与风控制度类

• AML/KYC/CFT 政策（若你接触客户或触发 AML 义务）

• 市场操纵与异常交易监控规则（监控指标、阈值、处置流程）

• 投诉处理机制

• 外包管理制度（尽调、SLA、审计权、退出方案）

• 记录保存制度（订单、通讯、系统日志、变更记录）

16｜官方收费与预算（官费 + 常见配套成本）

16.1 SFC 官费（核心摘录）

• 持牌法团申请（Types 1/2/4/5/6/7/8/9/10）：HK$4,740 / 每类 RA

• 申请成为 RO：HK$2,950

• 年费：持牌法团 HK$4,740 / 每类 RA（Type 7 在特定情况下可获“附带”豁免）

• Type 7 的申请费/年费豁免场景：若 Type 7 属于对 Type 1 和/或 Type 2 的“附带/从属”业务，可按 SFC 公布口径处理

16.2 常见第三方成本（Type 7 必备预算）

• 系统渗透测试/安全评估（按系统复杂度）

• 压力测试与容量评估

• 外包与云合规审计支持（含 SLA/控制映射）

• 法律文件（客户协议、平台规则、风险披露）

• 审计与会计（持续合规、FRR 计算支持）

17｜银行开户（实操要点）

Type 7 项目开户难点通常不在“公司文件”，而在：

• 业务是否清晰、资金流是否可解释

• AML/KYC 是否能落地（客户来源、交易目的、监控、制裁筛查）

• 交易对手与地区风险（是否涉及高风险司法辖区）

• 系统安全与事故应对（银行会看你的安全治理成熟度）

仁港永胜唐生建议：准备一套“Bank Pack”——业务流程图、资金流图、KYC/AML 摘要、系统安全摘要、关键人员履历与治理架构。

17.1 你必须提前把“银行开户”纳入申请关键路径

Licensing Handbook 明确：SFC 在批出公司牌照前，需要申请人提供银行账户资料（不一定递交时就要，但必须在批准前提供），并提示要预留开户时间。

17.2 银行最关注的 10 个点（Type 7 典型）

1. 牌照范围与业务边界（是否触发经纪/VA/跨境招揽）

2. 控股结构穿透到自然人、SoF/SoW 证据链

3. 客户资产是否入账、是否设隔离/信托账户安排

4. AML/KYC 与制裁筛查（即便“纯设施”，也要能解释客户准入与异常升级）

5. 交易监控（操纵/异常/高频/刷单等）与取证能力

6. 外包与云（审计权、退出方案、分包控制）

7. BCP/DR（RTO/RPO、演练记录）

8. 财政资源（持续满足 FRR）与预算

9. 关键人员履历（RO/MIC）与值勤机制

10. 客诉处理与重大事件处置机制

17.3 开户“材料包”建议（直接可用）

• 公司文件：CI/BR/NNC1/NAR1、章程、董事/股东名册

• 业务文件：BP、收费表、客户类型、地区限制、合同样本、风险披露

• 合规文件：AML/KYC、制裁筛查、交易监控 SOP、客诉 SOP

• 技术文件：系统架构图、日志与审计追踪、DR 演练报告

• 财务文件：预算、现金流预测、资本注入证明、FRR 计算样表

18｜后续维护与持续合规（拿牌只是开始）

• 持续维持资本金/流动资本：Type 7 维持 HK$5,000,000 paid-up share capital 与 HK$3,000,000 liquid capital 的底线要求

• 年度费用与逾期罚则：逾期会有附加费并可能影响牌照状态（持牌手册对逾期后果有明确提示）

• 重大事项通知：董事/股东/业务模式/外包/系统重大变更需设内部触发机制

• 定期测试：BCP/DR 演练、漏洞扫描、权限审查、监控模型回测

• 记录保存：订单、撮合、通讯、变更、事故、客户投诉等形成“可审计闭环”

19｜项目实操建议（“三阶段法”）

阶段一：定性与结构（把牌照范围一次定对）

• 先做 Reg perimeter：Type 7 是否足够？是否触发 Type 1/2/…

• 明确客户资产是否进入你体系（决定合规强度与持续成本）

阶段二：制度+系统证据链（监管看你“能不能控”）

• 用“证据链”写制度：每条制度都要对应日志/报表/审批记录

• 系统以“可审计”为核心：订单全链路、撮合规则固化、异常可回放

阶段三：递交与 RFI（把问答当成项目交付）

• 预设问题库：撮合规则、监控指标、外包控制、事故处理

• 用“RFI-ready 文件夹结构”管理材料：一问一包，一包可复用

20｜监管审查重点矩阵（按此做“证据链”）

仁港永胜唐生拟定的一份“监管关注点 → 你要交付的证据”映射（建议你做成项目检查表）：

1. 撮合规则公平性 → 撮合规则文件、订单类型说明、优先级、异常处理、回放样例

2. 准入与权限 → 客户/会员准入规则、权限矩阵、管理员双人复核、访问日志

3. 市场操纵防控 → 监控指标清单、阈值、处置流程、案例演示

4. 系统韧性 → 压力测试、容量评估、BCP/DR、演练记录

5. 变更管理 → 发布流程、审批记录、回滚方案、版本控制证据

6. 外包治理 → 尽调、SLA、审计权、分包控制、退出计划

7. 事故响应 → 事件分级、通报流程、取证与复盘模板

8. 治理问责 → 董事会/委员会会议纪要、RO/MIC 职责分工、三道防线文件

21｜（Type 7 ） 自动化交易服务 ATS 版 常见问题 FAQ｜Q1–Q150

本文由 仁港永胜（香港）有限公司 拟定，并由 唐生 提供专业讲解。

一、监管边界与“是否触发 Type 7 / SFO 第95条”（Q1–Q18）

Q1：Type 7（ATS）最核心的监管触发点是什么？
A：关键不在“你有没有系统”，而在你是否向香港人士提供或要约提供具备“接收订单、撮合/配对、执行、规则化处理交易指令”等功能的自动化交易设施。香港对 ATS 采取以 SFO 第95条为核心的禁止性框架：未获相应授权/持牌而提供或要约提供 ATS，会构成重大监管风险；其中“积极营销至香港”是常见触发因素。

Q2：什么是香港监管语境下的“自动化交易服务（ATS）”？
A：一般指通过电子方式提供交易设施/服务，使交易指令被接收、撮合、配对、执行或以规则化方式促成成交。香港监管重点不是你自称“交易所/平台/系统”，而是你是否实质提供交易设施并对市场公平、系统稳健与监控承担责任（以 SFC 个案定性为准）。

Q3：Type 7 是否等同“交易所牌照”？
A：不等同。Type 7 是受规管活动牌照（设施/系统维度）；而“认可交易所/市场营运者”等属于更高层级的市场基础设施监管谱系。实务上，若你是境外交易所类主体向香港提供接入，SFC 常倾向走 Part III 授权路径并列入名册，而非单纯 Type 7。

Q4：境外平台不在香港落地服务器，也需要管吗？
A：需要做“向香港要约”的判断。即使系统与人员在境外，只要你积极营销至香港人士或向香港开放接入（招商、平台开户、香港渠道合作等），仍可能触发第95条与 ATS 指引项下的监管关注。

Q5：什么叫“积极营销至香港人士”？有哪些常见证据？
A：常见证据包括：面向香港用户投放广告、香港媒体/路演、香港客户经理/客服、中文+港币计价营销、香港社群/KOL 渠道、允许香港手机号/IP 注册、在香港签约收款或承诺服务等。监管通常以“事实与整体印象”作穿透判断。

Q6：Type 7（ATS）与“电子交易平台/撮合系统”是同一概念吗？
A：高度重叠但不建议直接等同。你可能仅做订单路由/执行工具而未形成撮合；也可能形成撮合但同时触发 Type 1/2 等。应先做 Regulatory Perimeter（监管定性）：功能链条、客户对象、营销方式、交易规则、是否形成市场、是否涉及清算/对手方等。

Q7：只做“交易 API / Algo 执行”，不做撮合，也可能需要 Type 7 吗？
A：可能。若你的 API/Algo 使客户订单进入你的系统被规则化处理（智能路由、内部化执行、形成执行价格/成交确认、前置风控等），监管可能将其视为 ATS 组成部分；若只是客户自用工具且你不构成设施提供者，风险相对低，但仍建议形成书面定性备忘录。

Q8：我只是给券商提供撮合引擎（B2B），也算 ATS 吗？
A：可能算。B2B 不自动降低监管属性。只要你在链条中提供撮合/执行设施，仍可能触发 Type 7 或 Part III。监管更关注：谁对市场公平、准入、系统风险负责，以及是否构成关键基础设施。

Q9：系统只用于“内部自营交易”或集团内使用，还要牌照吗？
A：通常看是否对外“提供或要约提供”。纯内部自营一般不构成对外提供；但如集团成员以外部客户方式接入、对外营销或向香港客户开放注册，风险显著上升。建议明确使用主体范围、接入权限、营销边界与合同相对方。

Q10：ATS 是否只涵盖证券/期货？
A：ATS 是“设施型”概念，常与证券/期货交易相关；但若交易标的或安排触发其他监管框架（例如虚拟资产平台相关要求），会叠加更专门规则。实务必须先确认标的是否属证券/期货/受规管产品，再决定组合持牌路径。

Q11：ATS 是否包含清算/结算功能？
A：部分 ATS 会涉及交易后处理；若你具中央对手方（CCP）或类似清算角色，监管敏感度会明显上升，可能被视为更高层级基础设施并被施加更严条件。

Q12：只做“报价板/行情聚合/聊天室撮合”算 ATS 吗？
A：若只是信息展示而不形成规则化撮合与成交机制，通常较难定为 ATS；但若你通过规则/算法促成配对、提供下单与成交确认、或实质控制交易过程，则更接近 ATS。

Q13：只把香港客户导流到海外交易所（不直接撮合）是否安全？
A：不一定。若你在香港积极营销，并以你的名义要约提供接入/交易设施，仍可能落入第95条“要约提供 ATS”的讨论范围；导流还可能触发其他受规管活动（招揽/促成交易等）。建议穿透：谁签约、谁收费用、谁控制系统、谁承诺执行。

Q14：如何快速做一份“是否触发 Type 7”的内部定性结论？
A：建议四步：①画端到端流程（开户→下单→撮合/执行→确认→对账→争议）；②标注关键控制点（撮合规则、准入、优先级、异常处理、权限）；③列出对港营销与客户分布；④对照第95条/ATS 指引做风险评级并提出整改（不持客户资产、限制香港用户、调整合同主体等）。

Q15：SFC 如何区分“Type 7 持牌”与“Part III ATS 授权”？
A：一般而言：在港设立、以持牌法团/注册机构经营 ATS，多走 Part V Type 7；境外交易所/大型平台向香港提供接入，常见走 Part III 授权并列入名册。最终仍是个案定性。

Q16：在哪里查询已获 Part III 授权的 ATS 名录？
A：可在 SFC 公共名册查询 “Register of Automated Trading Services Authorized under Part III”。

Q17：若我先申请 Type 1/2，经纪业务附带系统功能，Type 7 是否仍需？
A：若系统功能构成“提供 ATS”，通常仍需涵盖 Type 7 或相应授权路径；但在费用处理上，若符合“附带活动（incidental）”的法定豁免/减免条件，Type 7 费用可能获豁免（以个案满足法例条件为前提）。

Q18：最常见的“踩线误区”是什么？
A：三类：①以为“服务器在海外/主体在海外=不监管”；②以为“白标/技术服务=不需要牌照”（但你实质控制规则与市场）；③以为“一张 Type 7 覆盖全链条”（忽略 Type 1/2/4/5/6/9 等组合触发）。

二、牌照范围、组合持牌与费用（Q19–Q30）

Q19：Type 7 牌照允许做什么？
A：核心是提供自动化交易设施：接收订单、撮合/配对、执行、规则化处理交易指令、向参与者提供接入与交易功能，并承担系统稳健、透明、公平、可监控等治理责任。

Q20：Type 7 不允许“单独”做什么？
A：Type 7 不天然覆盖经纪链条中的招揽/促成买卖（通常涉 Type 1/2），也不自动覆盖投顾/企业融资/资管（Type 4/6/9 等）。如你对客户提供交易建议、要约买卖或执行经纪服务，应评估组合牌照。

Q21：最常见的组合持牌结构有哪些？
A：常见三类：①Type 1/2 + Type 7（经纪/交易 + 设施）；②Type 7 + Type 4/9（平台叠加投顾/策略/资管工具——需谨慎定性）；③Part III 授权 + 香港持牌中介接入（境外平台授权，香港中介负责本地客户活动）。

Q22：Type 7 可否只做撮合，不碰客户资金？
A：可以，亦是降低合规负担的常见路径：资金/资产托管放在银行/券商/托管体系，你专注系统与规则治理。但仍需满足 Type 7 的资本、治理、系统稳健、监控与事故管理等要求。

Q23：Type 7 的申请费/年费是多少？
A：费用以《证监会费用规则/费用表》与 SFC 公布口径为准；同时需注意：历史上对部分牌照曾有阶段性年费宽免安排，具体以当期官方安排为准。就 Type 7 而言，法例层面亦存在在特定情形下与 Type 1/2 相关的 Type 7 费用豁免机制（见下一问）。

Q24：什么情况下 Type 7 费用可能豁免（incidental）？
A：若申请人已申请/持有 Type 1 或 Type 2，并且 Type 7 属其业务的附带活动，法例与 SFC 既有说明均显示：与 Type 7 相关的申请费及年费在特定条件下可被豁免（需严格按个案事实满足条件）。

Q25：什么情况下更难被认定为“附带活动”？
A：当平台本身是独立盈利中心、面向广泛客户开放接入、撮合规则与市场影响力独立存在、或你向其他中介提供设施服务时，更可能被视为独立 Type 7 业务而非附带。

Q26：Type 7 是否能用于虚拟资产交易平台？
A：若涉及虚拟资产且构成证券/期货或落入 SFC 虚拟资产平台监管框架，会叠加更专门指引与条件；不要假设仅靠 Type 7 可覆盖全部虚拟资产业务。

Q27：我能先以 Part III 授权方式提供 ATS，再转为 Type 7 吗？
A：路径上可能存在可行性，但取决于主体性质与业务安排。一般 Part III 更常见于境外设施提供者；若未来在港以持牌法团营运并承担本地合规责任，转为 Type 7 往往需重做组织、人员、资本与制度/证据链配置。

Q28：Type 7 能否外包给技术服务商，我只做市场与客户？
A：可外包部分 IT，但不能外包监管责任。你必须对权限、变更、监控、日志、事故响应、外包治理拥有可审计、可指挥、可恢复的控制力。

Q29：SFC 更偏好 B2B 还是 B2C 的 Type 7 模式？
A：监管不以 B2B/B2C 作为偏好，但风险画像不同：B2C 更重客户保护与投诉；B2B 更重准入公平、系统韧性、监控与治理问责。

Q30：只向专业投资者（PI）开放接入能否降低要求？
A：可在披露与客户保护安排上做差异化，但第95条触发、系统稳健与市场公平等核心原则不会因客户是 PI 而消失。

三、资本金、财政资源与预算（Q31–Q40）

Q31：Type 7 的最低资本金门槛是多少？
A：按 SFC 公布的最低资本要求表，Type 7（ATS）通常对应：最低实缴股本（Paid-up Share Capital）HK$5,000,000、最低速动资金（Liquid Capital）HK$3,000,000，并需持续维持。

Q32：为什么 Type 7 的资本门槛这么“硬”？
A：ATS 属可能影响市场公平与系统稳定的关键节点，监管逻辑更接近“市场设施”。资本门槛用于确保持续经营与事故承压能力，并支持系统安全、监控、灾备等长期投入。

Q33：Liquid Capital 为什么不能只看账户现金？
A：Liquid Capital 需按《财政资源规则（FRR）》口径计算，会对资产折扣并扣减非流动项目、或有负债与风险扣减，因此“账面现金/净资产”不等于合规 Liquid Capital。

Q34：资本金是申请时一次满足还是持牌后持续满足？
A：持续性要求。持牌后跌破门槛应触发内部升级、限制风险扩张、补充资本，并视情况与监管沟通。

Q35：多牌照（如 Type 1+7）资本金怎么计算？会叠加吗？
A：不宜简单相加，需按 FRR 规则结合业务结构与风险扣减模拟验证，避免“以为足够”。

Q36：监管会要求提交预算与财务预测吗？
A：常见会要求，特别是 Type 7 系统性投入高。建议准备 12–24 个月预算、现金流预测、资本补充安排与关键成本解释。

Q37：Type 7 项目最容易被低估的成本有哪些？
A：渗透测试与整改闭环、DR 演练与异地备份、日志存储与取证、监控告警与异常交易模型、外包审计权执行成本、法律文件（平台规则/风险披露/争议条款）、合规与内审资源。

Q38：资本金是否必须实缴？能否用股东借款替代？
A：最低 Paid-up Share Capital 以实缴股本为核心概念；股东借款可提供现金但未必满足“实缴股本”要求。应结合公司法与 FRR 口径设计并充分披露。

Q39：是否需要保证金或保险？
A：Type 7 没有统一“一刀切保证金”，但监管会关注运营风险承压能力。实务常用专业责任险、网络安全险、事故应急资金池增强可信度（视业务而定）。

Q40：如何建立“财政资源合规”内部控制体系？
A：建议至少：FRR 计算责任人/复核人（财务+合规双线）；预警阈值（如距门槛 20%）；重大支出资本影响评估；董事会/风委月度报表；跌破门槛紧急处置 SOP。

四、股东/董事/UBO 适当人选与治理（Q41–Q55）

Q41：SFC 评估股东/董事/UBO 的 Fit & Proper 看什么？
A：诚信声誉、财务稳健、能力胜任、合规/纪律记录、利益冲突与关联交易透明度。

Q42：UBO 穿透到什么层级？必须到自然人吗？
A：通常需穿透至最终自然人控制人，并解释控制链条、投票权、协议控制、代持安排等。Type 7 对影子控制/代持/对赌影响控制权更敏感。

Q43：资金来源（SoF/SoW）为何是高频追问？
A：Type 7 常涉及较高资本与系统投入，监管关注资金合法性、可解释性与持续性。建议“叙事+证据”：资金路径图+银行流水/证明+审计/纳税/股权交易文件等。

Q44：董事会治理需要做到什么程度？
A：以“可追责”为核心：董事会对系统风险、市场公平、外包、事故管理的监督责任清晰；设风险/合规委员会或等效机制；保留纪要、决议与整改跟踪形成证据链。

Q45：MIC（Managers-In-Charge）框架与 Type 7 有何关系？
A：MIC 用于明确核心职能负责人。Type 7 更应把“谁负责系统、监控、外包、事故上报与决策”写清并可落地执行。

Q46：三道防线如何落地？
A：第一线（业务/运营/IT 控制）、第二线（合规+风险）、第三线（内审/独立审查），并固化为可审计记录（报表、纪要、整改单）。

Q47：关联方（做市商/技术供应商等）带来哪些治理风险？
A：利益冲突、撮合偏置、信息优势、前置交易、权限滥用、数据泄露。建议：利益冲突政策、隔离机制、参数变更双人复核、访问日志审计。

Q48：是否必须有香港实体与本地管理层？
A：走 Type 7 持牌法团路径通常需香港公司架构与可履职管理层（RO/MIC 等），监管亦看重实质经营与可追责性。

Q49：可否集团共享合规/共享 IT 安全？
A：可，但需证明资源可用、职责明确、冲突可控、服务可审计，且香港实体对关键事项有指挥权与最终责任。

Q50：RO 是否必须是董事？
A：不一定，但 RO 必须有充分授权与实际监督能力；建议建立 RO→董事会直达汇报线，确保重大系统风险及时升级。

Q51：股东是基金/信托结构会更难吗？
A：不必然更难，但披露、穿透、控制权解释与 SoF/SoW 证据要求通常更高。

Q52：SFC 会关注 wind-down（退出/终止服务）计划吗？
A：会。ATS 属关键设施，需说明终止或重大事故时如何保护客户、处理未结交易、保存记录、通知参与者与监管，并可做情景演练。

Q53：是否需要外部审计或独立评估？
A：财务审计属常规；系统层面，SFC 可按个案要求对电子设施做独立评估，尤其平台型/重要性较高的 ATS。

Q54：治理文件写得漂亮但系统没实现会怎样？
A：RFI 会要求你用日志、测试、演练、变更记录等证明已实施；制度与系统能力不匹配会削弱审批信心。

Q55：推荐的治理产出清单？
A：董事会/委员会章程、RO/MIC 职责矩阵、三道防线框架、风险偏好声明、外包治理政策、事故响应政策、变更管理政策、年度合规与内审计划、纪要与整改台账模板。

五、关键人员、胜任能力与考试（Q56–Q65）

Q56：Type 7 是否有强制指定考试要求？
A：Type 7 在考试维度通常不像部分 RA 有“必须通过某张指定试”的硬性门槛，但这不等于门槛低——SFC 会以经验、职责、系统治理能力与面谈问答作胜任判断。

Q57：没有指定考试，RO 的能力证明怎么做？
A：建议“三件套”：①经验叙事（电子交易/市场结构/系统治理/风控）；②职责与监督安排（如何监督系统、监控、外包、事故）；③系统证据链演示（订单回放、权限审计、异常处置、DR 记录）。

Q58：RO 最好具备哪些背景？
A：优先组合：至少 1 名偏交易/市场运作/合规经验；至少 1 名偏系统治理/信息安全/高可用架构经验；若 B2C，还需客户保护与投诉治理经验。

Q59：CO/MLRO 可否与 RO 兼任？
A：可行但需评估规模与独立性。Type 7 属系统高风险，如一人多岗导致监督失效，监管可能要求加强资源配置。

Q60：IT 安全负责人一定要在香港吗？
A：未必一刀切，但监管看“关键控制是否在香港可追责、可面谈、可即时指挥”。海外团队需证明 7x24 响应、权限在持牌实体可控、事故升级路径清晰。

Q61：是否需要独立内审？
A：成熟平台建议设第三道防线。规模较小可外部独立审查，但必须有年度计划、抽样测试与整改闭环证据。

Q62：关键岗位离职/更换会影响牌照吗？
A：会触发合规动作：职责交接、权限回收、必要时监管通知、重新任命与胜任证明。Type 7 更要管好密钥与高权限回收审计。

Q63：平台是否需要 7x24 运维与监控？
A：视交易时段与 SLA，但监管通常期待交易时段具有效监控、响应与处置能力；宣称高可用却无值班机制会被质疑。

Q64：外包 SOC 监控可以吗？
A：可以，但需外包治理到位：审计权、SLA、分包控制、事件响应时限、数据访问控制、退出迁移方案，以及你方对重大事件最终决策权。

Q65：最容易被忽略的人员证据是什么？
A：岗位说明书与授权范围、汇报线、值勤/替岗安排、培训与考核记录、关键操作双人复核、离职权限回收清单。

六、系统、网络安全、外包、BCP/DR（Q66–Q82）

Q66：为什么 Type 7 被称为“系统高风险牌照”？
A：监管对象是交易设施本身，系统故障会直接影响公平成交与市场秩序。ATS 指引核心围绕：稳健性、容量、可用性、控制、透明规则、监控与事故管理。

Q67：最低系统控制能力应包括哪些？
A：容量管理与压力测试、变更管理与版本控制（含回滚）、权限分层与最小权限、全链路日志与可回放、告警监控与异常处置、BCP/DR 与演练记录。

Q68：撮合规则需要披露到什么程度？
A：至少可让客户/参与者理解：优先级、拒单/撤单/部分成交、异常行情处理、系统故障处理、争议回放机制；内部需更细的参数与阈值管理，并保证版本可追溯、变更可审计。

Q69：平台提供 API 给量化客户会被重点看什么？
A：公平接入+风险前置：限流与前置风控、密钥与权限管理、对刷单/幌骗/操纵的监控、日志可回放与取证、kill switch 与紧急停用机制。

Q70：系统放云上是否可行？
A：可行，但云往往是审查重点：云架构安全、数据治理、权限控制、外包审计权、分包控制、退出迁移方案、灾备演练与 SLA 可执行性都要能证明。

Q71：是否必须做到不可篡改日志（immutable logs）？
A：监管强调可追溯、可审计、可回放。最佳实践：WORM/哈希链/集中日志+权限隔离+访问审计。缺乏可信日志会导致成交争议无法解释。

Q72：渗透测试与漏洞管理要多频繁？
A：建议至少年度全面测试+重大变更后专项测试，并形成闭环证据（发现→评级→修复→复测→关闭）。

Q73：外包合同必须有哪些条款？
A：服务范围与 SLA、信息安全要求、审计权（含现场/远程）、分包限制、数据主权与访问控制、事件通知时限、整改配合、BCP 支持、退出迁移协助、责任与赔付。

Q74：第三方撮合引擎是“黑盒”可以吗？
A：高度不建议。你必须能解释撮合逻辑并对关键参数与变更有控制权与回滚能力；黑盒会导致公平性、复盘与审计无法证明。

Q75：系统变更管理要有哪些证据？
A：变更申请单、风险评估、审批记录、测试报告、上线窗口、回滚方案、上线后监控报告、问题单与修复记录；紧急变更需事后补批机制。

Q76：BCP/DR 要做到什么程度？
A：至少 RTO/RPO、备份策略、主备切换机制、演练脚本与演练记录、复盘整改闭环；ATS 指引强调备份恢复与定期测试。

Q77：宕机/错单时，SFC 会看哪些应对？
A：事故分级、应急响应、客户沟通口径、交易回滚/纠错机制、证据保存、事后复盘与整改闭环，并能提供演练与案例演示。

Q78：SFC 会要求第三方独立评估系统吗？
A：可能。ATS 指引提到可按个案要求对电子设施进行独立评估，尤其系统重要性/潜在系统性风险较高时。

Q79：平台是否必须建立市场操纵监控？
A：若 ATS 形成撮合与成交机制，监管通常期待具备异常交易/操纵行为监控、预警与处置流程，并能出示指标清单与处置闭环。

Q80：如何证明准入公平性？
A：准入标准与技术接入规范、API 公平接入策略、撮合规则公开与版本管理、对关键客户/关联方的额外披露与监控、准入/拒绝/暂停的记录与复核机制。

Q81：算法交易（Algo）需要额外控制吗？
A：若支持 Algo 下单或提供 Algo 工具，应有前置风控（限价/限量/频率）、异常检测、参数变更审批、kill switch、审计轨迹与应急停用流程。

Q82：最常见的系统合规失败点？
A：①日志不可审计或可被管理员篡改；②DR/事故响应只写不练、无真实演练记录；③外包失控（无审计权、无退出方案、关键参数不在你手里）。

七、客户保护、资产安排、记录保存与监管互动（Q83–Q92）

Q83：Type 7 是否可以持有客户资产？
A：Type 7 是设施牌照，本身不当然等同“可持有客户资金/资产”。是否持有取决于业务链条是否触发经纪/托管/客户款项安排等要求；纯设施模式通常建议结构上避免客户资产入账以降低风险与成本。

Q84：客户适当性（Suitability）在 Type 7 是否必须？
A：如面对零售客户或叠加产品分销/投顾功能，适当性要求显著增强；纯 B2B 设施提供则更多体现为准入、披露与风险分层机制。

Q85：风险披露文件应覆盖哪些重点？
A：撮合规则与优先级、延迟与断线风险、系统故障与取消/纠错规则、极端行情处理、第三方依赖、争议处理与证据保全方式、禁止行为（操纵、刷单等）及后果。

Q86：客户投诉机制需要哪些可交付件？
A：投诉政策、分级处理 SLA、证据调取流程（订单回放/日志）、升级路径（合规/RO/董事会）、沟通模板、复盘与整改闭环台账。

Q87：Type 7 是否一定要做 KYC/AML？
A：取决于你是否直接接触客户、是否涉及资金/资产流转以及业务链条 AML 触发点。但从银行开户与风险管理角度，建立与规模匹配的 KYC/制裁筛查/异常行为升级机制几乎是“事实标准”。

Q88：记录保存（Record keeping）有哪些核心要求？
A：能还原“谁在何时以何权限做了什么”：订单/撮合/成交/撤单、参数变更、访问控制、事故处理、投诉处置等可检索记录；若涉衍生品等还可能叠加其他报告与记录义务。

Q89：监管面谈最爱问哪些问题？
A：高频五问：撮合规则与公平性；操纵/异常交易监控；宕机怎么办、DR 怎么切、演练做过吗；关键外包如何控制与审计；谁负责重大事故上报与决策（RO/MIC 问责链）。

Q90：如何准备系统演示（Demo）提高审批效率？
A：建议 20–30 分钟脚本：下单→撮合→成交→回放；权限分层（双人复核/kill switch）；异常触发→告警→处置→记录；变更管理记录；DR 演练证据与切换日志。

Q91：SFC 可能施加哪些牌照条件（Licensing conditions）？
A：常见方向：限制客户类型/产品范围、要求独立评估、限制持有客户资产、强化报告与监控、要求特定关键人员配置等；具体高度个案化。

Q92：持续合规日历应包含什么？
A：FRR 计算与阈值检查、权限复核、漏洞扫描与补丁、DR/BCP 演练、外包评估、监控模型回测、合规培训、内审/独立审查、重大事件演练与复盘；明确责任人、证据产出与董事会汇报频次。

八、申请流程、RFI、获批后运营（Q93–Q100）

Q93：申请 Type 7 总体流程是什么？
A：监管定性→搭建人员与治理→制度包与系统证据链→提交申请→回应 RFI→面谈/补件→获批→上线前验收→持续合规运营（程序以 SFC 最新口径为准）。

Q94：RFI 通常会问哪些模块？
A：三大模块：①业务边界与牌照组合（是否触发 Type 1/2 等）；②系统控制证据链（日志、测试、演练、变更、监控）；③外包治理与问责链（合同、审计权、退出方案、责任划分）。

Q95：如何把 RFI 做成可控项目，避免无限循环？
A：一问一包（Issue Pack：问题→结论→制度引用→证据→附件索引）；指定负责人；答复必须指向可验证证据；版本控制与答复矩阵避免前后矛盾。

Q96：获批后是否可以马上上线？
A：建议不要“获批即上线”。应做上线前验收：权限与密钥管理、监控阈值、事故响应演练、客户条款上线、客服与投诉演练、外包应急联络清单，并确认资本与资源可持续。

Q97：持牌后哪些变更最容易触发监管关注？
A：核心系统架构重大变更、关键外包更换、撮合规则/参数重大调整、客户类型扩张（零售化）、新增产品/市场、RO/MIC/关键岗位变动、资本或财务指标显著波动。

Q98：发生重大事故（宕机/错单/疑似操纵）第一时间做什么？
A：三步：①控制风险并保全证据（停机/降级/kill switch/限流）；②启动事故响应（分级、内部升级、外包联动）；③客户沟通与复盘整改（回放、纠错规则、整改闭环），形成事故报告与改进计划。

Q99：如何证明长期可合规运营，而不是“为拿牌临时拼材料”？
A：监管最信任的信号：持续预算与人员；周期性测试与演练记录；董事会监督与整改闭环；可审计系统控制（日志、变更、权限、监控）。

Q100：Type 7 项目最优落地打法是什么？
A：建议“三阶段+证据链”：阶段1 监管定性与结构（组合牌照、资产安排）；阶段2 制度包+系统证据链（日志/测试/演练/外包合同一体化）；阶段3 RFI-ready 递交与面谈演示（用演示脚本证明可控可审计）。

九、透明度、接入公平、市场数据与交易规则（Q101–Q112）

Q101：SFC 在 Type 7 语境下最关心的“透明度（Transparency）”到底指什么？
A：不仅是“有没有规则文本”，而是你能否让参与者在合理范围内理解：交易如何被撮合/执行、在什么情形会被拒单/撤单/降级、以及争议时如何复核与回放。ATS 指引把“透明度”列为核心标准之一，目标是维护市场公平与秩序。

Q102：平台需要公开哪些“平台规则 / 会员规则 / 交易规则”？
A：一般建议至少形成三层文件：

1. 对外规则（Public / Participant Rules）：撮合优先级、订单类型、交易时段、拒单/撤单、异常行情处理、停市/熔断（如适用）、争议与纠错原则、费用与收费口径；

2. 接入与技术规范（Onboarding & Tech Spec）：API 规范、限流、连接/测试环境、证书与密钥要求、时间同步与报文标准；

3. 内部控制规则（Internal Control Rulebook）：参数治理、双人复核、紧急变更、异常阈值、kill switch、权限矩阵与日志要求（通常不完全公开，但需可审计）。

Q103：平台能否对不同客户设置不同撮合优先级（例如 VIP 更快/更优先）？
A：要极度谨慎。监管风险点在于：

• 是否破坏公平接入/公平成交；

• 是否构成对关联方/特定客户的不当优惠；

• 是否导致可被解读为“操纵便利”或“信息优势”。
  若确需差异化（例如不同线路、不同 API 频率档），必须：规则可披露、条件客观、记录可追溯、影响可评估，并设置利益冲突与监控缓释措施。

Q104：什么是“公平接入（Fair Access）”，如何做出可交付证据？
A：建议把“公平接入”落地为可审计的四件套：

• 准入标准（谁能接入、审核流程、拒绝/暂停/恢复规则）；

• 技术公平（同等 API、同等限流原则、同等撮合规则、同等延迟策略）；

• 治理公平（规则变更通知、版本生效窗口、回滚机制）；

• 证据公平（准入审批记录、限流策略配置、变更公告、日志与回放样例）。

Q105：平台是否可以提供 Co-location（机房同址）或低延迟专线？
A：可行，但属于“高敏感”安排：

• 必须证明不损害公平接入（例如：公开可获得的服务、透明费用、统一资格门槛）；

• 需强化对高频行为的监控（刷单、幌骗、拉抬打压等）；

• 需要留存：线路配置、延迟指标、接入资格、客户披露与同等服务证明。

Q106：时间戳（timestamp）要做到什么精度？监管会问吗？
A：会问，且常作为“争议回放/操纵取证”的基础。建议：

• 全链路统一时间源（NTP/PTP 方案与漂移监测）；

• 关键事件（接收、校验、排队、撮合、成交、回报、撤单、拒单、风控拦截）均需时间戳；

• 形成时间同步报告 + 漂移告警记录 + 样例回放。

Q107：平台“行情展示/市场数据”需要承担什么责任？
A：若你向参与者分发行情（含深度/成交回报/最佳报价），监管常关注：

• 数据是否准确、及时、可解释；

• 异常行情或系统延迟时的披露与处置；

• 与撮合引擎的一致性（避免“展示与成交不一致”引发纠纷）；

• 数据留存与回放（用于争议与调查）。

Q108：是否必须有“交易后对账”与“日终报表”？
A：强烈建议必须有。即便你不清算，也应提供：

• 日终成交/撤单/拒单汇总；

• 费用明细与计费依据；

• 异常事件与纠错记录；

• 争议工单与处理状态。
  这些既是客户服务，也是监管“记录保存/可追溯”的核心证据。

Q109：RFQ/询价撮合模式（Request-for-Quote）相比订单簿更容易过审吗？
A：不一定。RFQ 可能在市场操纵、信息不对称、报价公平性方面更敏感。你需要证明：

• 报价规则、有效期、成交条件清晰；

• 参与者准入与报价资格公平；

• 询价与成交的审计链可回放；

• 异常报价与串谋风险有监控与处置机制。

Q110：撮合规则是否允许“内部化（internalisation）/自成交（self-trade）”？
A：可以设计，但必须有明确规则与风控：

• 自成交识别与阻断/允许条件；

• 防止制造虚假成交量；

• 关联方交易披露与监控；

• 争议与回放机制。
  若你或关联方参与成交，更要强化利益冲突与监控。

Q111：平台收费结构（maker/taker、会员费、技术费）会被监管审查吗？
A：会，主要看三点：

• 是否引导不当交易行为（例如刷量套利）；

• 是否与公平接入相冲突（例如隐性差别定价）；

• 是否与披露一致且可核对（对账、账单、费用计算可追溯）。

Q112：对外宣传“最优成交/最佳执行（best execution）”是否会触发额外责任？
A：会。你一旦对外承诺“最优成交”，监管与客户争议会要求你证明：

• 订单处理与撮合是否符合承诺；

• 延迟、拒单、滑点、系统故障时如何处理；

• 是否存在利益冲突与偏置。
  建议营销表述与真实控制能力严格对齐，避免“承诺大于能力”。

十、监控、市场操纵、报告与监管协作（Q113–Q125）

Q113：ATS 指引中的“Surveillance（监控）”标准，通常要求做到哪一步？
A：至少要能识别、预警并处置明显异常交易/操纵迹象，并形成闭环记录。ATS 指引将“Surveillance”列为核心标准之一。

Q114：平台需要监控哪些典型操纵/异常行为？
A：建议最少覆盖：

• 幌骗（spoofing）、刷量（wash trading）、对倒、拉抬打压；

• 异常撤单率、异常高频下单、订单簿堆砌；

• 关联账户协同行为；

• 异常价格偏离与瞬时波动；
  并输出：指标清单、阈值、告警、人工复核流程、处置记录与复盘整改。

Q115：如果平台只做 B2B（给券商/机构接入），是否可以不做监控？
A：不建议。B2B 只改变监控“分工”，不消灭平台的设施责任。你至少要：

• 对接入方设定监控责任与协作机制；

• 自身保留关键监控能力（异常告警、日志回放、权限与参数审计）；

• 在合同中约定：信息共享、调查协作、紧急停用与审计权。

Q116：遇到疑似操纵或重大异常，平台第一时间该做什么？
A：建议“三步走”：

1. 控制风险：限流/暂停某账户/触发 kill switch/降级策略；

2. 保全证据：冻结相关日志、参数版本、订单回放、访问记录；

3. 启动调查与升级：合规/RO/MIC 升级，按制度启动对外沟通与后续整改闭环。

Q117：是否需要把“监控模型/规则”做成可回测、可审计？
A：强烈建议。监管与内部审计常追问：

• 规则何时生效、阈值如何设定、为何这样设定；

• 误报/漏报如何评估；

• 重大调整是否走变更审批；

• 处置是否一致、是否存在选择性执法。
  因此应保留：模型版本、参数变更、回测报告、处置样例。

Q118：平台是否需要向 SFC 定期提交监控或事件报告？
A：ATS 指引将“Reporting（报告）”列为核心标准，具体频率与内容通常视业务性质、风险画像与牌照条件而定。
实务上应准备：定期运行指标、重大事件通报、重大变更报告、独立评估/审计发现与整改报告等“可随时提取”的报告底座。

Q119：什么叫“重大事件（material incident）”？
A：通常包括（但不限于）：

• 交易中断、系统宕机、错单/错配；

• 严重网络安全事件（入侵、数据泄露、密钥泄露）；

• 影响公平成交的规则/参数错误；

• 关键外包失效导致服务不可用；

• 重大投诉/争议集中爆发。
  建议在制度中定义事件分级、通报时限与沟通口径。

Q120：平台发生“错单/错配”，能否回滚交易？
A：要看你的规则文本与参与者协议是否允许，以及回滚是否会产生二次不公平。最佳做法是：

• 事前在规则中写明“纠错/撤销/回滚”的触发条件、授权层级、通知与记录方式；

• 事中保全证据，做影响评估；

• 事后复盘整改，更新控制与演练记录。

Q121：监控团队是否必须独立于业务/技术团队？
A：成熟平台建议“相对独立”，至少要确保：

• 监控人员对业务指标不被激励扭曲；

• 对关联方与关键客户的处置有独立升级路径；

• 监控结论能直达 RO/MIC/董事会。
  规模较小可外包部分能力，但你必须可审计、可指挥、可复核。

Q122：SFC 面谈中关于“监控”最常见追问是什么？
A：高频追问：

• 你监控哪些行为？阈值怎么定？谁有权调阈值？

• 发现异常后怎么处置？处置有没有一致性与记录？

• 你如何避免关联方/做市商获得不当优势？

• 你能否当场演示：异常触发 → 告警 → 工单 → 处置 → 复盘闭环。

Q123：平台需要保留哪些“调查取证”能力？
A：建议至少具备：

• 全链路订单回放（含撮合决策依据）；

• 访问审计（谁改了什么参数/规则/权限）；

• 工单系统（异常、投诉、调查、整改闭环）；

• 可导出报表（按账户、IP、API key、策略标签、时间窗聚合）。

Q124：与外部监管/执法协作时，平台最容易卡在哪里？
A：常见卡点是“证据不完整”：

• 日志不全、时间戳不可靠、缺乏版本记录；

• 监控规则不可解释、处置缺乏一致性；

• 外包环境取证困难（无审计权/无数据提取权）。
  所以外包合同与日志治理要前置。

Q125：是否需要建立“市场公告/紧急通知”机制？
A：建议必须建立：

• 宕机/恢复公告模板；

• 规则变更公告模板；

• 重大异常/纠错公告模板；
  并明确发布渠道（官网、邮件、系统弹窗等）、审批权限与留存证据。

十一、记录保存、外部数据存储、云与外包治理（Q126–Q150）

Q126：ATS 指引对“Record Keeping（记录保存）”的底层要求是什么？
A：核心是：可追溯、可回放、可审计。ATS 指引把“Record Keeping”列为核心标准之一。
对 Type 7，建议把记录分为四类：交易链记录、系统链记录、治理链记录、客户链记录（投诉/披露/对账）。

Q127：日志与记录通常要保存多久？
A：具体年限需结合 SFO、附属法例、SFC 指引及你是否涉及其他业务（例如经纪、衍生品等）而定。实务建议：

• 先按“更严格口径”设计留存能力；

• 用数据分层（热/冷）降低成本；

• 保证检索与导出能力（监管/RFI/调查时最关键）。

Q128：如何把日志做到“可信（tamper-evident / immutable）”？
A：建议采用组合方案：

• 权限隔离（管理员不能单方删除/修改核心日志）；

• WORM/对象锁/不可变存储；

• 哈希链或签名（证明完整性）；

• 访问审计与定期抽检。
  监管最怕的是“你无法证明没有被篡改”。

Q129：SFC 会重点看哪些“系统链记录”？
A：至少包括：

• 变更管理：申请、审批、测试、上线、回滚、上线后监控；

• 权限与密钥：创建、分配、轮换、撤销、离职回收；

• 容量与压力测试：方法、结果、瓶颈与整改；

• DR/BCP 演练：脚本、切换日志、复盘整改；

• 安全事件：告警、响应、取证、修复、复测闭环。

Q130：我们把系统放到云上，会触发哪些额外合规工作？
A：云可行，但你要证明“云上控制不弱于自建机房”。重点包括：

• 数据分类分级、加密与密钥管理；

• 网络分区、最小权限、零信任/堡垒机；

• 日志集中与不可变存储；

• 跨区容灾与演练；

• 供应商审计权、分包控制、退出迁移方案；

• SLA 与事故通知机制。

Q131：什么是 SFC 的“外部数据存储（EDSP）”监管关注点？
A：若持牌人使用外部服务商存储监管记录/客户数据，SFC 期望持牌人确保可取回、可审计、可监管访问与有退出安排，并通过指定联络人/制度安排保证监管需要时能取回记录。

Q132：EDSP 情形下，最容易被忽略的“致命条款”是什么？
A：通常是：

• 取回权/访问权不足（你拿不回数据或拿回不完整）；

• 分包不可控（数据被二次外包到你未知地点）；

• 退出迁移不可执行（没有迁移协助、没有时间承诺、没有格式保证）；

• 监管访问受阻（无法在合理时间内向监管提供记录）。

Q133：外包撮合引擎/风控系统给供应商，监管会怎么问？
A：会穿透问三件事：

1. 谁控制关键参数与规则（你有没有最终决定权）；

2. 你如何验证供应商交付（测试、审计、监控、SLA）；

3. 你如何“收回控制权”（退出迁移、应急接管、源代码/配置访问安排）。
   结论是：可以外包技术，但不能外包责任。

Q134：如果供应商不给源代码，只给“黑盒服务”，能过吗？
A：风险很高。最低底线是：

• 你能清晰解释撮合/风控逻辑与异常处置；

• 你对关键参数变更有审批与回滚；

• 你能做独立验证（对账、回放、压力测试、故障演练）；
  否则很难证明公平与可控。

Q135：SFC 是否会要求对电子设施做独立评估？
A：ATS 指引明确 SFC 可按个案需要要求对用于提供 ATS 的电子设施进行独立评估（尤其系统重要性较高时）。
建议提前预留：第三方评估预算、整改周期、评估范围与交付件（控制有效性、韧性、网络安全等）。

Q136：独立评估报告通常要覆盖哪些内容才“对监管有用”？
A：建议至少包括：

• 架构与关键控制点审查；

• 权限、变更、日志、监控、DR 的有效性测试；

• 漏洞与渗透测试结果及整改闭环；

• 容量与压力测试；

• 外包与云控制等效性；

• 重大风险列表与整改路线图。

Q137：渗透测试（PT）与漏洞管理的“闭环证据”怎么做才算合格？
A：用“五件套”闭环：发现清单 → 风险评级 → 修复方案 → 复测验证 → 关闭记录。
缺任何一环，监管通常视为“控制未落地”。

Q138：密钥管理（API key、签名密钥、管理员凭证）需要什么级别？
A：建议至少：

• HSM/密钥托管（或等效强控制）；

• 双人复核、分权管理（M of N）；

• 定期轮换与离职回收；

• 访问审计与异常告警；

• 紧急吊销与全量替换演练记录。
  Type 7 常把密钥当“系统治理能力”的试金石。

Q139：平台是否必须有 kill switch？
A：强烈建议有，尤其支持算法/API 的平台。kill switch 不只是按钮，而是一套：触发条件、授权层级、日志留存、客户沟通与复盘整改机制。

Q140：算法接入（Algo / API）最关键的“前置风控”是什么？
A：建议至少包括：

• 限价、限量、频率限制（throttling）；

• 异常订单拦截（价格偏离、重复撤单等）；

• 账户级风险阈值与自动降级；

• 策略标签与可回放；

• 统一告警与工单闭环。

Q141：SFC 对算法交易的监管思路与“证据链”有什么共通点？
A：核心是可控、可解释、可追溯。算法交易相关指引/表格强调：治理、测试、监控、变更与紧急控制（如 kill switch）必须可验证、可审计。

Q142：如果平台发生网络攻击导致服务降级，需要保留哪些证据？
A：建议保留：

• 告警与事件时间线；

• 受影响范围评估（哪些功能/哪些账户/哪些数据）；

• 处置动作（封禁、切换、补丁、密钥轮换）；

• 客户沟通记录；

• 复盘报告与整改计划；

• 复测与关闭证据。
  这些将直接影响监管对你“系统完整性与治理”的信心。

Q143：如何把“事故响应”写成真正能跑的 SOP，而不是口号？
A：建议用“剧本化”：

• 预设 6–10 个典型场景（宕机、错单、异常波动、密钥泄露、云服务故障等）；

• 每个场景都有：触发条件、指挥官、通讯录、动作清单、证据清单、公告模板；

• 每年至少演练并复盘整改，形成记录。

Q144：Type 7 平台需要设立“变更评审委员会（CAB）”吗？
A：建议设立或等效机制。监管常用“变更治理”来判断你是否真正可控：

• 谁能改规则/参数；

• 谁批准；

• 上线前如何测试；

• 上线后如何监控；

• 紧急变更如何补批与复盘。

Q145：重大系统变更（例如换撮合引擎、迁移云、改撮合优先级）要不要提前与监管沟通？
A：通常属于高敏感事项，建议内部先做：风险评估 → 测试与演练 → 客户披露与生效安排 → 证据包准备，再视牌照条件与风险等级决定是否需要事前沟通/报备。原则是：不要等出事才解释。

Q146：平台如果不持客户资产，是否就不需要客户保护/投诉机制？
A：不成立。不持资产只能降低部分风险，但客户仍会因：错单、延迟、争议成交、费用争议而投诉。你仍需：投诉渠道、SLA、证据调取（订单回放/日志）、升级路径、复盘整改闭环。

Q147：持牌后最容易被忽视、但最容易出事的“日常合规动作”有哪些？
A：Top 6：

1. 权限复核与离职回收；

2. 变更记录与回滚演练；

3. DR/BCP 演练与整改；

4. 监控阈值与模型回测；

5. 外包服务评估与审计权执行；

6. FRR/资本与流动资本预警（多牌照结构尤需）。
   资本门槛（实缴股本/流动资本）是 Type 7 的硬指标之一。

Q148：Type 7 的资本金门槛是多少？会变吗？
A：按 SFC 持牌手册/要求表，Type 7（ATS）常见最低门槛为：实缴股本 HK$5,000,000；流动资本 HK$3,000,000，并需持续维持。
（个案还会受业务结构、风险扣减、其他牌照组合影响，建议用 FRR 模拟报表做压力测试。）

Q149：Type 7 是否“天然适合”做虚拟资产交易平台？
A：不要做这种假设。ATS 是设施监管概念；若你涉及虚拟资产且触发证券/期货属性或落入更专门的平台监管框架，可能叠加更高要求与额外条件。建议把虚拟资产纳入路线图：先做受规管边界清晰的阶段性落地，再逐步扩展。

Q150：你们对 Type 7（ATS）申请与运营的“终局建议”是什么？
A：一句话：用“证据链”赢监管，用“可运行”赢市场。

• 申请阶段：把制度写成可演示、可审计、可回放；

• 系统阶段：把日志、变更、监控、DR 演练变成“常态化产出”；

• 运营阶段：把外包审计权、重大变更治理、事件响应做成可持续机制；
  这样才能同时降低 RFI 回合与持牌后事故风险。

22｜我司可提供的配套文件清单（交付包目录示例）

1. Reg Perimeter 定性备忘录（Type 7/组合牌照判定）

2. 控股结构穿透图模板 + SoF/SoW 说明信模板

3. RO/MIC 职责分工矩阵（RACI）+ 值勤与监督日志模板

4. ATS 业务说明书（BP 结构）+ 撮合规则文本模板

5. 系统合规包：架构图模板、权限分层、日志规范、变更管理制度

6. 安全包：渗透测试整改闭环模板、漏洞管理流程、事件响应预案

7. BCP/DR：灾备策略、演练脚本、演练记录模板

8. 外包治理包：尽调清单、SLA 条款要点、审计权与退出方案模板

9. 市场操纵/异常交易监控规则模板（指标库+阈值+处置流程）

10. 客户保护包：风险披露、投诉处理、争议处理话术库

23｜唐生结论（Executive Wrap-up）

Type 7（ATS）不是“拿一个牌照就能开平台”，而是一个以系统稳健、市场公平、治理问责为核心的监管工程。你要把项目当成“可审计的市场设施”来建设：

• 资本门槛（HK$5m paid-up + HK$3m liquid）只是最低底线

• 真正决定审批效率与后续风险的是：证据链（系统测试、日志、演练、变更、监控、外包控制）

• 如果你同时做经纪/招揽/客户交易链条，必须在结构上提前把 Type 1/2 等组合牌照与客户资产安排设计清楚，否则 RFI 会无限循环。

24｜仁港永胜建议｜为何选择仁港永胜｜关于我们｜联系方式｜免责声明

24.1 仁港永胜建议（香港 SFC 7号牌申请注册）

1. 先定性、后写材料：先把业务边界（Type 7 vs 组合牌照）一次定对，再做制度与系统证据链。

2. 用“证据链”驱动项目管理：每一条制度必须能落地到日志、报表、审批记录与演练记录。

3. 把外包当成“监管项目”管理：云、撮合引擎、安全服务必须在合同与控制上“可审计、可退出”。

4. 提前做“面谈演示脚本”：用 20 分钟演示你的撮合规则、权限分层、订单回放、异常处置、事故响应与灾备切换，显著提升可信度。

5. 资本与现金流做“12个月视角”：不要只满足最低门槛，要能证明持续经营与事故承压能力。

6. 合规服务：选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

24.2 为何选择仁港永胜（核心优势）

• 交付导向：以“可递交、可审计、可面谈演示”为标准，不做空泛报告

• 系统合规强项：Type 7 以系统为核心，我们以“系统证据链”拆解监管要求

• 结构化项目管理：里程碑管理 + RFI-ready 材料包，减少反复补件

• 组合牌照经验：可协助你把 Type 7 与 Type 1/2/4/9 等业务链条合规拼图一次搭好

• 长期维护体系：从拿牌到持续合规（资本监控、变更管理、审计与演练）一体化陪跑

24.3 关于仁港永胜（香港）有限公司

仁港永胜（香港）有限公司长期为金融机构、金融科技与数字资产相关企业提供：香港及海外多司法辖区的合规咨询、牌照申请、制度建设、系统合规与持续监管维护支持。我们强调“交付级可落地”，以监管口径与证据链为导向，帮助客户以更可控的成本与更高的确定性推进持牌与运营。

24.4 联系方式（Contact）

24.5 免责声明（Disclaimer）

1. 本文仅作一般性信息与项目经验分享，不构成法律意见、合规意见或对任何个案的最终结论。

2. 牌照申请是否获批、审批周期、附加条件与持续监管要求，均以香港证监会（SFC）及香港适用法律法规的最新口径为准；监管亦可能因申请人业务模式、系统重要性、风险画像而提出额外要求。

3. 如需将本文用于正式递交或对外宣传，请在使用前取得专业法律/合规审阅，并结合申请主体的实际业务与系统现状进行定制化修订。

4. 仁港永胜保留对本文内容更新与修订的权利。

——《香港 SFC 7号牌：自动化交易服务牌照申请注册指南》——由仁港永胜唐生提供专业讲解。