首页 > 常见问题

香港 SFC 7号牌｜自动化交易服务（Type 7: Providing Automated Trading Services, “ATS”）常见问题（FAQ）

时间：2026-01-22 17:15:42 阅读：219

《香港 SFC 7号牌｜自动化交易服务常见问题（FAQ）》

Type 7: Providing Automated Trading Services, “ATS” FAQ

编制依据以香港《证券及期货条例》（SFO, Cap.571）对 Type 7 / ATS 的法定定义、以及证监会《Guidelines for the Regulation of Automated Trading Services（2016）》《Licensing Handbook》等公开指引为准。
本文由 仁港永胜（香港）有限公司 拟定，并由 唐生（唐上永，Tang Shangyong） 提供专业讲解。

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

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

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

✅ 点击这里可以下载 PDF 文件：关于仁港永胜

注：本文模板、清单、Word/PDF 可编辑电子档，可向仁港永胜唐生有偿索取（用于监管递交与内部落地）。

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

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条监管风险

二、香港SFC 7号牌｜自动化交易服务常见问题（FAQ）

《香港 SFC 7号牌｜自动化交易服务（Type 7: Providing Automated Trading Services, ATS）》FAQ

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

A. 定义与边界（ATS 是什么、Type 7 管什么）Q1–Q20

Q1. 什么是“自动化交易服务（ATS）”？
A：ATS 一般指通过电子化、自动化方式提供交易“设施/系统/规则”，使参与者能够在该设施内提交、配对、撮合、成交或以其他方式完成交易流程的服务；是否构成 ATS 以 SFO 附表 5 的法定定义与实质功能为准，而不以“平台自称”决定。

Q2. Type 7（提供 ATS）属于哪部法律框架？
A：Type 7 是 SFO 之下的受规管活动之一；提供 ATS 的法团通常需要：(i) 依据 SFO 第 III 部获授权提供 ATS 或 (ii) 依据 SFO 第 V 部获发牌/注册为 Type 7，具体取决于业务性质与是否已作为中介人从事其他受规管活动等。

Q3. “授权（Part III）”与“发牌（Part V）”有何核心差别？
A：监管口径通常将**“主要提供交易场所/系统性质的 ATS（更像交易所/电子交易设施）”**导向 Part III 授权；而若机构本身已是中介人、提供 ATS 作为其受规管业务的一部分，常见路径为 Part V 的 Type 7 发牌/注册。实际仍以业务结构、参与者范围、规则制定与市场影响等综合判断。

Q4. 只有“订单路由（order routing）”算不算 Type 7？
A：一般而言单纯订单路由通常不被视为 Type 7；但关键在于你的电子服务是否“实质上构成 ATS”（例如是否提供撮合/成交规则、交易设施、参与者互动机制等）。一旦符合 ATS 定义，就可能需要 Type 7。

Q5. 只做“算法交易/量化下单工具（给客户用）”就一定是 Type 7 吗？
A：不一定。若你仅提供工具让客户把指令送往已持牌经纪/交易所执行，且你并不运营交易设施/撮合机制，未必构成 ATS；但若你的系统本身形成交易撮合/成交环境或提供交易规则与设施，则更接近 ATS。建议按“功能实质”对照 ATS 定义逐项拆解。

Q6. Type 7 是否只管证券？
A：Type 7 的核心是“提供 ATS”这一类服务形态；涉及产品范围需结合 SFO 适用对象（例如证券、期货合约、以及 OTC 衍生品相关扩展等）。判断时要把产品属性与**服务形态（是否 ATS）**一起看。

Q7. “电子通讯网络（ECN）/黑池（dark pool）”在香港通常会落到 Type 7 吗？
A：若 ECN/黑池提供参与者进入的电子交易设施、指令交互与撮合/成交规则，典型会被视为 ATS 监管对象；具体仍取决于是否构成 ATS 及其市场结构（是否类似交易所设施）。

Q8. “撮合引擎在境外、香港只是销售/运营”还能规避 Type 7 吗？
A：不能简单以服务器位置规避。SFC 通常会看你是否在香港**“经营受规管活动业务”**、是否向香港客户提供服务、在港设有管理/营销/关键决策与控制等。跨境结构需做“谁在香港经营、谁控制关键功能”的穿透分析。

Q9. 做“机构间（B2B）撮合”比面对零售更容易吗？
A：机构间可能在客户适当性、风险披露与投资者分类上更可控，但不代表监管更轻。ATS 关键要求集中在：治理、规则透明、系统稳健、监控与记录、市场操纵防控、业务连续性等。客户类型影响“保护强度”，不改变“是否 ATS”的本质。

Q10. 做“广告牌式（bulletin board）撮合”，不成交，只展示意向，算 ATS 吗？
A：若仅信息展示、无指令提交与撮合成交机制，可能不构成 ATS；但若平台规则促成交易形成、提供指令交互、配对或形成事实上的交易设施，仍可能被视为 ATS。应做“功能清单 + 规则链路”的逐项比对。

Q11. “OTC 询价+RFQ 系统”会落入 Type 7 吗？
A：视其是否构成自动化交易设施：若 RFQ 系统只是通信工具，未形成撮合/成交设施，未必；但若系统内形成标准化交易流程、自动匹配/成交、规则与参与者接入机制，则可能触发 ATS 监管。

Q12. Type 7 与 Type 1（证券交易/经纪）怎么区分？
A：Type 1 侧重“为客户买卖证券（deal in securities）”的中介交易行为；Type 7 侧重“提供交易设施/系统（ATS）”。实务上很多平台会同时涉及（例如平台运营 + 经纪功能），需要按业务链拆分并可能组合持牌。

Q13. 只提供“撮合”，不碰客户资金/资产，就不需要 Type 7 吗？
A：是否需要 Type 7 取决于你是否提供 ATS（交易设施/规则/系统），不是取决于你是否持有客户资产。资产持有问题是“客户资产/托管与内部控制”的另一条合规线。

Q14. 平台“只允许会员进入”，会降低合规要求吗？
A：会员制可能有助于客户尽调与参与者管理，但 ATS 的核心标准仍适用（接入标准、规则透明、监控、记录、系统韧性、应急与外包治理等）。

Q15. ATS 是否一定要有“公开市场/多边撮合”？
A：不一定。关键是你是否提供使交易能够在你的设施内以自动化方式发生的机制与规则；多边/单边、中央限价簿/询价等只是形态差异，监管会看实质与风险。

Q16. SFC 会如何判断“我是不是在提供 ATS”？
A：通常按“功能实质”判断：是否有交易规则、参与者接入、订单/报价提交、匹配/成交逻辑、交易监控与记录、清结算安排等；并结合业务规模、对市场的影响与潜在风险决定监管路径（授权或发牌）。

Q17. ATS 与“在线分销/投顾平台”有什么关系？
A：在线分销/投顾平台侧重向客户提供产品分销与建议，但如平台同时提供 ATS 功能（自动化交易设施），则需同时对照 ATS 指引要求；SFC 的在线平台指引也会引用 ATS 指引作为相关要求来源。

Q18. 我只做“API 接入第三方交易所”，是否构成 ATS？
A：若你只是技术接入、把客户指令传递到第三方持牌/受监管市场完成撮合成交，一般更接近“路由/技术服务”；但若你在中间形成自己的撮合规则、合并流动性、内部化成交或提供交易设施，则可能触发 ATS。

Q19. “复制跟单（copy trading）”会触发 Type 7 吗？
A：复制跟单本身更像交易功能/投资服务安排；是否触发 Type 7 仍看你是否运营 ATS（撮合/设施）。但复制跟单往往同时触发适当性、披露、利益冲突、算法治理等监管关注点。

Q20. Type 7 是否与虚拟资产平台（VATP）强相关？
A：在 SFC 对“虚拟资产交易平台”框架下，常见组合是 Type 1 + Type 7（并可能叠加 AMLO 下 VA 服务牌照）；VATP 的持牌与条件会进一步强化系统、托管、市场监控等要求。

B. 牌照路径与组合（Type 7 单独拿？要不要叠加 Type 1/其他）Q21–Q40

Q21. 我能否只申请 Type 7，不申请 Type 1？
A：取决于你的业务链条。若你仅提供交易设施（ATS），不从事“为客户买卖证券”的经纪撮合，则可能只需 Type 7；但多数平台商业模式会涉及成交、收费、会员/客户交易安排，从而可能同时触及 Type 1（甚至 Type 2/5/9 等）。应做“业务活动映射表”逐项归类。

Q22. Type 7 与证券型代币/虚拟资产交易平台为什么常被绑定 Type 1？
A：当平台提供的交易标的中存在“证券”属性（如证券型代币），平台交易行为可能构成 Type 1，而平台设施又构成 Type 7；因此监管常以 Type 1+7 作为平台基础牌照组合，并配合额外条款。

Q23. 如果我只做“非证券”产品撮合，还需要 SFC Type 7 吗？
A：要看是否落入 SFO 体系与 ATS 定义以及监管归口；若不属于 SFO 监管标的，未必由 SFC 以 Type 7 管辖，但涉及到其他法律/监管框架的可能性仍需评估。对“产品是否证券/期货/受规管”这一点必须先做法律定性。

Q24. “白标（white-label）”平台：我是品牌方，技术和撮合由第三方提供，谁需要 Type 7？
A：SFC 通常看谁在“提供服务”、谁控制关键功能与规则、谁对客户与市场承担责任。白标结构常见监管结论是：品牌运营方与核心系统控制方都可能被要求纳入持牌/受监管安排（或至少纳入受规管外包与关联实体治理）。

Q25. 只向“专业投资者（PI）”提供 ATS，会降低持牌门槛吗？
A：PI 限制可能影响客户保护与适当性强度，但 Type 7 的系统性要求（治理、监控、记录、风险管理、BCP 等）并不会因此消失；若是 VATP 场景，PI/零售的监管条件差异更明显且有额外手册要求。

Q26. ATS 是否可以作为“附带业务”放在已有持牌法团内？
A：可以。若法团已就其他受规管活动持牌，新增 ATS 功能通常会被要求增持 Type 7 或作出相应授权/变更；并按 ATS 指引完善制度与系统证据链。

Q27. 同一集团：香港持牌公司 + 海外交易所，如何做合规隔离？
A：常见做法是：香港实体仅承担获牌范围内功能；海外实体承担境外撮合/结算等；并通过信息隔离、客户界面与合同主体清晰化、外包协议、风险与事件报告机制来证明香港实体没有“未授权在港经营”。结构需谨慎，避免形成事实上的香港 ATS。

Q28. ATS 服务是否必须在香港设立实体？
A：若在香港经营受规管活动，通常需要以合规方式在港运营（如持牌法团/注册机构等）。仅以境外主体向香港开展业务仍可能触发“在香港经营”的判断与监管关注。

Q29. 是否存在“豁免/不需要牌照”的情形？
A：SFO 存在若干豁免与例外，但是否适用必须结合你的业务事实、客户对象、服务地点与活动性质判断。常见误区是把“技术服务/路由”误认为完全豁免，最终仍可能被认定为 ATS。

Q30. 我能否先做“技术测试/沙盒”，再申请 Type 7？
A：可以规划分阶段：先做内部测试或与持牌机构合作进行受控试点；但对外提供服务前，需确保牌照路径与监管沟通到位，避免“先运营后补牌”。虚拟资产平台场景亦存在监管沙盒/试点历史与相应条件安排。

Q31. Type 7 申请是否一定要先拿到银行账户？
A：一般需证明有健全的财务与营运安排；在部分平台/特定类型申请中，监管可能要求在审批前提供银行账户或资金安排证明（尤其涉及客户款项安排或 VATP 额外条件时）。

Q32. 我提供 ATS，但交易对手是“自营做市商”，是否属于 ATS？
A：如果你的系统允许参与者以规则化方式提交指令并完成成交，即使对手方集中，也可能构成 ATS；同时还会引出利益冲突、市场操纵、价格形成与披露等重点审查。

Q33. ATS 是否可以“只撮合不清算”？
A：可以，但你需要清晰披露清结算路径、第三方角色与风险；并确保交易后流程（确认、对账、争议处理、违约处置）可审计、可追溯。

Q34. ATS 的“市场监控（surveillance）”必须自己做吗？
A：ATS 指引允许由 ATS 提供者、监管机构或其他胜任者进行监控，但你作为持牌主体必须证明监控有效、覆盖范围足够、处置机制闭环，不能“完全甩锅”。

Q35. 我只做“内部撮合（internalization）”，不对外开放，仍算 ATS 吗？
A：若系统仅为内部运营工具且不对外提供交易设施，可能不构成；但只要你向外部客户/会员提供进入并在系统内形成交易，仍可能构成 ATS。关键是“是否对外提供交易设施/服务”。

Q36. 若我同时提供投顾/资产管理，Type 7 与 Type 4/9 如何并存？
A：需把客户旅程拆分：建议（Type 4/5/6）、管理（Type 9）、交易设施（Type 7）、执行经纪（Type 1/2）分别落位，并在制度上处理利益冲突与信息隔离，避免“既当裁判又当运动员”。

Q37. Type 7 申请能否“买壳/收购持牌公司”实现？
A：市场上存在并购路径，但 Type 7 涉及重大控制人、负责人员、业务变更与系统变更，均可能触发 SFC 审批/报备与适当人选评估；收购后“换系统/换业务”通常仍需充分说明与审查。

Q38. Type 7 牌照是否有“牌照条件（licensing conditions）”？
A：有可能。SFC 可按个案对持牌法团施加条件（例如客户范围、产品范围、系统要求、报告要求等）。VATP 场景尤其常见附加条款与持续性义务。

Q39. Type 7 与“AMLO 虚拟资产服务提供者牌照”是否互相替代？
A：不替代。若业务落在 SFO 的受规管活动与 ATS 范畴，仍可能需要 SFO 下的 Type 7；同时若提供 AMLO 下定义的 VA 服务，也可能需要 AMLO 牌照。双牌照并行是现实常态。

Q40. 我如何快速自检：我是不是“更像 Type 7”？
A：看 5 个关键词：设施（facility）/规则（rules）/接入（access）/撮合（matching）/监控记录（surveillance & records）。若你具备并对外提供这些要素，基本已高度接近 Type 7。

C. 申请资格与“适当人选”总览（监管看什么）Q41–Q60

Q41. 申请 Type 7 的核心门槛是什么？
A：三件事：(1) 适当人选（Fit & Proper）（股东/董事/RO/高管）、(2) 健全治理与合规体系（三道防线、制度与记录）、(3) 系统与运营稳健（安全、监控、BCP、外包治理）。

Q42. “适当人选”一般包含哪些维度？
A：诚信品格、胜任能力、财务稳健、合规记录与监管配合度等；对 ATS 而言还会特别看你对市场公平、系统风险与客户保护的理解与控制能力。

Q43. SFC 对业务说明书（Business Plan）会看什么？
A：会看你是否把 ATS 的关键风险说清楚并提出可验证控制：客户与参与者画像、产品范围、交易规则、费用与利益冲突、监控与处置、系统架构、外包与供应商、事件响应与停机安排。

Q44. 需要哪些关键岗位？
A：通常至少包括：负责人员 RO（Type 7）、合规负责人、MLRO/AML 负责人、风险管理、IT 安全/系统负责人、运营负责人及内部审计/独立审查资源（可外包但要可控）。

Q45. RO（负责人员）对 Type 7 有何特殊性？
A：RO 不仅要懂一般中介合规，还要能解释 ATS 的交易规则、市场监控、系统控制与事故处置；面谈常围绕“你如何证明系统可控、市场公平、风险闭环”。

Q46. 申请阶段最常见被退回/补件的原因是什么？
A：常见包括：业务边界不清（到底是不是 ATS）、系统描述空泛（缺证据链）、监控与记录方案不足、外包治理缺失、RO/关键人员经验不匹配、财务资源与预算不可信。

Q47. 系统外包给第三方，是否会被认为“不具备能力”？
A：外包可以，但你必须证明：供应商尽调、合同 SLA、权限与数据控制、变更管理、事故响应、审计权与退出计划完整；监管关注点是“你仍能承担最终责任并可控”。

Q48. 申请前是否必须有“可运行系统”？
A：通常至少要有可演示的架构与关键控制（日志、监控、权限、BCP、风控阈值等），并能提供测试证据；纯 PPT 难以通过。

Q49. 资金实力/资本金一定要很高吗？
A：资本与财政资源要求需结合你持牌类型与业务规模、风险敞口、是否持有客户资产等综合评估；ATS 场景监管更强调“持续运作能力与系统投入预算真实”。

Q50. 申请人是否需要在香港有实体办公室与员工？
A：通常需要满足合理的管理与控制在港安排（substance），确保 RO 与核心职能可履职、系统与运营可监管、记录可提供；是否需要多大团队取决于规模，但“空壳 + 纯外包”风险很高。

Q51. 股东/UBO 会被查到什么程度？
A：会进行穿透式适当人选评估，重点看资金来源、控制链条、诚信记录与监管历史；复杂控股结构需准备穿透图、SoF/SoW 证明与一致性解释。

Q52. 董事会需要具备哪些能力？
A：至少要能对 ATS 的关键风险作出治理：系统风险、市场操纵风险、外包与网络安全、合规资源配置与问责。董事会不懂技术没问题，但要有“能问对问题并能监督”的机制与材料。

Q53. 需要提交哪些制度文件（最小集合）？
A：通常至少包括：ATS 规则与参与者条款、监控与处置 SOP、记录保存政策、变更管理、信息安全与权限管理、BCP/DR、外包治理、投诉处理、利益冲突、AML/KYC（如适用）等。

Q54. SFC 会要求“独立审查/渗透测试/审计报告”吗？
A：对关键系统与控制，监管常希望看到第三方或独立团队的验证（例如安全评估、控制有效性测试、复原演练结果），尤其当业务规模、客户范围或产品复杂度较高时。

Q55. 我们是初创公司，没有大型金融机构背景，会吃亏吗？
A：不会“一票否决”，但必须用证据链补足：核心人员履历、制度落地、系统可验证、外包可控、预算与资本安排可信。SFC 关注的是“你是否能持续合规地运营”。

Q56. Type 7 是否需要投保（Professional Indemnity）？
A：是否强制取决于具体牌照条件与业务安排；但实务上，为覆盖运营风险、网络风险、错误与遗漏等，投保常被视为稳健治理的一部分。

Q57. 申请前能否与 SFC 做“预沟通/预咨询”？
A：可行且建议。ATS 的边界判断与路径（Part III vs Part V、是否需要叠加其他牌照）往往需要尽早对齐监管预期，以减少来回补件与结构返工。

Q58. 申请材料如何体现“可审计、可追溯”？
A：用“证据链”写法：制度（Policy）→ 流程（SOP）→ 系统控制点（Control）→ 日志/报表（Evidence）→ 复核与整改闭环（Governance）。ATS 指引对记录与监控的要求尤其强调这一点。

Q59. 申请人最容易忽略的 ATS 专属模块是什么？
A：市场监控（surveillance）与异常处置、规则治理（规则变更、公告、冲突处理）、记录保存（交易与系统日志完整性）、以及 停机/故障的公平处置。

Q60. Type 7 是否存在持续性合规（拿牌后更难）？
A：是的。ATS 的持续合规往往比申请更重要：系统变更、规则调整、供应商变更、监控阈值与模型更新、事故报告、定期演练与审查都构成持续义务。

D. 系统、监控与记录保存（ATS “命门”）Q61–Q90

Q61. ATS 系统建设的监管底线是什么？
A：底线是：稳健（resilience）+ 安全（security）+ 可监控（surveillance）+ 可追溯（audit trail）+ 可恢复（BCP/DR），并且这些能力要能通过文件、测试与日志证据证明。

Q62. 为什么 SFC 特别强调 surveillance（市场监控）？
A：因为 ATS 自带“速度与规模”，容易放大操纵、对敲、刷量、异常波动与系统性风险；有效监控是维持市场公平与有序交易的核心控制。

Q63. 监控必须覆盖哪些典型场景？
A：至少应覆盖：异常价格/成交量、对敲与自成交、分拆与刷单、异常撤单率、集中度风险、做市/自营与客户冲突、系统延迟与丢包异常、数据篡改迹象等，并与处置 SOP 对应。

Q64. 监控是“事后报表”还是“实时拦截”？
A：两者都需要：实时告警/拦截用于防扩散，事后复盘用于模型优化与合规证明；监管更看重你能否在合理时间内识别与处置异常并留痕。

Q65. 交易规则（matching rules）需要公开吗？
A：应向参与者清晰披露关键规则（撮合逻辑、优先级、价格形成、成交确认、取消与错误交易处理等）；规则不清会被视为不公平与治理不足。

Q66. 规则变更如何合规？
A：要有规则治理机制：变更审批（含合规/风险/业务）、影响评估、公告与生效期、回滚方案、变更后监控与复盘；重大变更在特定情况下可能需要与监管沟通。

Q67. ATS 需要保留哪些记录？
A：ATS 指引明确要求保留完整运营记录，包括交易记录、系统运行与访问日志、监控告警与处置记录、规则与参数变更记录、事故记录等，以支持审计与调查。

Q68. 记录保存要满足哪些特性？
A：完整性（no gaps）、不可抵赖性（tamper-evident）、可检索性（searchable）、时间同步准确、权限控制与留痕、备份与灾备可用。

Q69. 记录保存多久？
A：保存期限需按适用法规与监管要求执行，且要覆盖审计与调查需要；实务上会以“满足监管检查与潜在执法取证”为标准设置。

Q70. ATS 是否需要时间戳精度与时钟同步？
A：建议对关键事件（报单、撤单、成交、风控触发、权限变更）进行高精度时间戳记录，并保持系统时钟同步，以确保审计链条可靠。

Q71. 系统容量与压力测试要做到什么程度？
A：要能证明在峰值下仍能稳定运行：容量规划、压力测试报告、降级策略、排队与限流机制、故障切换演练记录；监管会关注“遇到极端行情是否失控”。

Q72. 何谓“公平、有序”的停机/故障处置？
A：当系统故障或延迟异常时，你必须有清晰规则：暂停/恢复条件、订单处置（保留/取消/重报）、信息披露与通知、错误交易处理、争议解决；并确保不偏袒任何一方。

Q73. 网络安全要覆盖哪些域？
A：访问控制、密钥管理、渗透测试、漏洞管理、日志与 SIEM、DDoS 防护、权限分离（开发/运维/安全）、供应链安全、数据加密与备份安全。

Q74. 开发与上线需要哪些治理？
A：SDLC/DevSecOps：需求→设计→代码审查→测试→上线审批→上线后监控→回滚；关键参数与撮合逻辑变更必须受控并可审计。

Q75. 外包撮合引擎，如何证明“我能监控它”？
A：需要：接口与日志可获取、监控指标可见、告警与处置权在你手上、供应商变更需你批准、你有审计权与现场检查权、退出与迁移计划可执行。

Q76. 是否需要“独立环境”隔离测试与生产？
A：强烈建议。测试与生产环境隔离是防止未授权变更与数据泄露的基础控制；关键系统应具备严格权限与变更审批。

Q77. ATS 的数据（行情/订单/成交）是否可以对外售卖？
A：可能涉及利益冲突、信息披露与市场公平问题；需确保对参与者透明、无不当差别待遇、并符合相关规则与合约安排；涉及客户数据还需考虑私隐与数据保护。

Q78. 参与者接入（onboarding）要有哪些门槛？
A：应设明确接入标准：身份与资质、技术接入测试、风险告知与合约、权限与限额、行为规则、违规处置；并可对高风险参与者施加更严限制。

Q79. 是否必须有“交易限制/风控阈值”？
A：通常需要。包括价格保护（price collar）、成交量限制、撤单率阈值、异常波动暂停、API 速率限制等，防止系统被滥用或造成市场冲击。

Q80. 如何处理“自成交/同一客户多账户”的风险？
A：需有识别与限制机制：账户关联识别、禁止自成交设置、异常交易报警、客户多账户政策与例外审批；在某些平台监管框架下对“单一客户多账户”有更严格限制。

Q81. ATS 是否要有“投诉与争议处理”机制？
A：要。投诉、争议、错误交易、系统故障导致损失的处理必须制度化：受理、调查、证据提取、决定、补救、复盘与整改闭环。

Q82. 是否需要对参与者进行持续监测（行为合规）？
A：需要。ATS 提供者应持续监测参与者是否违反规则（操纵、滥用 API、刷量、违规接入），并保留处置记录（警告、限制、暂停、终止）。

Q83. 交易监控发现可疑行为，是否要向 SFC 报告？
A：视事件性质、影响与适用规则而定。一般重大事故、潜在市场失序或重大违规，监管期望及时知会并提交调查与补救计划；需把报告触发阈值写入事件管理制度。

Q84. 系统事故（如撮合错误）如何“先止损再取证”？
A：优先控制扩散：暂停相关功能/市场、冻结异常订单；同步启动取证：锁定日志、保存快照、记录决策链与时间线；随后按规则进行错误交易处理与公告，并复盘整改。

Q85. “错误交易（error trades）”能否取消？
A：可在规则中预设取消/更正机制（条件、流程、权限、通知），并确保对所有参与者公平一致；无规则或临时拍脑袋是监管高风险点。

Q86. ATS 是否需要“内部审计/独立审查”？
A：建议具备独立审查能力（内部或外包）。重点审查系统控制、监控有效性、记录完整性、外包治理、事件管理与合规执行。

Q87. 代码/算法是否需要可解释与可审计？
A：对撮合逻辑、风控阈值与关键规则参数，需要可解释与可追溯（版本管理、变更审批、测试证据、上线记录），否则难以证明公平与可控。

Q88. 是否必须保存“完整订单簿历史（order book history）”？
A：如你的 ATS 以订单簿为核心，完整订单簿事件流（下单、改单、撤单、撮合、成交）是最关键的审计材料之一；具体保存粒度应与监管检查与争议处理需求匹配。

Q89. 清结算由第三方做，记录谁来保存？
A：你必须确保你能取得并保存与 ATS 运营相关的完整记录；第三方记录不能成为你缺失证据链的理由。合同应约定数据提供、保留期限、审计权与应急支持。

Q90. ATS 能否接入多个流动性池并做“智能路由”？
A：可以，但需清晰披露路由逻辑、优先级与潜在利益冲突，并确保路由不会造成不公平或误导；同时要有监控机制验证路由执行的合规性。

E. 运营、合规与持续义务（拿牌后怎么活）Q91–Q120

Q91. Type 7 持牌后最重要的“日常动作”是什么？
A：四件事：监控（surveillance）日常化、变更管理严控、事件管理与报告机制可用、记录与审计链不断档。

Q92. 哪些变更通常需要特别谨慎（甚至先沟通监管）？
A：重大系统改造/更换撮合引擎、规则/费率重大调整、客户范围变化（PI→零售）、新增产品类别、关键外包商变更、控制人/RO 变更、清结算路径变化等。

Q93. 可以频繁迭代上线吗（像互联网公司那样）？
A：可以迭代，但必须受控：分级审批、灰度发布、回滚、监控与复盘；关键规则与撮合逻辑变更要更严格，避免引发市场公平与系统性事故。

Q94. 对外公告与信息披露要做到什么程度？
A：至少做到：规则清晰、费用透明、风险提示充分、停机/事故及时通知、重大变更提前告知与生效期合理；并对参与者一视同仁。

Q95. 如何证明我没有“选择性对待”某些参与者？
A：用制度+日志证明：接入标准一致、撮合规则一致、延迟与优先级一致、异常处置一致；对例外情况必须有审批记录与合理性说明。

Q96. ATS 的费用模型有哪些监管关注点？
A：关注是否诱导不当交易（刷量返佣）、是否造成利益冲突、是否对不同参与者差别待遇不透明；费用与回扣应透明并可解释。

Q97. 我能否做“做市/自营”并同时运营 ATS？
A：可能引发重大利益冲突与市场公平疑虑；需要强隔离（信息墙、账户隔离、权限隔离、监控增强）、透明披露与董事会监督。

Q98. 持牌后遇到可疑操纵，我是否要冻结账户？
A：应按规则与合约行事：先触发风控措施（限额/暂停/冻结），同时保留证据与启动调查，并按事件严重性决定是否通知监管与执法。关键是“有章可循、处置可审计”。

Q99. 参与者违规如何处分才“站得住”？
A：要有明确的纪律机制：违规定义、证据标准、处分梯度（警告→限制→暂停→终止）、申诉机制与记录保存；临时决定容易被质疑不公平。

Q100. 业务连续性计划（BCP）最低要包括什么？
A：灾备架构、RTO/RPO 目标、故障切换演练、通讯与公告机制、关键人员名单与替补、第三方依赖点与替代方案、恢复后的对账与错误交易处理。

Q101. 我能否把 BCP/DR 全部外包给云厂商？
A：云可用，但责任不能外包。你必须验证云与供应商能力、合同 SLA、演练结果、数据可恢复性与退出迁移路径，并保留审计权。

Q102. 需要定期向 SFC 提交哪些报告？
A：取决于你的持牌条件与业务类型。一般会涉及财务申报、重大事件/事故报告、业务变更通知、以及按监管要求提供的系统/监控/运营资料；VATP 场景报告要求更体系化。

Q103. “重大事件”通常包括哪些？
A：系统重大故障、数据泄露、撮合错误导致大量错误交易、监控发现重大操纵/欺诈、关键外包商崩溃、关键人员离任、无法持续营运等。

Q104. 如何准备 SFC 现场检查/主题审查？
A：准备“证据链资料包”：制度全集、系统架构与控制点、监控报表样例、日志抽样、变更记录、事故记录、演练记录、外包尽调与合同、董事会/合规会议纪要。

Q105. 监管常抽查的“ATS 高危点”有哪些？
A：监控有效性（是否能抓到操纵）、记录完整性（是否有缺口/可篡改）、规则公平性、停机处置是否偏袒、外包是否失控、权限是否过度集中、变更是否无审批。

Q106. 如果我想新增“零售客户”，需要做什么？
A：需重新评估客户保护、适当性、风险披露、投诉处理与教育材料，并可能触发牌照条件调整或更严格要求；虚拟资产平台场景对零售开放尤其敏感。

Q107. ATS 是否需要 AML/KYC？
A：是否需要取决于你是否在业务链条中承担客户开户与交易关系、是否涉及资金流与身份识别义务来源（例如同时持有其他牌照或 AMLO 相关义务）。即便不是 AML 义务主体，参与者接入也应有足够尽调以控制滥用风险。

Q108. “客户款项隔离”与 Type 7 有直接关系吗？
A：Type 7 的核心不在托管，但一旦你的模式涉及客户款项/资产安排，就会触发客户资产保护、内部控制与潜在额外监管要求；因此在商业模式设计阶段要先把资金流与资产流画清楚。

Q109. 我能否在 ATS 中提供杠杆/融资？
A：可能触发其他受规管活动与更高风险（如保证金融资等概念相关要求）；需非常谨慎评估牌照组合与风险控制能力。

Q110. 交易数据跨境传输是否可行？
A：可行但需做好数据治理：最小化、加密、访问控制、日志留存、第三方合规、以及私隐法与合同披露；监管检查时你仍需确保数据可及时提供。

Q111. 如何设置“权限分层”才符合监管预期？
A：至少做到：开发、运维、合规监控、业务运营权限分离；关键操作双人复核；管理权限有日志与告警；紧急权限（break-glass）要可审计并事后复盘。

Q112. 参与者 API 权限与限速为何重要？
A：API 是 ATS 风险放大器。限速、白名单、密钥轮换、异常调用监控、风控阈值与熔断机制可防止刷单、DDoS、策略失控导致市场异常。

Q113. “撮合优先级”要怎么写才不踩雷？
A：要明确并一致执行：价格优先/时间优先/数量优先/做市特殊规则等；任何“隐藏优先级/暗箱通道”都会被视为严重不公平。

Q114. 可以设置“VIP 更低延迟/更高优先级”吗？
A：高风险做法。若存在差别待遇，必须披露并证明其合理性与不损害市场公平；多数情况下更建议只在费用与服务支持上差异化，而不要在撮合公平性上差异化。

Q115. ATS 如何应对“闪崩/极端波动”？
A：需要波动控制：熔断、价格保护、分层限价、暂停与恢复规则、公告机制，以及事后错误交易处理与复盘；并通过压力测试证明有效。

Q116. 若发现系统被入侵，第一小时要做什么？
A：切断扩散（隔离系统/停交易/撤销密钥）、保全证据（日志/镜像/时间线）、启动应急小组、评估客户与市场影响、准备对外沟通与必要时监管通报，并同步推进修复与复原。

Q117. SFC 会如何看待“无重大事故但经常小故障”？
A：频繁小故障反映系统治理不足。监管更看重你是否有：根因分析（RCA）、整改闭环、变更质量提升、监控指标改善；否则可能影响适当人选评价与持续合规风险。

Q118. 什么时候需要考虑“有序退出（wind-down）”？
A：当无法持续营运、关键外包失效、资本不足、系统重大缺陷无法及时修复、或监管要求停止业务时，应启动退出计划：暂停新交易、保护参与者权益、保存记录、清理未结事项并沟通监管。

Q119. Type 7 持牌后能否“换 RO 不通知”？
A：不可以。RO 属关键岗位，变更通常需要按规定审批/报备并确保值勤安排与职责交接到位。

Q120. Type 7 合规体系如何做到“可复制交付”？
A：建议用“ATS 合规包”标准化：规则手册 + 监控 SOP + 记录保存政策 + 变更管理 + 事件管理 + 外包治理 + BCP/DR + 审计计划，并绑定系统证据链模板（日志字段表、报表样例、演练记录表）。

F. 客户资产、客户保护与合同安排（“你能不能碰钱/碰币/碰证券？”）Q121–Q150

Q121. 持有 Type 7（ATS）牌照，是否等于可以持有客户资产？
A：不等于。Type 7 的核心是“提供交易设施/系统/规则”，并不天然赋予你“托管/保管客户资产”的权限。是否能“持有/控制”客户资金或资产，取决于你的业务链条是否触发其他受规管活动、客户资产规则、以及你在客户协议与资金/资产流中扮演的实际角色（例如是否代客户收付、是否作为对手方、是否控制钱包/证券账户）。

Q122. ATS 平台最容易踩雷的“资产碰触点”有哪些？
A：常见踩雷点包括：

平台收取客户入金并集中管理；2) 平台代客户进行交收/代付；3) 平台控制客户钱包私钥/多签；4) 平台以“保证金/杠杆”形式占用客户资产；5) 平台对客户资产设定冻结/划拨权限但缺乏清晰法理与授权文件。原则：资金/资产流要画到“谁控制、谁可动用、谁承担对账与追索”。

Q123. 如果平台不触碰客户资金，只做撮合，客户与清算行/经纪直接交收，可以吗？
A：可以，这是常见的“轻托管/不托管”结构。但你必须把：**交收路径、对账责任、失败交收处理、争议处理、以及客户误解风险（谁对资产安全负责）**写清楚，并在系统上保留可追溯记录（确认、回报、状态变化、异常处理）。

Q124. ATS 平台是否需要“客户款项隔离”机制？
A：若你根本不收付客户款项，隔离机制更多体现在“你不得形成事实上的资金池”；但只要你一旦触及客户款项/资产，隔离、授权、账目分离、对账与控制就会成为监管重点（并可能触发额外规则/牌照组合）。建议：从商业模式设计阶段就把“是否收付/是否控制”做成红线管理。

Q125. 平台能否以“平台名义”开立银行账户收款，再转给第三方？
A：高风险。即便出发点是“流程便利”，但会形成资金池与责任错位。合规上更推荐：由客户直接向其经纪/托管/清算机构付款，或采用受监管第三方支付/信托/托管结构；否则需极强的法律文件、内部控制与审计链条支撑。

Q126. 客户协议至少要覆盖哪些核心条款？
A：建议形成“ATS 参与者/客户总协议 + 规则手册 + 风险披露 + 数据与隐私条款”的组合文件，至少覆盖：

平台角色与责任边界（撮合者/设施提供者/是否对手方）
交易规则（撮合优先级、有效指令、撤单、错误交易）
费用与收费时点（含回扣/返佣如有）
风险披露（系统风险、市场风险、流动性风险、停机风险）
争议处理与投诉流程
终止与账户处分机制（冻结/暂停/终止条件）
数据使用、日志保存与监管披露
适用法律与管辖（通常香港）

Q127. 风险披露写得越长越好？
A：不以“字数”取胜，而在“可理解 + 可证明已披露”。建议用：分层披露（摘要/要点/全文）+ 勾选确认 + 关键条款醒目提示，并在系统留痕（版本号、确认时间、IP/设备、语言版本）。

Q128. ATS 平台是否需要做“适当性（Suitability）”？
A：取决于你是否提供受规管的建议/招揽、是否涉及复杂产品或零售客户、以及你的业务是否与 Type 4/5/6/9 等发生交叉。即便不构成法定“建议”，你仍需要确保：客户不会因界面设计/营销话术被误导为“平台保证收益/平台推荐策略”。（实务上常用“非建议声明 + 行为边界 + 监控营销内容”三件套。）

Q129. 平台提供“策略市场/量化信号”，会触发适当性吗？
A：可能。若你提供的内容构成对证券/期货的投资意见或推荐，可能触发相关受规管活动。建议：将“教育/信息”与“建议/推荐”严格隔离，并在内容治理上设审核、留痕与下架机制。

Q130. 客户保护机制里，SFC 最看重哪三块？
A：在 ATS 场景通常是：规则公平透明、系统稳健可控、监控与记录可追溯。这些直接决定市场公平与事故可处置性。

Q131. ATS 平台是否允许“负余额/穿仓”？
A：如果你的结构涉及保证金或杠杆，穿仓与负余额将带来信用风险与客户争议高发。监管上你必须：有清晰风控阈值（强平、追加保证金、熔断）、穿仓承担规则（谁承担/如何追索）、以及在客户协议中明确披露与授权。

Q132. “错误交易”如何处理才不构成不公平？
A：关键是“事先规则”。建议在规则手册中预设：错误交易定义、触发条件、取消/更正流程、权限与复核、通知机制、争议处理与复盘。ATS 指引强调规则与记录的重要性。

Q133. 平台能否对不同参与者设置不同撮合优先级？
A：高度敏感。若存在差别待遇，必须具备：合理性、透明披露、可审计证明一致执行。否则容易被视为不公平或“暗箱通道”。

Q134. 可否给 VIP 更低延迟、更快通道？
A：对“撮合公平性”影响极大，风险很高。更建议把差异化放在：客户支持、报表服务、接口规格（在不影响撮合公平的前提下）等，而不是影响成交机会的“速度/优先级”。

Q135. 平台营销材料最常见的合规问题是什么？
A：常见包括：夸大流动性、暗示保本保收益、把“回测”说成“可复制收益”、把“信息”包装成“推荐”、对费用/滑点/延迟/停机风险披露不足。建议：建立营销审批流程与黑名单用语库。

Q136. ATS 平台是否需要“客户教育/风险提示页面”？
A：强烈建议，尤其是面向较广泛客户时。教育材料不是装饰品，而是降低误解与投诉的关键证据；建议与风险披露联动，并保留客户阅读/确认记录。

Q137. 平台收取“交易佣金 + 做市返点”，是否构成利益冲突？
A：可能构成。需要披露收费结构、回扣安排与潜在激励，并建立冲突管理：例如独立定价/监控、禁止利用客户订单信息牟利、对做市行为设监控阈值与审计。

Q138. 平台若同时做自营/做市，客户保护怎么做？
A：至少要做到：账户隔离、信息墙、权限隔离、交易监控加强、异常交易复核、董事会层面的利益冲突披露与监督。否则“既当裁判又当运动员”的质疑难以消除。

Q139. ATS 平台是否可以限制客户类别（仅 PI）？
A：可以。限制客户类别通常有助于降低客户保护压力，但不免除 ATS 的核心要求（系统稳健、监控、记录、规则公平）。若涉及虚拟资产平台，还需对照相应持牌框架的客户范围安排。

Q140. 平台能否允许同一客户开多个账户？
A：可以设规则允许或限制，但必须：有合理目的、可控、可监测、并在 AML/行为监控上能识别关联关系，防止刷量、对敲、规避限额等。

Q141. 客户投诉通常集中在哪些点？
A：高频点：成交争议（滑点/延迟/撤单失败）、系统故障损失、规则变更未提前告知、费用不透明、异常冻结/限制账户、错误交易处理不一致。

Q142. 投诉处理机制需要哪些“证据链”？
A：至少包括：交易与订单日志、系统状态日志（延迟/错误码）、客户确认记录（风险披露/规则版本）、内部处置记录（谁审批、何时决定）、以及最终答复与补救方案。

Q143. 平台能否单方面修改规则并立即生效？
A：不建议。即便合同允许，也会带来公平性与争议风险。合规做法是：重大变更提前公告、给合理生效期、保留旧规则下未完成订单的处理方案、并保留客户可下载的版本记录。

Q144. “暂停交易/停机”后订单怎么处理？
A：必须事先规定：保留还是取消、恢复后是否重报、哪些订单失效、以及客户如何确认。并做到对所有参与者一致、公平。

Q145. 平台是否需要“黑名单/拒绝客户”机制？
A：需要。用于处理：涉嫌操纵、滥用 API、欺诈、身份不明、制裁命中、以及严重违规。关键在于：规则明确、证据充分、处置留痕、申诉机制可用。

Q146. 客户/参与者终止关系时，要保留哪些资料？
A：应保留：合同与披露确认、交易/订单记录、投诉与争议记录、关键通讯记录、以及监管或法律要求的保存期限内所有可追溯材料。

Q147. 平台是否可以对客户资金/资产做“冻结/划拨”？
A：只有在你拥有明确的法律依据、合同授权与内部审批机制时才可行，并且必须可审计、可解释、可对外披露。无授权的冻结/划拨极易引发投诉与监管关注。

Q148. ATS 平台是否需要购买保险（PI/Cyber）来覆盖客户损失？
A：不一定“强制”，但从风险管理与商业谈判角度，专业责任险/网络安全险常被视为成熟运营的组成部分，尤其当你面对机构客户或规模较大时。

Q149. 如何把“客户保护”写进业务说明书让监管一眼看懂？
A：用四张图最有效：

客户旅程图（开户→下单→成交→交收→对账→争议）
资金流/资产流图（谁控制、谁保管、谁对账）
监控闭环图（发现→告警→处置→复盘→整改）
事故处置时间线（T+0 的前 1 小时/24 小时/7 天）

Q150. 客户最关心“平台跑路/停运”，我如何回应？
A：准备一套“有序退出（wind-down）承诺包”：停运触发条件、客户未结订单处理、记录保全、系统与数据可取回、第三方交收/托管安排、以及对客户的通知机制。并把它写进制度与合同附件里。

G. 监管沟通、申请材料与审批节奏（“怎么递交、怎么答问、怎么过 RFI”）Q151–Q180

Q151. Type 7 申请最先要做的 3 件事是什么？
A：

边界判定：你的服务是否构成 ATS、走 Part III 还是 Part V、是否叠加 Type 1/其他；
系统证据链准备：监控、日志、权限、BCP、变更管理可演示；
关键人员到位：RO/合规/风险/IT 负责人职责与履历匹配。

Q152. 申请阶段监管最常问的“第一性问题”是什么？
A：通常是：

你到底提供什么（是否 ATS）？
你的交易规则如何保证公平？
你如何监测与处理操纵/异常？
系统故障如何公平处置？
外包给谁、你如何控制？
这些问题全部可以在 ATS 指引的框架下组织答案。

Q153. 申请材料中，系统部分写“我们用云、很安全”为什么不够？
A：监管要的是“可验证控制点”，例如：访问控制矩阵、关键日志字段表、告警规则库、RTO/RPO、演练记录、渗透测试摘要、变更审批样例。没有证据链，就等于没有控制。

Q154. 业务说明书（BP）建议包含哪些“ATS 专属章节”？
A：建议至少单列：

ATS 规则手册结构与关键规则摘要
市场监控（surveillance）框架、阈值与处置 SOP
记录保存与审计追溯（audit trail）
停机/故障/错误交易处理机制
外包治理与供应商控制
重大事件报告与沟通机制
（这六块是 Type 7 的“必考题”。）

Q155. RO 面谈通常考什么？
A：RO 面谈通常不只问法规条文，而是问“你是否能控制系统”：

如何判断操纵与异常？
告警触发后谁决定暂停交易？
规则变更谁批准、怎么公告？
故障时如何保证公平？
你如何监督外包商？
建议准备“10 分钟速答版 + 30 分钟深答版”题库。

Q156. 申请时是否要提供“规则手册（Rulebook）”？
A：通常建议提供，至少提供关键规则摘要与版本控制机制。规则越清晰、越可执行、越能减少监管对“不公平/不透明”的担忧。

Q157. 申请时需要提供哪些 IT/安全类附件最加分？
A：常见加分件：

系统架构图（含数据流、权限分层）
关键控制清单（Control Catalogue）
渗透测试/漏洞扫描摘要与整改闭环
DR 演练记录
关键日志字段表与样例
监控报表样例（异常交易/撤单率/延迟/自成交等）

Q158. “外包”在申请时需要提交哪些信息？
A：至少要准备：供应商尽调摘要、合同关键条款（SLA、审计权、数据权、变更控制、退出）、服务范围边界、应急支持与升级路径、以及你内部如何监督的机制。

Q159. 如何处理监管的补件/问询（RFI）？
A：用“逐条闭环”方法：

对每一问给出：结论 + 证据链接（制度/截图/日志/样例）+ 责任人 + 生效日期
不要只给文字；要给“可验证材料”
同步更新索引目录（RFI Index）便于监管复核

Q160. 申请过程中可以一边开发系统一边递交吗？
A：可以分阶段，但要确保关键控制能在合理时间内落地并可演示。纯概念阶段递交风险高，容易陷入多轮补件。监管对 ATS 的系统可控性要求较明确。

Q161. 申请前是否建议与 SFC 预沟通？
A：建议。尤其是：边界不清（是否 ATS）、路径不清（Part III vs Part V）、或涉及跨境结构/白标/多牌照组合时，预沟通能显著减少返工。

Q162. 申请时“公司治理”要怎么写才像样？
A：建议用“责任矩阵（RACI）”：董事会、RO、核心职能主管、合规、风险、IT 安全、运营分别对：规则治理、监控处置、变更管理、事故响应、外包监督承担什么责任，并附会议机制与汇报频率。

Q163. 申请时“合规手册”要不要把所有内容都塞进去？
A：不建议塞成一本大杂烩。更好的交付结构是：

总合规框架（Compliance Framework）
专题制度（ATS Rulebook / Surveillance SOP / Incident SOP / Outsourcing Policy / Records Policy）
表格与日志模板（可打印、可审计）
这样监管检查也更友好。

Q164. 申请被问到“你们如何确保市场公平”，最强回答结构是什么？
A：用“四段论”：

规则公平（撮合优先级、差别待遇披露）
监控有效（模型/阈值/处置）
记录可追溯（日志字段、不可篡改、检索）
事故公平处置（停机、错误交易、公告）
这与 ATS 指引关注点高度一致。

Q165. 申请阶段能否先限制业务范围（例如只做某类产品/只做 PI）来更易获批？
A：可以，这是常见策略：先做“范围可控、风险可控”的 MVP，拿到监管信任与运营记录后，再申请扩展。扩展时按“变更管理 + 风险评估 + 证据链升级”推进。

Q166. 如何证明“我不是交易所（RE/RC）”，只是 ATS？
A：要从三方面说明：

你的设施定位与市场影响（参与者范围、产品范围）
你是否制定/执行类似交易所的上市、停牌、监管规则
你与清算/交收的安排与责任边界
并以组织结构、合同主体、规则手册与系统功能佐证（不要只口头描述）。

Q167. 如果监管认为我更像 Part III 授权（而不是 Part V Type 7），怎么办？
A：需要调整路径与材料侧重点：Part III 授权更强调“设施/市场基础设施”属性、系统性风险与更高层级的治理与稳健性安排。你应尽早在预沟通中确认路径，避免材料写到一半再推倒重来。

Q168. ATS 定义是否包括 OTC 衍生品交易/清算相关设施？
A：是的，历史上 ATS 定义的适用范围曾因 OTC 衍生品市场监管发展而扩展，SFC 也发布过相关通函/说明，提醒市场关注扩展定义的影响。

Q169. 申请材料里“最容易被质疑不真实”的部分是什么？
A：通常是：预算（系统与人力成本明显低估）、外包控制（合同没有审计权/退出权）、监控（只有口号没有规则库）、以及 RO 履历（与 ATS 风险不匹配）。解决方法：用“样例报表 + 样例日志 + 演练记录 + 岗位职责”把真实性钉死。

Q170. 申请时是否需要提供“合规培训计划”？
A：建议提供。尤其是针对：监控人员、运维人员、客服、业务开发团队的培训计划与记录模板，证明你能持续合规运营，而不是“拿牌即散”。

Q171. 如何把“系统变更管理”写得可落地？
A：给监管看三样东西最有效：

变更分级标准（重大/一般/紧急）
变更审批流（含合规/风险/IT/业务签批）
变更证据样例（工单、测试结果、上线窗口、回滚记录、上线后监控）
ATS 指引强调系统控制与记录，你的变更管理要能“落到日志”。

Q172. 若 SFC 要求演示系统，我应该演示什么？
A：建议按“监管视角脚本”演示：

下单→撮合→成交→回报（含日志）
触发异常监控→告警→处置（暂停/限额/冻结）
规则变更→公告→版本留痕
故障模拟→停机公告→恢复→对账
把“可控性与公平性”演示出来。

Q173. 申请阶段如何处理“数据与隐私”问题？
A：建议建立：数据分类分级、访问控制、加密与备份、跨境传输评估、供应商数据条款、以及对监管披露的法律基础与流程。并在客户条款中明确数据用途与保留期限。

Q174. 申请阶段是否需要“独立审计/独立评估”的承诺？
A：很多成功案例会在申请材料中写明：上线前与上线后的独立评估计划（例如网络安全评估、监控有效性审查、DR 演练审阅）。这能增强监管信心。

Q175. 获批后还会被加牌照条件吗？
A：有可能。SFC 可按个案施加条件（例如客户范围、产品范围、报告义务、系统控制等）。因此材料写得越清晰可控，越有机会把条件控制在可接受范围内。

Q176. 拿牌后想扩大业务范围，怎么做最稳？
A：用“扩展包”思路：新增产品/客户/功能 → 风险评估 → 制度更新 → 系统控制升级 → 测试与演练 → 变更审批与必要沟通监管 → 上线后监控复盘。不要直接上线再补文件。

Q177. 申请时如何证明“持续运营能力（going concern）”？
A：用三类证据：

财务预算与资金安排（至少 12–24 个月）
人员与关键岗位配置（含替补）
供应商与基础设施稳定性（合同期限、退出方案）
SFC 在《Licensing Handbook》亦强调申请人须具备适当资源与管治安排。

Q178. 申请被拒绝最常见的根因是什么？
A：通常不是单点问题，而是“整体不可控”：边界不清 + 系统证据不足 + 关键人员不匹配 + 外包失控 + 预算不可信。解决要“整体重构”，而不是局部补丁。

Q179. 我如何为“监管现场检查”提前做准备（申请阶段就开始）？
A：从申请阶段就按“未来检查”建档：制度版本库、日志字段表、监控规则库、事故与演练记录模板、外包尽调与合同、董事会/合规会议纪要模板。这样获批后立刻进入可检查状态。

Q180. Type 7 项目最实用的里程碑（Milestone）怎么划分？
A：建议 6 个里程碑：
M1 边界判定与牌照路径确认（含预沟通）
M2 治理架构与关键岗位到位
M3 规则手册 + 监控/记录/事故/外包制度成套
M4 系统证据链（日志/报表/演练）可演示
M5 递交申请 + RFI 闭环包
M6 面谈演练 + 获批后持续合规包上线

H. 持牌后持续合规与“日常运营必答题”Q181–Q210

Q181. Type 7 持牌后最关键的“持续合规三件套”是什么？
A：建议你把持续合规拆成三条主线：

规则治理：规则手册/撮合逻辑/费用结构/参与者准入的版本控制与审批；
监控处置：市场监察（surveillance）告警→处置→复盘→整改闭环；
证据链留存：订单/成交/系统状态/权限/变更/事故处置全链路可追溯（可检索、可导出、可审计）。这正是 ATS 指引反复强调的“控制与记录”核心。

Q182. 持牌后是否一定会被现场检查？多久一次？
A：监管检查不一定按“固定周期”，常见触发包括：例行主题检查、规模/风险显著变化、投诉/事故、媒体舆情、跨境风险、或监管抽样。你应按“随时可查”建设档案体系（制度库+日志库+报表库+处置记录库），而不是等通知才补材料。

Q183. SFC 最常要求我持牌后持续输出哪些管理报表？
A：没有唯一标准模板，但实务高频要求包括：

异常交易/可疑行为监控报表（自成交、对敲、拉抬/打压、刷量、异常撤单等）
系统可用性与延迟报表（关键时段延迟、故障、恢复时间）
事故与重大事件记录（影响评估、客户通知、整改闭环）
规则变更与公告记录（版本号、审批链、影响范围）
外包商 SLA 与问题工单统计（含升级路径是否有效）

Q184. 持牌后我可否频繁改交易规则或撮合参数？
A：可以改，但必须“可控+可追溯+公平”。你需要：变更分级、审批流程（业务/风险/合规/IT）、上线前测试证据、上线窗口与回滚方案、上线后监控与复盘；并对可能影响公平性的变更做提前披露或公告安排。ATS 指引的逻辑是：系统变更本身就是风险源。

Q185. 什么属于“重大规则变更”，需要更强的披露/通知？
A：一般包括：影响撮合优先级/延迟/订单类型、影响费用结构、影响参与者准入与限制、影响停机/错误交易处置规则、影响做市/流动性安排等。原则：一切会改变客户成交机会或交易成本的，都按重大变更管理。

Q186. 持牌后可以新增产品线吗（新增证券/期货品类、或新增 OTC 衍生品相关）？
A：可以，但应走“扩展包”流程：新增范围界定→风险评估→制度/规则更新→系统控制升级→测试/演练→必要的监管沟通→上线后强化监控。若涉及 ATS 定义扩展或 OTC 衍生品相关边界，也要特别谨慎对照监管口径。

Q187. 持牌后新增“参与者类别”（例如新增海外参与者/更多 API 客户）有什么坑？
A：主要坑在：跨境合规、客户身份与 AML 强度是否足够、网络安全暴露面增加、以及市场行为风险加大。建议：为新参与者类别做单独准入标准（KYC、技术接入测试、限速/限额、监控阈值更严格）。

Q188. Type 7 持牌后，是否必须有“市场监察（surveillance）团队”？
A：要看规模与风险，但监管预期是：你必须具备有效的监控与处置能力。可以是专岗团队，也可以是按规模配置的岗位组合（合规/风控/运营/IT 联动），但必须：职责明确、值守安排明确、处置权限明确、且能证明监控有效。

Q189. 市场监察最少要覆盖哪些“异常行为类型”？
A：至少建议覆盖：

自成交/自撮合（wash trades）
对敲/关联账户刷量
异常撤单率/报价填塞（潜在 spoofing/layering 风格特征）
异常价格偏离/拉抬打压
异常 API 行为（高频爆发、异常重试、绕过限速）
并为每类异常设置：阈值、告警级别、处置动作、复核与升级路径。

Q190. 监控触发后，我可以直接“暂停某客户交易”吗？
A：可以，但必须：事先在规则/合同里约定暂停/限制的触发条件与权限；处置过程要留痕（告警截图/日志、审批人、执行时间、通知记录），并提供申诉与复核通道，避免“选择性执法”的质疑。

Q191. 持牌后“错误交易/明显错误价格”处理要做哪些常态化建设？
A：你需要把“错误交易”做成制度化模块：定义、触发条件、取消/更正权限、双人复核、通知模板、对所有参与者一致适用的原则、以及每次事件后的复盘与阈值调整。ATS 指引强调规则透明与记录可追溯。

Q192. 交易争议发生时，SFC 最看重我能提供什么？
A：最看重“事实链”：订单/成交日志、系统状态（延迟/报错/撮合队列）、规则版本与客户确认、当班值守记录、处置审批记录、以及对外沟通记录。你能“还原全流程”，就能把争议从情绪拉回证据。

Q193. 我需要为客户提供哪些“交易后报表/对账”功能？
A：至少建议：订单回报、成交回报、费用明细、日结对账（或可下载交易明细）、以及争议窗口期说明。对机构客户通常还要求：API 回报字段稳定、报表可审计、版本变更可追溯。

Q194. Type 7 持牌后客户资金/资产如果交由第三方托管，我还需要做什么？
A：你仍要做“责任边界管理”：

合同中明确托管方职责、失败交收处理、赔付/追索边界
系统上明确状态回报与对账机制
供应商治理：尽调、SLA、审计权、退出方案
避免客户误解“平台负责托管安全”。（平台不托管≠不负责解释与信息披露。）

Q195. 我是否需要“规则手册（Rulebook）年度复核”？
A：强烈建议至少年度复核一次，且重大变更随时复核。把复核做成董事会/管理层的固定议程，并留存会议纪要与版本对比说明，便于证明治理有效。

Q196. 持牌后新增收费项目（例如新增接入费、行情费）需要注意什么？
A：注意三点：透明披露（明码标价、何时计费、可否退费）、利益冲突（是否引导不当交易）、以及公平性（是否造成差别待遇）。对机构客户尤其要注意合同补充协议与生效期安排。

Q197. Type 7 是否要求“值勤安排/关键岗位在岗”类似机制？
A：ATS 业务具有实时性，你必须有可用的值守机制：交易时段监控值守、事故响应 on-call、关键审批人替补、以及升级联系人清单。否则一旦故障或操纵风险发生，你无法证明“可控”。

Q198. 哪些事件应被定义为“重大事件（Major Incident）”？
A：通常包括：系统长时间不可用、撮合错误、价格异常导致大量客户损失、数据泄露、权限被入侵、外包商严重故障、监控系统失效、或任何可能影响市场公平与客户利益的事件。ATS 指引的思路是：能影响公平与秩序的，就是重大。

Q199. 重大事件发生后，我内部要走什么“标准时序”？
A：建议固定“事故时间线”：
T+0–15min：止血（暂停/限流/熔断）+ 事件分级
T+15–60min：影响评估（范围、参与者、数据完整性）+ 内部升级（RO/合规/管理层）
T+24h：根因初判 + 临时补救 + 对外通知策略
T+7d：根因报告 + 长期整改 + 演练更新
并将每一步“谁批准、何时执行、证据在哪里”固化为模板。

Q200. 持牌后必须做哪些演练（BCP/DR/事故响应）？
A：建议至少：灾备切换演练（含 RTO/RPO）、事故响应桌面演练（含操纵/攻击/数据泄露）、以及重大变更上线回滚演练。演练记录是监管检查时非常“硬”的证据。ATS 指引强调系统稳健与控制。

Q201. 记录保存（records retention）要保存多久？保存哪些？
A：具体年限与范围需结合你适用的监管要求与业务类型，但在 ATS 语境下，监管最关注你能否完整保存：订单/成交/撮合、系统状态、权限与操作、变更记录、监控告警与处置、客户确认与披露版本等“审计追溯”材料。ATS 指引强调审计追溯与记录。

Q202. 日志要“不可篡改”到什么程度才算合格？
A：实务上建议满足：

权限分离（写入与读取/导出分离）
完整性校验（hash/签名/审计链）
访问留痕（谁看过、谁导出过）
保留与归档策略（热/冷存储）
只要你能证明：事后可复核、可追责、可还原，就能显著降低监管疑虑。

Q203. 如果采用云服务（AWS/Azure 等），监管会担心什么？
A：主要担心：数据主权/跨境、访问控制、供应商锁定、事故响应与审计权、以及退出计划。你要准备：云架构控制点、密钥管理、日志完整性、供应商审计条款与退出方案（含数据可迁移）。ATS 指引也强调外包/系统控制。

Q204. 持牌后若要引入白标合作方（White-label），合规要点？
A：核心是“谁是 ATS 提供者”。白标极易造成责任边界混乱：客户以为是 A 平台，实际上系统与规则由 B 控制。你必须把：品牌披露、合同主体、规则制定者、监控责任、投诉责任、数据责任写清楚，并确保不出现“监管真空”。

Q205. 外包运维/监控给第三方可以吗？
A：可以，但不等于“甩锅”。你仍必须：供应商尽调、合同审计权、SLA、升级路径、关键控制点在你方可监督、以及退出/替换方案。ATS 指引强调外包治理与控制。

Q206. “供应商审计权”通常要写到什么粒度？
A：建议至少包含：你或你的审计师/监管要求下的第三方可进行审计；审计范围覆盖系统、流程与控制；配合时限与整改义务；以及在重大事故/监管要求下的紧急配合条款。没有审计权，外包基本等于失控。

Q207. 持牌后是否需要定期向管理层/董事会汇报 ATS 风险？
A：强烈建议。ATS 风险具有“系统性与实时性”，管理层/董事会应定期收到：监控指标、事故统计、重大变更、外包风险、以及整改闭环进度。你能拿出固定节奏与纪要，就是治理成熟的直接证据。

Q208. Type 7 与 “电子交易/算法交易”相关的控制要求，怎么落到制度？
A：用“交易生命周期控制框架”落地：
接入（身份/权限/限速）→ 下单（字段校验/风控）→ 撮合（公平性/优先级）→ 回报（完整性/一致性）→ 监控（异常检测）→ 处置（暂停/撤单/更正）→ 复盘（整改闭环）。
每一步对应制度+日志字段+责任人，监管一眼能看懂“你可控”。

Q209. 持牌后是否必须更新《Licensing Handbook》相关要求并自检？
A：建议把《Licensing Handbook》作为你持续合规的“基础清单来源”，尤其是关于 Type 7 适用 Part III 或 Part V 的框架、以及一般持牌与适当人选（fit and proper）持续要求。

Q210. Type 7 与虚拟资产平台（VATP）有什么关系？
A：若你运营虚拟资产交易平台并涉及证券型代币等情形，实务中常见需要 Type 1 + Type 7 的组合，并按 SFC 对 VATP 的相关指引/通函执行额外要求（含外部评估报告等）。

I. 系统、网络安全、权限与事故响应（“监管看证据链”）Q211–Q230

Q211. ATS 系统最关键的“权限控制”要做到什么？
A：做到“三分离”：

开发/运维分离（避免开发直接改生产）
审批/执行分离（关键操作需双人或多签）
读取/导出受控（敏感数据、日志导出需审批留痕）
并配套：定期权限复核、离职即时回收、特权账号（PAM）管理。

Q212. 哪些属于 ATS 的“关键系统”必须纳入更高等级控制？
A：至少包括：撮合引擎、订单网关/API、市场监察系统、日志与报表系统、权限与密钥系统、以及任何能改变撮合/风控阈值的配置中心。关键系统的变更与访问应走更严格的审批与记录。

Q213. 监管检查时，最常抽查哪类日志？
A：高频抽查：

订单全生命周期日志（提交、接受、排队、撮合、成交、撤单、拒单原因）
系统状态日志（延迟、队列、报错、宕机、恢复）
管理员操作日志（改参数、改规则、改权限、导出数据）
监控告警与处置日志（告警→谁确认→谁批准→执行动作）

Q214. 撮合公平性怎么用“系统证据”证明？
A：用三类证据：

规则文档（优先级、时间戳、部分成交规则）
代码/配置的版本与审批记录（证明上线内容与规则一致）
订单队列与成交还原日志（证明实际执行与规则一致）
ATS 指引强调规则透明与审计追溯。

Q215. “时间戳”要不要统一时钟源？
A：强烈建议统一（NTP/时钟源管理），并记录时钟漂移、校准日志。没有统一时钟，事后无法还原“先后顺序”，会直接削弱公平性与争议处置能力。

Q216. API 接入客户最常见的技术合规风险是什么？
A：常见风险：限速绕过、异常重试导致系统压力、字段滥用导致风控失效、以及算法导致市场操纵特征。建议：API 网关限速、签名校验、异常行为封禁、接入前测试认证、并与市场监察联动。

Q217. 我能否允许客户使用“自动下单算法/机器人”？
A：可以，但你必须能监控并抑制其带来的市场秩序风险（例如刷量、异常撤单、操纵特征），并在规则中明确禁止行为与处罚机制（限流/暂停/终止）。

Q218. 如何把“系统容量与压力测试”写成可交付证据？
A：建议形成：容量基准（峰值 TPS、并发连接数）、压力测试报告（脚本、结果、瓶颈、优化）、以及上线后容量监控（报警阈值、扩容策略）。事故发生时，监管会问：你是否“可预见 + 可承受”。

Q219. 系统故障导致成交异常，第一优先是“恢复交易”还是“保证公平”？
A：两者都要，但顺序通常是：先止血确保不扩大不公平（例如暂停/熔断/限制订单），再恢复。恢复前要评估：订单状态一致性、撮合队列完整性、回报是否丢失；否则恢复会放大争议。

Q220. 灾备（DR）最低要做到什么？
A：至少明确：RTO/RPO、灾备切换路径、关键数据备份策略、演练频率与记录、以及灾备期间交易规则（是否暂停、如何公告、如何处理未结订单）。ATS 指引强调系统稳健与应急安排。

Q221. “熔断/暂停交易”机制要怎么设计才不引发投诉？
A：关键是：触发条件透明、适用对象一致、恢复条件明确、公告及时、以及事后复盘与解释充分。所有机制都应写入规则手册并留存版本与生效记录。

Q222. 网络攻击（DDoS/入侵）发生时，监管最关心我做没做什么？
A：最关心：你是否有预案、是否快速止损（限流/封禁/隔离）、是否保护数据完整性、是否保留证据（日志与取证）、是否及时通知受影响方、以及是否形成整改闭环。

Q223. 数据泄露风险，ATS 平台最敏感的数据是什么？
A：至少包括：客户身份/KYC 数据、订单与交易数据、API 密钥、系统配置与密钥材料、以及任何可用于重放交易或绕过风控的数据。敏感数据应加密、最小权限、访问审计。

Q224. “生产环境紧急变更”怎么做才不被质疑？
A：必须有紧急变更流程：触发条件、最小化变更、双人审批（至少事后补批）、回滚计划、以及事后复盘报告。紧急变更是监管常抓的“内部控制薄弱点”。

Q225. 我是否需要定期做渗透测试/漏洞扫描？
A：强烈建议，尤其当你对外提供 API、面向机构客户或规模较大。要点不只是“做了测试”，而是：整改闭环、复测通过、以及把高危漏洞处理纳入董事会/管理层风险汇报。

Q226. 监控系统本身如果故障了怎么办？
A：你要有“监控失效预案”：监控失效视为重大运营风险，可能需要限制交易规模/暂停特定客户/提高人工复核，直到监控恢复。并记录失效期间的补偿性控制（compensating controls）。

Q227. ATS 平台是否需要“独立复核/内审”机制？
A：建议配置。即使是小团队，也至少要有“独立复核”安排（不同于一线运营），定期抽查：规则执行一致性、权限操作合规性、事故处置是否按 SOP、以及外包监督是否有效。

Q228. 如何降低“关键人员离职导致系统失控”的风险？
A：用制度与技术双保险：岗位备份、权限分层、关键操作双人制、配置与密钥托管、文档化（runbook）、以及交接清单。监管不喜欢“单点英雄系统”。

Q229. 我是否需要把“系统演示脚本”作为长期文件保留？
A：建议保留并定期更新。系统演示脚本（撮合→监控→处置→日志导出）既是监管沟通材料，也是内部培训材料，更是事故发生时快速解释的工具。

Q230. 如果未来引入 AI/智能监控模型，会有什么新增合规点？
A：新增点在：模型解释性、阈值可控、误报/漏报管理、训练数据治理、以及模型变更管理（版本控制与审批）。监管关注你是否“可控、可解释、可审计”，而不是你是否“最先进”。

J. 监管措施、违规后果与高风险雷区（“别等执法才补课”）Q231–Q240

Q231. Type 7 最典型的合规雷区有哪些？
A：高发雷区：

规则不透明或执行不一致（差别待遇/暗通道）
监控形同虚设（只有口号无阈值/无处置）
日志缺失或可被篡改（无法还原事实）
外包失控（无审计权/无退出方案）
事故处置不公平（停机后订单处理混乱）
这五类都与 ATS 指引核心要求直接相撞。

Q232. 违规会面临哪些后果？
A：后果通常包括：监管问责、牌照条件加严、业务限制、公开纪律处分、罚款、以及对 RO/管理层的适当人选影响（可能影响其继续担任持牌角色）。具体后果取决于违规性质与影响范围。

Q233. 什么情况最容易触发监管“深挖式”检查？
A：常见触发：严重客户投诉、系统故障造成广泛影响、市场操纵嫌疑、媒体报道、或你业务范围突然扩张但控制体系没跟上。建议：规模增长要同步升级监控、人手与控制证据链。

Q234. 监管检查时，最容易被问到的“灵魂拷问”是什么？
A：一句话：你如何证明你一直在按规则办事？
能回答这个问题的只有证据链：规则版本→系统配置/代码版本→日志→告警→处置→复盘→整改闭环。

Q235. “差别待遇”到底怎么界定？
A：不是说你不能提供差异化服务，而是差异化不能破坏公平交易机会、不能隐蔽、不能随意。若存在差异化（费用、通道、优先级），你必须：透明披露、合理性说明、以及一致执行的审计证据。

Q236. 若发生客户损失争议，我是否应考虑“和解”还是“硬扛”？
A：合规视角不是“硬扛/和解”二选一，而是：先用证据还原事实、确认是否存在规则/系统缺陷、评估是否有持续风险；若属系统或流程问题，通常应同时采取补救与整改（必要时含客户补偿），并把整改闭环留存，避免重复事件。

Q237. 发生重大事故后，我需要对制度做哪些“强制性升级”？
A：通常至少升级：事故分级与响应流程、变更管理、监控阈值、公告与客户沟通机制、以及复盘与整改跟踪机制。事故后“制度不更新”会被认为你没有从事件学习。

Q238. 外包商出问题导致事故，责任在谁？
A：监管通常看“你是否有效监督”。外包不转移你的责任。你必须证明：尽调做过、合同控制点存在（SLA/审计/退出）、日常监督有效、问题发生后响应及时、整改闭环完成。ATS 指引强调外包治理与控制。

Q239. Type 7 在“Part III 授权 vs Part V 发牌”上，持牌后还会被重新判断吗？
A：一般取决于你业务实质是否变化。监管框架明确：ATS 提供者要么走 Part III 授权，要么走 Part V（Type 7）发牌/注册；若你业务性质发展到更像市场基础设施层面的 ATS，可能需要重新评估路径与监管安排。

Q240. 我如何用一句话概括 Type 7 持牌后“合规经营的底线”？
A：一句话：规则要公平透明、系统要稳健可控、监控要真实有效、记录要可审计追溯。这四句话能覆盖 ATS 指引的核心精神，也能覆盖你应对检查、事故与投诉的全部“防线”。

K. 业务边界与“是否触发 Type 7”的典型场景 Q241–Q270

Q241. 判断一个系统是否构成 ATS / Type 7 的“最核心测试”是什么？
A：核心看两点：

你是否通过电子设施提供服务，并且该设施不是认可交易所公司或认可结算所提供的设施；
该设施是否使得买卖要约被经常作出/经常被接受，或经常介绍/识别交易对手以便他们协商或达成证券/期货买卖。这个逻辑直接来自 Schedule 5 对 ATS 的定义，也在 ATS Guidelines 开篇明确引用。

Q242. “认可交易所公司/认可结算所的设施”为什么是关键排除项？
A：因为 Schedule 5 的 ATS 定义本身排除了这类设施。换句话说：如果你只是使用/接入“认可交易所或认可结算所”的系统设施（而不是自己提供一个撮合/介绍/交易设施），监管分析路径就会不同；但你一旦在其外部搭建“自己的电子设施”并形成撮合/介绍/达成机制，就会进入 ATS/Type 7 的评估区间。

Q243. 我做一个“撮合引擎/撮合池（matching engine）”，把买卖盘自动配对成交——一定是 Type 7 吗？
A：高度概率是。因为你在用电子设施使得买卖要约被经常作出/经常被接受，属于典型 ATS 场景。ATS Guidelines 的监管逻辑也是围绕：撮合规则透明、公平执行、系统稳健、监控与记录可追溯来设定。

Q244. 我只提供“电子订单传递/路由（order routing）”到券商或交易所，这算 Type 7 吗？
A：不一定。最新版《Licensing Handbook》明确提示：提供电子 order routing 设施、以及某些“仅传递申购赎回指令/订阅计划”的在线设施，一般不会被视为 Type 7；但中介人仍需确保其服务不落入 ATS 定义，若落入则需 Type 7。

Q245. 我做“引荐/撮合微信群/电报群/论坛”，把买方卖方经常介绍认识，让他们私下谈价格并成交——会触发 Type 7 吗？
A：有触发风险。ATS 定义里就包含“经常介绍或识别他人，以便协商或达成证券/期货买卖”。即使你不做自动撮合，只要你的电子设施经常承担“介绍/识别+促成交易”的功能，就会进入 ATS 分析框架。

Q246. 我只发布“意向（IOI）/广告牌（bulletin board）”，不提供撮合、不自动成交——算 ATS 吗？
A：要看你是否实质上在“经常介绍/识别交易对手并促成协商或成交”。如果你只是信息发布且不组织对接、不过滤匹配、也不形成交易流程，风险相对低；但若你提供筛选、匹配、私聊通道、并以此作为交易达成的主要路径，就可能被视为落入 ATS 定义的“介绍/识别”部分。

Q247. RFQ（询价）系统：买方发 RFQ，系统推给做市/卖方报价，再由买方确认成交——算 ATS 吗？
A：多数情况下属于高风险场景，因为电子设施在“经常引导要约/接受要约”或“经常识别对手方”并促成交易；特别是当系统具备规则（谁能报价、报价优先级、有效期、拒绝/撤销机制等）时，监管会更倾向按 ATS 逻辑要求你证明公平、控制、记录与监控有效。

Q248. 我是“语音为主+系统辅助”的经纪撮合：系统负责识别对手方，最终成交靠电话确认——还会被视为 ATS 吗？
A：仍可能。关键不在“最终用不用电话”，而在你是否提供电子设施用于经常识别/介绍对手方并促成交易。只要该电子设施在交易形成中发挥核心作用，就要按 ATS 定义逐项对照评估。

Q249. 我只给“集团内部/关联方”提供撮合（内部 crossing），不对外开放——还需要 Type 7 吗？
A：对象是否“对外”并不是唯一豁免理由。监管更关注你是否“经营业务（carrying on a business）”提供 ATS；若集团内部撮合仍是业务运作核心、经常发生、并涉及证券/期货交易安排，就应谨慎评估是否构成 ATS 并与专业顾问/监管沟通。

Q250. 我做“智能路由（Smart Order Router）”，把客户订单拆分并路由到不同交易场所——一定是 Type 7 吗？
A：不一定。若你只是提供 order routing（不形成你自己的撮合池/介绍机制），可能落入《Licensing Handbook》提到的“order routing generally would not be regarded as Type 7”的范畴；但你必须证明：你没有实质运行一个“ATS（撮合/介绍/达成）设施”。

Q251. 我提供“算法执行（VWAP/TWAP/冰山单等）”给客户，这是否等同 ATS？
A：算法执行通常发生在持牌中介人的交易执行体系内，未必天然等于 ATS/Type 7；但如果你搭建的电子设施本身具有“经常形成要约/接受要约”或“经常识别对手方并促成交易”的功能（例如内部撮合、内部池化、RFQ 机制），就会靠近 ATS 定义，需要按 Schedule 5 与 ATS Guidelines 进行实质评估。

Q252. 我只提供“行情/报价展示/资讯终端”，不提供下单成交——是否需要 Type 7？
A：通常不需要，因为你并未提供让买卖要约经常作出/接受、或经常介绍对手方以促成交易的设施。但要注意：如果你的“资讯”演变成“引导成交的电子撮合/引荐机制”（例如一键对接交易、自动匹配报价方），风险会升级。

Q253. 我做“复制交易（copy trading）/跟单”，自动复制高手订单——会触发哪些牌照风险？
A：复制交易经常同时触发多维牌照风险：

交易执行/撮合层面：若你提供电子设施使交易要约经常作出/接受或形成撮合，可能涉及 Type 7；
交易指令/建议层面：若你在“推荐/引导”客户交易，也可能涉及其他受规管活动的边界（需整体评估）。
结论：复制交易不是“只看一个牌照”，要按你的实际流程拆解。

Q254. 我提供“白标（white-label）ATS”，客户前端是合作方品牌，但撮合引擎/规则由我控制——谁需要 Type 7？
A：监管会看“谁在实质提供 ATS”。若撮合规则、系统控制、监控与处置由你掌握，你通常会被视为核心 ATS 提供者；合作方若也参与招揽、接入、规则变更或交易组织，也可能触发其自身牌照义务。建议在合同里把：规则制定权、系统控制权、监控责任、投诉责任、数据责任与披露责任写清楚。

Q255. 我使用第三方撮合引擎（外包/采购），自己只做运营与客户接入——我还需要 Type 7 吗？
A：大概率仍需要。外包不改变“你是否在经营 ATS 业务”的法律判断；同时 ATS Guidelines 强调控制、监督、记录与系统稳健等要求，你必须证明外包仍处于你可控的治理框架中（审计权、SLA、退出方案、应急响应）。

Q256. 我计划把系统部署在云上（AWS/Azure）或把运维外包——监管会重点看什么？
A：重点看：访问控制、日志完整性、变更管理、事故响应、审计权与退出计划。你的目标不是证明“云很先进”，而是证明“云也可控、可审计、可恢复”，符合 ATS Guidelines 对系统稳健与控制的预期。

Q257. 我能否给不同客户提供不同“速度/通道/API 优先级”？
A：可以做差异化服务，但必须避免破坏公平或形成“暗通道”。建议：差异化条款透明披露、条件一致适用、技术实现可审计、并用日志证明不存在选择性对待。ATS 的监管精神核心就是公平、透明与可追溯。

Q258. 我既做 ATS，又安排“做市/流动性提供”——会带来什么新增合规点？
A：新增合规点在：利益冲突与市场操纵风险（自成交/对敲/拉抬打压嫌疑）。你需要更强的：隔离机制、监控规则、披露与治理文件，以及对做市策略/账户的限制与审计追溯，确保平台规则不被内部流动性方“反向利用”。

Q259. Type 7 的 RO（负责人员）最低配置要求是什么？
A：根据《Licensing Handbook》的一般要求：你应为每一项受规管活动委任不少于两名负责人员（RO）直接监督；同一活动至少要有一名 RO 随时可用；并且至少一名 RO 必须是执行董事（Executive Director）。

Q260. 同一个人能否同时担任多个受规管活动的 RO？
A：可以，但前提是：该人对每个活动都“适当人选、胜任且无角色冲突”，并且你能证明其时间与管理带宽足以覆盖多条业务线。《Licensing Handbook》明确允许同一人担任多个活动 RO（满足适当人选与无冲突前提）。

Q261. RO 是否可以由“经常不在香港的人”（飞来飞去的 itinerant professionals）担任？
A：监管一般不接受“流动专业人士”担任 RO，因为 RO 需要持续监督相关受规管活动；《Licensing Handbook》明确指出 itinerant professionals 一般不应是 RO。

Q262. Type 7 的“管理层问责（MIC）”与 RO 的关系是什么？
A：SFC 一般预期：核心职能主管（MIC）中的“总体管理监督、关键业务线”等关键岗位，往往需要相应申请成为 RO，以匹配其对业务的实质控制与问责要求。《Licensing Handbook》对 MIC 与 RO 的监管期望有明确提示。

Q263. Type 7 对 RO / 核心人员的“能力证明”通常怎么准备最有效？
A：建议准备三层证据：

经历证据：电子交易/撮合/市场监察/风控/运营/合规管理相关履历与项目说明；
制度证据：你实际能写出并解释规则手册、监控阈值、事故响应、变更管理；
系统证据：能演示从下单→撮合→监控→处置→日志导出的一条证据链。ATS Guidelines 的要求本质上是“你懂、你管得住、你留得下证据”。

Q264. 持牌后 RO/持牌代表是否需要持续培训（CPT）？
A：需要。持牌法团需负责规划并实施持续培训计划，以提升持牌代表的知识与技能；《Licensing Handbook》在“Continuous professional training (CPT)”部分有明确说明。

Q265. Type 7 的年度牌照年费怎么收？有没有豁免？
A：存在豁免情形。《Licensing Handbook》注明：若某人的 Type 7 业务是其 Type 1 或 Type 2 业务的附带活动（incidental），Type 7 的年度费用可获豁免（该处以注释形式说明）。

Q266. 年费逾期不交会怎样？
A：《Licensing Handbook》列出逾期将产生附加费（surcharge），逾期更久可能导致暂停甚至撤销牌照/注册。实务上建议你把“年费与续期”纳入合规日历，避免低级错误造成牌照风险。

Q267. Type 7 对资本金/流动资金是否有硬性要求？
A：SFC 一般要求持牌法团须持续维持符合《Securities and Futures (Financial Resources) Rules（FRR）》等规定的缴足股本与速动资金门槛；《Licensing Handbook》也提醒按 FRR 等规则维持最低水平。具体数额取决于你业务形态与是否叠加其他牌照。

Q268. 我在哪里可以快速核对“我是不是需要申请牌照/注册”？
A：SFC 的“Do you need a licence or registration?”页面强调：Schedule 5 规定了 13 类受规管活动并提供每类的定义，是判断起点；若涉及 ATS（Type 7），还应结合 ATS Guidelines 与 Licensing Handbook 做实质评估。

Q269. 如果我同时做虚拟资产交易平台（VATP），Type 7 会怎么搭配？
A：SFC 的 VATP 专页与 VATP Licensing Handbook 体系里，常见是 Type 1 + Type 7 的组合，并叠加 AMLO 下的 VA 服务牌照要求（视业务而定）。做 VATP 不是“只有 Type 7”，而是“组合牌照+额外合规包”。

Q270. 我是线上平台（online platform operator），我需要同时参考哪些 SFC 指引？
A：如果你是线上分销/顾问平台（ODAP）类业务，相关《Guidelines on Online Distribution and Advisory Platforms》明确提到：其要求适用于 Part III 授权的 ATS 提供者或Part V 下 Type 7 的持牌/注册人，并指向 ATS Guidelines 作为重要参考。

L. 申请/运营关键动作：电子交易、问卷、通知与“合规动作清单” Q271–Q300

Q271. 如果我不属于 Type 7，但我提供电子交易/网上交易服务，还要做什么合规动作？
A：即使不触发 Type 7，《Licensing Handbook》仍指出：中介人如拟通过互联网开展“dealing activities（例如电子交易服务）”，需提交**Questionnaire for Providing Electronic Trading Services（Questionnaire 2）**并书面通知 SFC 上线日期与网站地址。

Q272. “order routing 不算 Type 7”的前提条件是什么？
A：关键前提是：你的服务确实只是“传递/路由”，没有形成 ATS 定义中的撮合/要约经常作出或接受/经常介绍识别对手方并促成交易。SFC 也明确：中介人有责任确保其服务不落入 ATS 定义；一旦落入，就需要 Type 7。

Q273. 我怎样把“我们不做 ATS（不触发 Type 7）”这件事写成可审计证据？
A：建议做一份“业务边界声明 + 流程图 + 控制点清单”：

声明：你不撮合、不形成交易对手识别机制、不组织议价成交；
流程图：订单从客户→你系统→（直接）持牌中介/交易所；
控制点：无内部撮合池、无 RFQ/报价池、无对手方推荐、无成交规则；
并保留系统设计与日志字段说明，便于检查时“用事实证明”。

Q274. Type 7 持牌公司上线新功能/新版本前，最推荐的“合规门禁（gates）”有哪些？
A：建议固定 6 个门禁：

合规/风控评审（是否改变公平性与利益冲突）
规则手册更新（版本号+生效日+披露安排）
测试证据（UAT/压力/回滚演练）
权限审批（生产变更双人制）
监控阈值更新（surveillance 规则同步）
上线后复盘（问题闭环）
这些都与 ATS Guidelines 的“控制、透明、记录”精神一致。

Q275. Type 7 业务是否必须建立“事故响应（incident response）与重大事件分级”？
A：强烈建议必须。ATS 的风险是“实时+系统性”，一旦故障或规则错误会直接影响市场公平与客户利益。ATS Guidelines 的监管框架本质上要求你有能力：识别→止损→沟通→复盘→整改，并留下完整记录。

Q276. 持牌后哪些变更通常需要“先批/先报/通知”？
A：你应以《Licensing Handbook》“After being licensed or registered”章节为底稿建立“变更事项清单”，常见包括：关键人员/RO 变动、业务范围重大变化、系统重大变更、记录保存地点/营业地点变更等；不同事项对应“先批/先报/事后报”的差异。

Q277. Type 7 的“值勤安排/RO 可用性”监管预期是什么？
A：《Licensing Handbook》明确：必须至少有一名 RO 随时可用监督相关业务；若 RO 短期离港可通过“可联系+补偿性内控”作为临时措施，但不应长期化。

Q278. 我们是小团队，能否用“外包监控/外包运维”来替代内部能力？
A：外包可以，但不能替代你的问责。ATS Guidelines 强调：你必须保持对关键控制的监督能力与审计追溯能力（尤其是监控、日志、变更与事故响应）。外包模式反而要求你更强的供应商治理（审计权、SLA、退出）。

Q279. 我如何把“供应商治理”做成监管看得懂的材料包？
A：建议形成“三件套”：

供应商尽调报告（能力、资质、过往事故、数据与安全控制）
合同控制条款摘要（SLA、审计权、数据归属、退出迁移、事故升级）
月度/季度监督报表（SLA 达成、工单、事故、整改闭环）
以此证明：外包在你治理框架内。

Q280. Type 7 是否需要把“规则手册/用户条款/披露文件”作为长期受控文件？
A：是。你应把规则与披露当作“监管级文件”：版本控制、审批链、客户确认记录、重大变更通知记录必须齐备。ATS 的核心是规则公平透明且可被审计还原。

Q281. 如果我计划对公众营销 Type 7 平台，合规宣传有什么要点？
A：要点是：不夸大、不误导、清晰披露风险与限制；尤其避免让客户误解你提供“保本/保收益/必成交”。当你属于线上平台运营者时，也要留意 ODAP 类指引对线上披露与客户保护的监管预期。

Q282. Type 7 平台是否需要设立正式“投诉处理机制”？
A：需要，而且要能落地执行：渠道（邮箱/工单/电话）、响应时限、升级路径、证据调取（日志/录音/截图）、以及复盘与整改闭环。投诉机制不是客服口径，而是“风控与合规的一部分”。（ATS 争议最终都回到证据链。）

Q283. 监管检查时，哪些文件最值得你提前做成“随时可抽查”的一键包？
A：建议至少 8 个文件夹：

规则手册与版本库
系统架构与关键控制点说明
权限与变更管理记录
市场监察规则库+告警处置记录
事故/重大事件记录与复盘
外包治理与供应商审计材料
客户披露与确认记录
日志导出说明（字段字典+取证流程）
这基本覆盖 ATS Guidelines 的核心关注点。

Q284. Type 7 是否必须建立“异常交易监控（surveillance）规则库”？
A：强烈建议必须。至少覆盖：自成交/对敲、异常撤单率、异常价格偏离、异常 API 行为等，并配套阈值、处置动作、升级与复盘。没有规则库，你很难证明“监控有效”。

Q285. 我怎样证明“撮合公平性”不是口号？
A：用三类证据证明：

规则文本（优先级、时间戳、订单类型、错误交易处理）
系统实现证据（版本控制、配置快照、审批链）
还原证据（订单队列与成交重建日志、时间源管理）
这一套是应对争议与检查的“硬通货”。

Q286. Type 7 平台是否需要“系统演示脚本（walkthrough script）”？
A：强烈建议准备并常态更新。脚本应覆盖：接入→下单→撮合→回报→监控告警→处置→日志导出，确保你能在监管沟通/检查/事故复盘中快速展示“可控与可追溯”。

Q287. 发生故障时，我是否可以“先恢复交易再补记录”？
A：不建议。ATS 的风险在于“恢复动作本身可能放大不公平”。正确顺序通常是：止损与保全证据→评估影响→在确保状态一致性与规则可执行后再恢复；并记录每一步审批与执行时间线。

Q288. Type 7 是否需要建立“数据与日志不可篡改”机制？
A：监管目标是“可审计追溯”。你应至少做到：访问留痕、权限分离、导出审批、完整性校验与归档策略。否则争议发生时，你会在“证据可信度”上先输。

Q289. 若我提供服务属于 Part III 的 ATS 授权路径，与 Part V 的 Type 7 持牌路径有什么关键差异？
A：原则上，提供 ATS 的主体要么走 Part III 授权，要么走 Part V（Type 7）发牌/注册；《Licensing Handbook》明确了这一二选一框架，并说明一般实践：若该公司已是其他受规管活动的中介人，通常会走 Part V 的 Type 7。

Q290. 我怎样判断自己应走 Part III 还是 Part V（Type 7）？
A：实务上通常先问：你是否已是“中介人（持有其他牌照/受规管活动）”？若是，《Licensing Handbook》提到的一般实践是：更倾向走 Part V 的 Type 7；若不是，则需要结合业务性质、市场基础设施属性与监管沟通来判断。

Q291. Type 7 持牌申请前，最常见的“被退回/被追问”原因是什么？
A：高频原因包括：业务流程不清晰、控制点不可验证、RO 配置不足或不匹配、系统/监控/记录证据链薄弱、外包治理缺失。建议你把材料按“监管审查矩阵”结构化呈现（规则、系统、监控、记录、治理）。

Q292. 我们做电子交易服务但不做 Type 7，为什么 SFC 还要求提交电子交易问卷？
A：因为电子交易服务仍有市场风险与系统风险。Licensing Handbook 在讨论 order routing 与互联网服务时明确要求：提交电子交易问卷并通知上线日期/网站地址，用于监管掌握你的电子交易控制安排。

Q293. 我上线新网站/新域名/新 App，需要通知 SFC 吗？
A：若涉及你受规管活动的电子渠道、尤其是与电子交易服务相关，按《Licensing Handbook》的指引，应书面通知上线日期与网站地址，并确保相关问卷/资料已提交且与实际一致。

Q294. Type 7 的“对外披露”最容易遗漏什么？
A：最容易遗漏：停机/熔断规则、错误交易处理规则、费用与回扣结构、潜在利益冲突（做市/关联方）、以及客户争议窗口期与证据提供方式。披露缺口会在投诉时被放大。

Q295. Type 7 平台可以做“分层客户”（专业投资者 vs 零售）吗？
A：可以，但分层必须有清晰标准、可审计的准入流程、以及与之匹配的风控阈值/披露强度。若面向更广泛客户群，监管对客户保护与风险披露的预期会更高。

Q296. Type 7 是否需要建立“合规日历（Compliance Calendar）”？
A：强烈建议。至少包含：年费、CPT、规则年度复核、灾备演练、权限复核、外包商季度评估、监控阈值复盘、投诉复盘、审计准备等。年费逾期的后果在《Licensing Handbook》里有明确罚则提示。

Q297. 我们如何把“年度复核”做得更像监管想要的样子？
A：建议年度复核输出三份成果：

规则与披露复核报告（变更清单+公平性评估）
监控有效性报告（命中率/误报漏报/处置耗时/整改）
系统与外包治理报告（事故统计、SLA、演练、整改闭环）
这三份报告基本可覆盖 ATS Guidelines 的主轴。

Q298. 如果我将来扩展为 VATP（含证券型代币等），合规工作量会增加多少？
A：会显著增加，因为 VATP 通常涉及 Type 1 + Type 7 组合并叠加 VA 服务的额外要求；SFC VATP 专页与 VATP Licensing Handbook 提供了专门框架与要求清单。

Q299. Type 7 持牌后，如果我想把业务“升级/扩容”，最安全的策略是什么？
A：用“里程碑式升级”：先确保规则、监控、记录与事故响应足以承载更大规模，再逐步放开客户类别、API 权限、交易时段、产品范围；并对每次升级形成“评估→测试→上线→复盘”的文件闭环，避免规模先行、控制滞后。

Q300. 用一句话总结：Q241–Q300 这一段想解决什么？
A：它要解决的就是四个字：边界可证——你要么证明“我不属于 ATS/Type 7”，要么证明“我属于 Type 7 但可控、可审计、可持续合规”，并且能随时拿出证据链回答监管与客户。

M. 财务资源（FRR）与监管申报 Q301–Q320

Q301. Type 7 持牌法团必须满足哪些“持续性财务资源”底线？
A：SFC 要求持牌法团按《Financial Resources Rules（FRR, Cap.571N）》持续维持不少于规定的**缴足股本（paid-up share capital）与流动资金/流动资本（liquid capital / liquid assets vs required liquid capital）**等指标，并按规则计算与申报。

Q302. “流动资本（liquid capital）”是什么？如何快速理解？
A：FRR 体系下，通常可理解为：用规则口径计算的流动资产（liquid assets）减去认可负债（认可扣减项）后的结果，并需始终高于规定所需流动资本（required liquid capital）。SFC FAQ 也明确：不同受规管活动的最低门槛在 FRR Schedule 1，并需结合 FRR 第4/5/6条等条文理解。

Q303. Type 7 的最低资本/流动资本是否有统一固定数字？
A：没有“一刀切”。最低门槛要按你的牌照组合（是否叠加 Type 1/2 等）、以及是否被施加某些**指定持牌条件（例如不得持有客户资产）**等因素综合确定；SFC 也提示最低数额分布在 FRR Schedule 1，需与其他条文一并阅读。

Q304. 申请阶段，监管通常如何看“资金实力与持续经营能力”？
A：除了 FRR 的硬门槛，SFC 更关心你是否具备持续投入系统、监控、人手与合规的能力：包括营运预算、现金流预测、融资来源、主要成本项（IT/云/外包/监控工具/审计）及“压力情景下能否活下去”的安排。此类审视逻辑在《Licensing Handbook》对持牌法团总体要求中亦有体现。

Q305. 如果我们承诺“不持有客户资产”，对 FRR 要求有什么影响？
A：在香港实务中，“不持有客户资产”的指定持牌条件常用于降低部分业务模式的资本压力，但是否适用、如何措辞、以及对你可做业务的限制，需要在申请时与整体业务模型一并论证；FRR 培训材料也解释了“specified licensing condition”的概念与影响。

Q306. SFC 会要求我们提交哪些财务报表/预测模型？
A：常见包括：最近审计报表（若有）、股东资金证明、开办费用与 12–24 个月预算、收入假设说明、成本拆分（尤其是系统/监控/外包与人力）、以及资金缺口的补足方案。其目标是验证“你不是只拿牌、而是能持续合规运营”。

Q307. 经营中出现资本接近门槛（接近 breach）时，第一优先级是什么？
A：第一优先级是风险止损与合规处置：立刻做内部预警、冻结高风险变更/扩张动作、评估是否触发 FRR breach、并准备增资/补充资本或削减风险敞口（例如外包成本重谈、关停非核心功能等）。FRR 为持续性要求，一旦跌破会引发重大监管后果。

Q308. FRR breach 的典型后果有哪些？
A：视情节可能包括：监管质询、要求提交整改计划、加强申报频率、对业务施加限制，严重情况下可能影响牌照持续有效性。与“年费逾期可能导致暂停/撤销”类似，SFC 对基础合规底线通常采取高强度处置。

Q309. Type 7 持牌法团需要定期提交哪些监管申报/回报？
A：除持牌相关的变更通知外，持牌法团一般需要按 SFC 要求提交**财务回报（financial returns）**与相关报表，以证明持续符合 FRR；具体频率与表格取决于你的业务与牌照组合。FRR 与 SFC 监督 FAQ 体系均以“持续申报+持续符合”为核心。

Q310. “财务回报”在内部如何落地成流程？
A：建议设立：财务数据口径表（FRR mapping）、月度试算表、异常阈值预警（接近 required liquid capital 即报警）、以及董事会/管理层月报机制；同时明确 CFO / 财务负责人、RO、合规的签核链，确保数据可追溯、责任可追责。

Q311. 申请阶段与持牌后，是否需要审计师/外部会计师深度参与？
A：强烈建议参与。因为 FRR 的口径计算与回报准确性是“低级错误高代价”的领域；外部专业人士可以协助你建立 FRR mapping 与申报底稿，避免把合规风险留到现场检查才暴雷。

Q312. Type 7 年费、逾期附加费与暂停/撤销风险是怎样的？
A：SFC《Licensing Handbook》明确：年费逾期会产生附加费（surcharge），并可能导致牌照/注册被暂停甚至撤销；因此建议把“年费节点”纳入合规日历并设置双人复核。

Q313. Type 7 年费有没有豁免情形？
A：有。《Licensing Handbook》载明：若 Type 7 属于 Type 1 或 Type 2 的附带活动（incidental），Type 7 的年费可豁免；SFC FAQ 亦提到在某些情形下 Type 7 的申请费/年费/CPT 可被豁免。

Q314. “incidental（附带）”在实务里怎么判断？
A：核心看：Type 7 是否只是为了支持你主要的 Type 1/2 业务（例如单纯订单路由/执行辅助），而非独立收费、独立产品线或独立客户群的“平台业务”。一旦形成独立商业线（独立收费/独立营销/独立规则），监管更可能认为不是 incidental。

Q315. 如果我们同时做 Type 1 + Type 7，资本要求如何叠加？
A：通常按 FRR 的规则取决于你“最高要求的那一类”以及叠加风险（例如是否持有客户资产、是否做保证金融资等）。关键是：不能只看某一个活动的最低数，而要按你的实际业务与限制条件综合测算。

Q316. 监管会不会追问“收入结构与费用模式”对资本稳定性的影响？
A：会。尤其是 ATS 平台往往前期收入不稳定、但系统与监控成本刚性，SFC 通常会追问：收费方式（交易费/接入费/API费/会员费）、回扣与利益冲突安排、以及在低成交时期如何维持合规运营。

Q317. 资本规划里，最容易被忽视但最烧钱的项目有哪些？
A：常见是：监控/告警系统（surveillance tools）、日志与数据存证（长期留存与查询）、渗透测试与安全加固、灾备演练、外包治理成本（审计/评估/替换）、以及事故响应与法律费用预备金。ATS Guidelines 强调系统稳健与可追溯，相关成本不能省略。

Q318. 我们可以用集团资金支持来满足持续资本要求吗？
A：可以作为资本来源之一，但你需证明资金的可用性、稳定性与合法性（例如注资承诺、资金来源证明、集团内部支持协议等），并确保在压力情景下不因集团政策变化导致你跌破 FRR。

Q319. 资本金/流动资本测算需要做到什么颗粒度才算“可递交/可检查”？
A：至少要做到：科目映射（会计科目→FRR 类别）、计算逻辑说明、取数来源与证据、异常调整依据、以及可复算的工作底稿（Excel / system report）。监管检查时要的是“可复核”，不是“口头解释”。

Q320. Type 7 申请材料里，如何把“财务资源合规”写得更有说服力？
A：建议用“三段式”：

门槛：我们适用的 FRR 门槛与测算口径；
过程：月度监控与预警机制（阈值、责任人、升级路径）；
保障：备用融资/注资安排与压力测试结论。这样能把“合规底线”写成“可执行系统”。

N. 系统治理、控制与证据链 Q321–Q340

Q321. ATS Guidelines 对系统治理的核心监管精神是什么？
A：一句话：公平、透明、稳健、可监控、可追溯。你要证明撮合/执行规则公平一致，系统在压力下稳定，监控能及时发现异常，日志能完整重建事件。

Q322. 监管最常追问的“系统控制点”有哪些？
A：常见包括：权限分层（谁能改规则/参数）、变更管理（上线审批与回滚）、时间同步（timestamp 一致性）、容量与压力测试、灾备与恢复目标、以及异常处置与复盘闭环。上述都直接对应 ATS Guidelines 的要求。

Q323. “变更管理（change management）”要做到什么才够？
A：最低标准是：变更申请→风险评估→测试证据→双人审批→上线窗口控制→上线后监控→复盘与记录归档；并且对“规则/撮合逻辑”变更设立更高门槛（例如必须合规签核）。

Q324. 如果撮合参数可被运营人员在后台调节，会有什么风险？
A：最大风险是“选择性对待/暗箱操作”的监管疑虑。你必须用：权限最小化、双人制、全量日志、变更留痕、以及变更前后影响评估，证明没有对特定客户或特定交易进行不公平处理。

Q325. 如何证明撮合规则“公平一致执行”？
A：用四类证据：规则文本（优先级/撮合逻辑）、代码/配置受控（版本与审批）、运行日志可还原（订单队列与成交重建）、以及独立抽样复核（内审/外部审计）。这是 ATS 争议处理的“硬证据”。

Q326. ATS 平台是否必须建立“市场监察（surveillance）”功能？
A：监管预期非常高。你至少要能识别并处置：异常撤单、异常价格偏离、自成交/对敲、异常 API 行为、以及潜在操纵模式；并且留下告警→调查→处置→复盘的闭环记录。

Q327. 告警太多、误报高会被监管否定吗？
A：会被质疑“监控无效”。正确做法是：定义风险优先级、设置合理阈值、做模型/规则复盘（命中率、误报率、处置时效），并把迭代过程记录下来，证明你持续改进而不是“摆设”。

Q328. 对 API 客户（量化/高频）应额外设置哪些控制？
A：通常要加强：API 权限分级、速率限制（rate limit）、订单风控（价格带/数量/撤单率）、异常行为自动熔断、以及更细粒度日志（request id、签名校验、IP/设备指纹等），以降低系统性风险。

Q329. 交易时间戳与时间源管理为什么重要？
A：因为时间戳决定“优先级、公平性与争议还原”。若时间源漂移、不同组件时间不一致，会导致你无法可靠重建订单队列，监管与客户争议时你会在证据链上处于劣势。

Q330. 灾备（DR）要达到什么水平才算合规？
A：你需要明确 RTO/RPO、演练频率、切换流程、数据一致性验证、以及演练报告与整改闭环。ATS 的风险在“实时市场”，灾备不是 IT 选项，而是监管关切点。

Q331. 日志与记录保存通常要覆盖哪些范围？
A：至少覆盖：订单全生命周期（提交/修改/撤销/成交）、撮合引擎决策点、规则/参数变更、权限与登录、告警与处置、事故与恢复，以及对外披露/客户通知记录。可追溯性是 ATS 合规的核心。

Q332. “日志不可篡改”要怎么做才够监管口径？
A：关键是：权限隔离、访问留痕、导出审批、哈希校验/归档策略、以及可审计的保管链（chain of custody）。监管不一定要求你用某种特定技术，但会要求你证明“记录可信”。

Q333. 外包撮合/云部署时，监管会不会认为“你失去控制”？
A：只要你无法证明控制与监督，风险就很高。正确做法是：合同审计权、SLA 与事故升级、数据归属与迁移、退出计划（exit plan）、以及你内部仍具备关键监控与应急能力。ATS Guidelines 的要求不会因外包而降低。

Q334. 供应商治理（vendor governance）最关键的“三条线”是什么？
A：1) 准入：尽调与安全评估；2) 过程：SLA、工单、事故与整改；3) 退出：替换、迁移、数据可携带。把它做成制度+报告+证据包，才能应对检查。

Q335. 如果我们同时做做市/流动性提供，如何处理利益冲突？
A：必须把利益冲突写进：治理结构、账户隔离、交易监控规则、披露文件与审计轨迹；尤其要监控自成交/对敲/异常价差等行为，避免被视为操纵或不公平对待。

Q336. “错误交易（error trade）/系统故障导致错配”应如何制度化处理？
A：建议建立：错误交易识别标准、暂停/回滚触发条件、客户沟通模板、补偿原则、监管沟通阈值、以及复盘与整改清单。监管关注点是：你能否及时止损、是否公平一致、是否保全证据。

Q337. 事故响应（incident response）的最小可交付包应该包括什么？
A：至少包括：分级标准（P1/P2/P3）、应急联系人表、处置流程图、证据保全清单、对内/对外沟通模板、复盘报告模板、以及整改追踪表。把“临场发挥”变成“可复制流程”。

Q338. 监管面谈/检查时，最建议准备的系统演示是什么？
A：准备一条“端到端证据链演示”：下单→撮合→成交回报→告警→处置→日志导出→复算还原。监管看重的是“你能否用数据证明你说的控制真的存在”。

Q339. ATS 的“规则披露”要覆盖到什么层级？
A：至少覆盖：撮合优先级、订单类型与限制、停机/熔断/限速机制、错误交易处理、费用结构、以及利益冲突（如做市/关联方）。披露不清会在客户争议中放大。

Q340. 我们如何把“系统治理”做成 SFC 看得懂的申请附件目录？
A：建议按模块成册：系统架构说明书、控制点矩阵（control matrix）、变更管理 SOP、权限与访问控制、监控规则库、日志字段字典与导出流程、DR/BCP 计划与演练报告、外包治理包。ATS Guidelines 就是你的目录模板。

O. 线上渠道、WINGS 问卷与通知义务 Q341–Q360

Q341. 我们提供互联网下单/电子交易服务，但不一定构成 Type 7——还需要做什么？
A：SFC 明确要求：若你拟通过互联网提供相关 dealing activities（例如订单传递/电子交易服务），你需要提交 Questionnaire 2（Providing Electronic Trading Services），并书面通知上线日期与网站地址。该要求在《Licensing Handbook》与 SFC“Do you need a licence…”页面均有说明。

Q342. Questionnaire 2 在哪里提交？包含什么内容？
A：可通过 SFC 的 WINGS 系统进入 Questionnaire 2 页面提交；其内容覆盖电子交易/自动化交易相关的强制问题（例如负责人员、系统功能、控制安排等）。

Q343. Questionnaire 2 与 Type 7（ATS）申请是什么关系？
A：两者不是简单等号：Questionnaire 2 主要用于电子交易服务的监管掌握；Type 7 则是当你实质提供 ATS（撮合/经常作出或接受要约/经常介绍对手方促成交易）时的牌照路径。实务上若你接近 ATS 定义，监管会更深追问你的撮合/监控/记录与公平性。

Q344. “Guidelines on Online Distribution and Advisory Platforms（ODAP）”与 Type 7 有何关系？
A：若你通过在线平台提供执行/分销/建议等受规管活动，ODAP 指引会适用，并强调线上渠道同样需要满足适当性、披露与管治要求；它适用于持牌/注册人通过线上平台开展相关活动。对 ATS/线上交易平台而言，这些要求常与 ATS 的公平、透明与客户保护形成叠加。

Q345. ODAP 指引的核心检查点有哪些？
A：重点通常落在：线上披露是否清晰、客户适当性评估如何落地、复杂产品的处理、信息展示是否误导、以及线上流程是否有足够的控制与审计追溯。SFC 亦发布过行业简报帮助理解常见缺陷。

Q346. 我们通过社交媒体（公众号/社群/短视频）引流到交易平台，会被纳入线上监管视野吗？
A：会。ODAP 体系强调：监管会把面向香港投资者的线上活动“整体看”，包括社交媒体等渠道的信息展示与营销行为（是否误导、是否充分披露风险）。

Q347. 上线新网站/新 App/新域名，最稳妥的合规动作是什么？
A：在上线前完成 Questionnaire 2（如适用）并准备书面通知材料，上线后保留通知回执与版本快照；同时确保风险披露、费用披露、规则披露与投诉渠道在新渠道完整一致。

Q348. 如果我们的系统功能迭代很快，如何避免问卷与实际不一致？
A：建立“问卷映射表”：把 Questionnaire 2 / 申请材料中的关键声明（功能、控制、监控、日志、外包）映射到内部制度与系统配置；每次重大变更触发合规复核与材料更新。

Q349. 线上平台开户与 KYC 流程，监管通常会抓哪些问题？
A：常见是：身份核验强度不足、风险评级与持续尽调缺失、客户声明与披露未留存证据、以及线上流程存在“跳过关键步骤”的漏洞。对 ATS 平台而言，KYC/客户分类与权限分级还会影响市场风险与公平性。

Q350. 若我们提供“复杂产品”交易（例如结构性产品、衍生品等），线上要求会更严吗？
A：通常更严。ODAP 监管思路强调线上也要满足适当性与披露要求，复杂产品更需要清晰的风险披露、适当性门槛、以及“客户理解度”与冷静期/确认机制等设计。

Q351. 如果我们既提供订单执行，又提供“策略/信号/建议”，要注意什么？
A：要做“牌照边界拆解”：执行（可能涉及 Type 1/2）与建议（Type 4/5/9 等）在人员、披露、利益冲突与适当性上要求不同；线上形态下 ODAP 的要求会叠加。建议先把业务流程画清楚再定牌照组合。

Q352. SFC 为什么强调“线上与线下应同等合规”？
A：因为线上流程同样可能造成误导销售、适当性不足或风险披露缺失，且传播更快、影响更广。ODAP 的政策目标就是把线下的关键投资者保护原则迁移到线上环境。

Q353. Type 7 / ATS 平台应如何设置“客户权限与产品权限”？
A：建议至少分层：零售/专业投资者、API/非 API、复杂产品/非复杂产品、以及更细的风险等级；每一层配套不同的限额、告警阈值、披露强度与确认步骤，并保留授权证据。

Q354. 监管检查线上平台时，常见“硬伤”是什么？
A：最常见硬伤包括：披露分散且不显眼、关键条款可被跳过、适当性问卷与实际交易权限不联动、以及缺乏可导出的证据链（客户何时看到什么、点了什么、同意了什么）。ODAP 行业简报与相关材料反复强调“可证明”。

Q355. 我们应如何把“线上合规”做成可打印的自检清单？
A：用 ODAP 四大块做骨架：信息披露、适当性、产品分类（尤其复杂产品）、系统与管治；每块再加上“证据字段”（截图、版本号、日志、回执、抽样记录），让清单不只是“勾选”，而是“能出示证明”。

Q356. 持牌后发生重大事故（例如系统停摆、错误撮合），是否需要向监管沟通？
A：ATS 监管精神要求你有事故管理与沟通机制。是否需要对外或对监管沟通取决于事故性质、影响范围与客户损害可能性；最稳妥做法是预设“重大事件分级与升级阈值”，并保留所有决策与沟通记录。

Q357. Type 7 平台的年度培训（CPT）与线上团队培训要怎么设计？
A：除满足持牌人员 CPT 规划外，线上平台团队应做“岗位化培训”：客服（披露与投诉）、运营（规则与变更门禁）、IT（日志/权限/事故）、合规风控（监控规则与调查）。SFC《Licensing Handbook》对 CPT 有明确要求。

Q358. 最建议建立哪些“常态化报表”，让 RO 真正可监督？
A：建议至少：系统可用性与事故报表、变更上线报表、监控告警统计与处置时效、客户投诉与争议报表、以及 FRR 资本预警报表。这样 RO 的监督就不是“名义值勤”，而是“数据驱动”。

Q359. 若我们只是 order routing，但被客户宣传成“平台撮合”，会有什么风险？
A：风险在于：事实与披露不一致可能引发监管质疑，甚至被重新评估是否落入 ATS 定义（经常介绍/促成交易等）。建议营销口径严格对齐业务实质，并保留内部审核记录。

Q360. Q301–Q360 这一段的“交付目标”是什么？
A：把 Type 7 的两条生命线落地：

FRR（财务资源）持续合规：可计算、可预警、可申报；
系统与线上渠道可审计：规则可证、控制可证、记录可证（并能在 WINGS/问卷/检查中自洽）。

P. SFC 面谈 / 审查 / 现场检查：高频问题与“证据链” Q361–Q380

Q361. Type 7 申请阶段，SFC 最常用什么方式“把你问透”？
A：通常是“书面提问（RFI）+ 系统/流程追问 + 证据链补件”组合：先让你把业务边界、撮合规则、监控与记录机制写清楚；再针对关键风险点逐条追问；最后看你能否拿出可复核材料。ATS Guidelines 的监管精神就是：规则公平、系统稳健、监控有效、记录可追溯。

Q362. 面谈时，SFC 最想确认的“第一性问题”是什么？
A：一句话：你到底提供的是不是 ATS（触发 Type 7）？如果是，你能不能管住它？
因此面谈通常围绕：是否落入 Schedule 5 ATS 定义、你走 Part III 还是 Part V（Type 7）、撮合/引荐机制是否公平透明、以及监控与日志是否能重建交易全链路。

Q363. SFC 会用哪些“场景化问题”测试你是否真正理解 ATS 风险？
A：典型场景包括：

撮合引擎 bug 导致错配/不公平成交怎么办？
大客户 API 爆量导致系统延迟、优先级扭曲怎么办？
你如何发现自成交/对敲/异常撤单率？
规则/参数变更如何审批、如何回滚、如何告知客户？
这些都直接对应 ATS Guidelines 对系统控制与市场监察的关注点。

Q364. 面谈前最建议准备的 3 份“必杀材料”是什么？
A：

业务边界与牌照路径说明书：为什么属于 Type 7（或为什么不属于），并对照 Schedule 5 定义逐条论证；
系统控制点矩阵（Control Matrix）：撮合规则、公平性控制、变更管理、权限、日志、DR、监控规则一一对应；
端到端演示脚本（Walkthrough）：下单→撮合→回报→告警→处置→日志导出→复算还原。

Q365. SFC 最爱追问“撮合公平性”的哪些细节？
A：常见四连问：优先级规则（价优/时优/撮合逻辑）、时间戳来源（同步与漂移控制）、同速同权（是否存在暗通道/差别对待）、异常成交处理（error trade 机制）。你要能“讲清楚 + 证明”。

Q366. 监管怎样判断你有没有“暗箱操作空间”？
A：看你是否存在：

运营人员可随意改撮合参数且无双人审批；
权限不分离（同一人可改规则、上生产、删日志）；
日志不完整或可篡改；
客户差别通道缺乏披露与审计。
ATS 合规的核心是“可追责、可复核”。

Q367. Type 7 的“市场监察（surveillance）”要做到什么程度才不虚？
A：至少做到：

有“规则库”（监控指标、阈值、触发条件）；
有“处置闭环”（告警→调查→结论→处置→复盘）；
有“指标复盘”（误报/漏报、处置时效、规则迭代记录）。
这与 ATS Guidelines 的监管目标一致：及时发现不当行为并留下证据。

Q368. SFC 会不会要求看你们的“真实日志/真实报表”？
A：会，尤其在系统、监控与记录的核验上。你最好能现场导出：订单生命周期日志、撮合决策点、告警记录、变更记录与权限记录，并能解释字段含义与取证流程（chain of custody）。

Q369. 现场检查（或被抽查）通常会怎么抽“记录保存与可追溯”？
A：常见做法是：随机抽某一交易日、某一客户或某一异常事件，要求你用日志复原：

客户下单与修改撤单全过程；
撮合引擎如何决定成交；
是否触发告警、如何处置；
是否对客户披露/通知。
你能否还原出来，就是合规成败。

Q370. “外包/云部署”在检查里通常怎么被问？
A：监管会问：你如何确保仍由你负责、仍可审计、仍可迁移退出？你需要证明：审计权、SLA、事故升级、数据归属、访问控制、以及 exit plan。外包不降低 ATS 的控制要求。

Q371. SFC 会如何检视你们的“变更管理（Change Management）”？
A：会看你是否做到了：版本控制、上线审批、测试证据、回滚预案、上线窗口控制、上线后监控与复盘记录。特别是撮合规则/参数变更，通常会被要求更高门槛。

Q372. SFC 面谈最容易“翻车”的回答是什么？
A：三类最危险：

“我们不会出事”（没有机制与证据）；
“外包商会负责”（把问责甩出去）；
“这块我们还没定”（关键控制点空白）。
ATS 是强监管领域，监管要的是“可执行与可验证”。

Q373. 如何用一句话回答“你们的平台如何保护市场公平”？
A：用“控制链”回答：规则透明一致 + 权限分离 + 变更双人制 + 监控告警闭环 + 日志可复算还原，并能拿出对应的文件与系统证据。

Q374. 面谈中，RO（负责人员）通常会被重点问哪些问题？
A：RO 通常会被问：

你具体如何监督 Type 7 业务（报表、例会、门禁）；
遇到异常交易/事故你怎么决策与止损；
你如何确保系统变更不破坏公平；
你如何评估外包与第三方风险。
《Licensing Handbook》对 RO 监督与可用性有明确监管预期。

Q375. RO 值勤与可用性（availability）如何安排更稳？
A：建议：至少一名 RO 随时可联系、重大事故有升级链、并把“值勤日志 + 关键报表签阅”常态化。监管不喜欢“挂名 RO”。

Q376. 如何把“电子交易/在线渠道”合规与 Type 7 合规衔接？
A：做一套统一的“线上证据链”：

Questionnaire 2（如适用）与材料声明与实际系统一致；
网站/App 的披露、风险提示、规则手册与版本可追溯；
客户点击确认与授权留痕可导出。
SFC 对线上平台（ODAP）强调“线上也要可证明”。

Q377. ODAP 指引是否适用于 Type 7/ATS？
A：适用。ODAP 指引明确：适用于 Part III 授权的 ATS 提供者或 Part V 下 Type 7 持牌/注册人，并要求线上平台在订单执行、分销与咨询等活动中落实核心原则。

Q378. 现场检查时，最建议准备的“一键资料包目录”是什么？
A：建议至少 10 个文件夹：规则手册/版本库、系统架构与控制矩阵、权限与变更记录、监控规则库与处置记录、事故与复盘、DR/演练、外包治理、客户披露与确认、投诉与争议、日志字段字典与导出流程。

Q379. 被投诉触发检查时，你的第一动作是什么？
A：先做三件事：证据保全（日志/截图/录音/工单）、风险止损（暂停相关功能/账户/策略）、统一口径（对内与对外沟通）。ATS 争议的胜负关键在“证据链完整”。

Q380. 面谈/检查的“及格线”是什么？
A：不是“讲得好听”，而是：你能把监管关心的风险点，用制度与系统证据闭环回答——并能复原交易事实、说明决策过程与责任归属。

Q. 处罚风险、退出（Wind-down）与持续合规“高危雷区” Q381–Q400

Q381. Type 7/ATS 领域最常见的高危雷区有哪些？
A：通常包括：撮合不公平或不透明、监控缺失导致操纵/异常交易未被发现、日志不完整无法还原、权限与变更管理失控、外包失控、以及对客户披露不足。ATS Guidelines 的要求基本就是为了压这些风险。

Q382. 监管对“误导宣传/不当披露”在 ATS/线上平台上会更敏感吗？
A：会。ODAP 指引与相关 FAQ 明确强调线上平台的信息展示、风险披露、以及与客户交易相关的说明必须清晰且不具误导性；线上渠道传播快、影响面大，监管容忍度更低。

Q383. 如果我们想“先小规模试运营”，监管会接受吗？
A：可以采用“里程碑式上线”策略（灰度/限量客户/限品类/限权限），但前提是：控制体系与证据链在上线前已到位，而不是“先跑起来再补合规”。ATS 的系统性风险决定了监管更偏好“先合规后扩张”。

Q384. 持牌后最容易犯的“低级致命错”是什么？
A：两类：

年费/持续义务类错误（逾期、漏报、未按要求更新关键信息）；
系统变更类错误（未经审批上线、记录缺失、导致不公平成交却无法复原）。

Q385. Type 7 的费用/年费豁免规则，最容易被误用在哪里？
A：最容易误用在“把独立平台业务说成 incidental”。费用表与《Licensing Handbook》都明确：Type 7 年费仅在其属 Type 1/2 的附带活动时可豁免。一旦你对外独立营销、独立收费、独立规则，通常就很难再称为 incidental。

Q386. 若我们的业务模式发生变化（例如从 order routing 变成 RFQ/撮合），最关键的合规动作是什么？
A：立刻做“牌照边界重评估”：对照 Schedule 5 ATS 定义与《Licensing Handbook》关于 Type 7/Part III vs Part V 的框架，必要时尽早与监管沟通并更新内部控制与披露文件。

Q387. “客户投诉/争议”在 ATS 平台上为何更危险？
A：因为争议往往指向：成交公平性、系统延迟、规则透明度与记录可信度。你如果无法输出可复算日志与处置记录，就很难自证清白，风险会快速放大为监管问题。

Q388. 发生重大事故（系统故障/错配）时，什么样的处置更符合监管预期？
A：四步法：止损（暂停/限流/隔离）→ 保全证据（日志/配置快照）→ 评估影响与公平性 → 沟通与复盘整改。监管关心的是：你有没有机制控制损害、有没有透明一致的处理原则。

Q389. 是否必须准备“退出计划（Wind-down plan）”？
A：强烈建议必须。虽然不同业务会有差异，但 ATS 平台通常需要证明：若停止服务，如何保护客户权益、如何保存记录、如何处置未完成交易、如何通知客户与相关方、如何迁移/封存数据并维持查询。ATS 的系统性与数据性决定退出计划是重要治理组件。

Q390. Wind-down 计划最少要包含哪些章节？
A：建议至少包含：触发条件、决策与授权、客户沟通、交易与订单处置、系统停机与数据封存、日志与记录保管、外包商退出/迁移、人员安排、投诉与争议处理、以及复盘与最终结案报告。

Q391. 退出时“记录保存”为什么是核心？
A：因为监管与客户争议可能在你退出后仍发生。你必须确保记录在授权访问、完整性与可检索性方面仍可满足监管与争议解决需要；这与 ATS Guidelines 对可追溯性的精神一致。

Q392. 你们建议做一份“处罚风险地图”，应该怎么画？
A：用三轴：

风险类型（不公平撮合/操纵/记录缺失/外包失控/披露不当）；
触发事件（投诉、事故、抽查、媒体舆情）；
证据链缺口（缺日志、缺审批、缺复盘、缺披露确认）。
每个格子配“预防控制 + 检测控制 + 应急动作”。

Q393. Type 7 平台是否需要维护“合规日历”？
A：是，强烈建议。至少覆盖：年费与续期、RO/人员变动通知、CPT、规则年度复核、DR 演练、权限复核、外包评估、监控规则复盘与内审。逾期/漏做会带来不必要的监管风险。

Q394. 哪些指标最适合做成“董事会级 KPI”，用于证明管理层问责？
A：建议：系统可用性与重大事故次数、告警处置时效、关键规则变更次数与合规签核率、投诉量与解决时效、以及外包 SLA 达成率。这样 RO/管理层监督才可被量化证明。

Q395. SFC 是否有公开名录/登记册可查询 ATS 或相关授权/牌照信息？
A：SFC 网站提供：“Do you need a licence or registration?”信息、并列出Part III 下 ATS 授权的登记册入口；持牌/注册信息也可通过 SFC 相关公开渠道查询。

Q396. 我们如何向客户解释“Part III 授权 vs Part V Type 7 持牌”的差异？
A：可用一句话：提供 ATS 的主体要么走 Part III 授权，要么走 Part V（Type 7）发牌/注册；《Licensing Handbook》明确这是一种“二选一”的监管框架，并说明若公司已是其他受规管活动中介人，一般会走 Part V 的 Type 7。

Q397. “我们只是 order routing 不算 Type 7”——怎样对外说才不踩雷？
A：要避免把服务描述成“撮合/平台成交”。更稳妥的说法是：我们提供的是订单传递/路由与相关电子交易控制安排（并按要求完成电子交易问卷/通知等），不提供 ATS 定义下的撮合或对手方识别促成交易设施。

Q398. 做 Type 7 的“最小合规配置”是什么？
A：最小不是“最省钱”，而是“能持续合规”的底盘：两名 RO 的有效监督、系统控制与变更门禁、监控告警闭环、日志与存证、事故响应与 DR、外包治理（如适用）、以及线上披露与客户保护机制。

Q399. 客户最常问的一句“刁钻问题”是什么？你建议怎么答？
A：常见刁钻问法是：“你们是不是暗箱撮合？我怎么证明我没被区别对待？”
建议答法：我们有公开的撮合与规则披露、权限分离与变更双人制、监控与异常处置闭环，并能在争议时按程序导出日志重建订单队列与成交过程（在合规与保密边界内提供证据）。

Q400. 用一句话总结 Type 7（ATS）合规的终极目标是什么？
A：把“市场公平与客户保护”变成可审计的制度与系统证据链——你说得清、做得到、查得出、还原得了，并能长期稳定运行。

三、了解仁港永胜

1 仁港永胜建议（结论与行动清单）

先定边界：用 Schedule 5 的 ATS 定义把业务拆解为“撮合/引荐/路由/执行”，明确是否触发 Type 7。
先做证据链再谈扩张：控制矩阵、监控闭环、日志可复算、变更门禁与 DR 演练先落地。
面谈材料按监管语言写：引用 ATS Guidelines 与 Licensing Handbook 的结构组织材料（不是营销 PPT）。
线上渠道别掉以轻心：ODAP 指引适用线上平台活动，披露/适当性/证据留存要可证明。
持续合规靠“合规日历+仪表盘”：年费、培训、复核、演练、外包评估与关键报表要常态化。

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

交付级材料体系：从业务边界论证、系统控制矩阵、监控规则库、日志字典、到面谈问答与现场检查“一键包”。
工程化合规方法：把监管要求翻译成“门禁、日志、报表、复盘、审计追溯”的可执行流程。
里程碑管理：按申请—补件—面谈—上线—持续合规分阶段推进，降低反复返工成本。

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

仁港永胜（香港）有限公司长期为金融机构与金融科技企业提供：香港 SFC 持牌规划、申请材料编制、系统合规与持续合规支持、现场检查应对与整改闭环等服务。

4 联系方式

—— 合规咨询与全球金融服务专家 ——

公司中文名称： 仁港永胜（香港）有限公司
公司英文名称： Rengangyongsheng (Hong Kong) Limited

专业讲解/项目负责人：唐生（Tang Shangyong）｜合规与监管许可负责人
香港/WhatsApp：+852 9298 4213
深圳/微信：+86 159 2000 2080
电邮：Drew@cnjrp.com
网站：www.jrp-hk.com
总部地址：
香港特别行政区西九龙柯士甸道西 1 号香港环球贸易广场（ICC）86 楼

办公地址：
- 香港湾仔轩尼诗道 253–261 号依时商业大厦 18 楼
- 深圳福田卓越世纪中心 1 号楼 11 楼
- 来访提示：请至少提前 24 小时预约。
服务范围：香港SFC持牌申请与持续合规、制度文件体系搭建、AML/CFT、线上平台治理、监管问询/现场检查应对等。

5 免责声明（Disclaimer）

本文仅作一般信息与合规实践参考，不构成法律意见、税务意见或对任何监管结果的保证。个案是否触发 Type 7（ATS）及牌照路径选择，须以业务实质、系统功能与最新监管口径为准，并建议在提交申请或上线前获取专业法律与合规意见。仁港永胜保留对本文内容更新与修订的权利。

——《香港SFC 7号牌｜自动化交易服务常见问题（FAQ）》——由仁港永胜唐生提供专业讲解。

如欲查询更多香港 SFC 7号牌｜自动化交易服务（Type 7: Providing Automated Trading Services, “ATS”）常见问题（FAQ）有关的资料，请与我们仁港永胜的专业顾问联络，我们将为您提供免费咨询服务。[点击联系公司注册专业顾问]

24小时专业顾问：15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）

上一页： 香港 SFC 8号牌：证券担保融资牌照常见问题，SFC Type 8 FAQ
下一页： 香港 SFC 6号牌｜机构融资咨询（Type 6）FAQ，SFC Type 6 Regulated Activity – Advising on Corpora