首页 > 常见问题

捷克共和国（MiCA）加密资产服务提供商（CASP）牌照常见问题（FAQ 大全）

时间：2025-11-26 09:26:35 阅读：142

《捷克加密资产服务提供商（CASP）牌照常见问题（FAQ 大全）》

Crypto-Asset Service Provider (CASP) under MiCA – Czech Republic CNB Version
本文由仁港永胜（香港）有限公司拟定，并由唐生提供专业讲解

捷克共和国（MiCA）加密资产服务提供商（CASP）牌照常见问题（FAQ 大全）

Czech Republic MiCA Crypto-Asset Service Provider – FAQ Master Pack

监管机构（Competent Authority）：捷克国家银行 CNB（Czech National Bank）

适用法规（Regulatory Framework）：

Regulation (EU) 2023/1114 MiCA
Czech AML Act No. 253/2008 Coll.
Act on Capital Market Undertakings
CNB Supervisory Statements & Licensing Guidelines

本文件由 仁港永胜（香港）有限公司 全面编制，内容覆盖 MiCA + 捷克 CNB 落地要求 + AML 法规 + 风险、ICT、外包、资本金、税务等全方位内容，提供 至少 300 条深度问答，适用于：

准备在捷克设立 MiCA CASP 主体
计划通过捷克作为 EU/EEA 护照（Passporting）母国
需要完成监管补件（RFI）、面谈准备、风险与 ICT 文档准备的团队
律所、家办、加密企业、托管型项目、交易平台

下载区（以下文件由仁港永胜唐生提供）

✅ 《捷克 CASP 牌照申请注册指南 – 详细版》
✅ 《捷克 CASP 常见问题（FAQ 大全）》
✅ 《捷克 AML 手册目录 + 风险登记册（Risk Register）》
✅ 《CNB 面谈问答模拟（监管补件版本）》

注：本文中的模板或电子档可以向仁港永胜唐生有偿索取。 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）]

目录结构

✔ 第一章：MiCA + 捷克监管基础（Q1～Q30）
✔ 第二章：业务模式与业务范畴（Q31～Q70）
✔ 第三章：申请流程、补件（RFI）与面谈（Q71～Q110）
✔ 第四章：治理结构、人员要求、实体要求（Q111～Q150）
✔ 第五章｜资本金、财务预测、审计要求（Q151～Q180）
✔ 第六章｜AML / CFT / KYC & 捷克 AML 法专章（Q181～Q210）
✔ 第七章｜ICT、网络安全、DORA & 托管技术（Q211～Q240）
✔ 第八章｜捷克 Crypto Tax + 会计与税务处理专章（Q241～Q270）
✔ 第九章｜监管沟通、现场检查与持续义务（Q271～Q285）
✔ 第十章｜项目实战建议、常见错误与仁港永胜服务模式（Q286～Q300）
✔ 第十一章：虚拟资产托管技术（Custody Tech）专章（Q301～Q330）

第一章：MiCA + 捷克监管基础（Q1～Q30）

以下为仁港永胜唐生拟定的捷克共和国（MiCA）加密资产服务提供商（CASP）牌照常见问题（FAQ 大全），逐条问答：

Q1：捷克的 MiCA CASP 牌照由谁负责监管？

捷克的 MiCA CASP 由 捷克国家银行（CNB） 作为主管机关（Competent Authority）审查与发牌。

CNB 职责包括：

MiCA 授权（Authorization）
持续监管（Ongoing Supervision）
检查（On-site / Off-site）
执法与处罚（Enforcement）

捷克金融分析单位 FAU（Financial Analytical Office） 负责 AML/CFT 监督。

Q2：在捷克申请 CASP 牌照是否仍需要《加密企业登记（Trade Licensing）》？

不需要。

MiCA 实施后：

原“加密交易服务提供商 VASP（在商业登记处注册）”制度将被 MiCA 授权制度取代。
已登记 VASP 需要在过渡期内完成 升级申请，否则将失去合法经营资格。

Q3：捷克 MiCA CASP 牌照可以经营哪些加密业务？

MiCA 规定的 10 项业务全部适用，包括：

托管（Custody）
交易平台运营
执行订单
交换服务（Crypto-to-Fiat / Crypto-to-Crypto）
接收与传送订单
投资建议
自营交易
放贷（Crypto Lending）
组合管理（Portfolio Management）
ICO / Offer to the Public（在某些情况下）

捷克 CNB 采用与 MiCA 一致的分类，不扩不缩。

Q4：捷克是否有额外于 MiCA 之外的国家级本地要求？

有两类本地要求：

① AML（最严格）：

捷克 AML Act No. 253/2008
强制链上分析
强制验证 UBO
高风险国家强化审查

② 实体要求（Substance）：

本地董事（至少 1 名）
本地 AML Officer
本地可执行的办公地点（实际地址）
本地簿记与审计制度

捷克不是“纯监管套利国”，其监管风格比马耳他/爱沙尼亚更严谨。

Q5：捷克 CASP 和奥地利/德国 CASP 在监管风格上有何差异？

项目	捷克（CNB）	奥地利（FMA）	德国（BaFin）
严格程度	中等偏高	中等偏高	最高
AML 要求	很严格	严格	极严格
ICT / DORA	中等	严格	非常严格
审查速度	中等	一般	最慢
对外包态度	中立	谨慎	极度保守

捷克较适合作为：
“申请难度 < 德国/奥地利，但合规水平远高于马耳他/爱沙尼亚”的折中管辖地。

Q6：MiCA 是否要求捷克 CASP 设立当地实体？是否可用国外公司？

必须设立：

捷克当地公司（s.r.o 或 a.s）
并作为 MiCA 授权实体
不能以外国分公司或海外公司申请

MiCA 是 Member State-based 法律，必须在该国设立实体。

Q7：捷克 CASP 是否需要最低注册资本？

根据 MiCA：

托管（Custody）：≥ 15 万欧元
交易平台：≥ 15 万欧元
执行订单、接收与传送：≥ 5 万欧元
建议类业务：≥ 5 万欧元
自营交易：≥ 75 万欧元

CNB 不额外加码，但会根据风险模型建议增加资本。

Q8：捷克是否对加密业务有额外“许可证”或“牌照前置登记”？

没有额外牌照，但涉及：

PSD2（若涉及支付）
EMD2（若涉及电子货币）
Licensing Act（若变相提供投资服务）

如果您的业务触及这些范围，可能需“双牌照结构”。

Q9：MiCA 是否废除捷克原有的“加密货币法律类别”？

是。
捷克过去将加密资产视作：

“商品”
“无形资产”

MiCA 引入 Crypto-Asset + ART + EMT 三大分类后，CNB 将全面采用 MiCA 分类。

Q10：捷克 CASP 是否必须提供捷克语服务或 UI？

MiCA 没有要求，但 CNB 可能要求：

客诉流程
合规文件
法律披露

至少提供捷克语版本。

Q11：捷克 CNB 是否允许 CASP 采用境外第三方托管钱包服务？（如 Fireblocks、Copper 等）

允许，但必须符合：

MiCA 托管外包要求
DORA ICT 风险监管框架
外包不影响管理层“最终责任”原则
提供完整技术文档与渗透测试报告
外包协议需可被 CNB 审查
数据需能在捷克监管要求下被本地访问

⚠️ 注意：
CNB 对“关键外包（Critical Outsourcing）”高度关注，尤其涉及私钥托管与 MPC 服务。

Q12：捷克是否要求 CASP 必须使用本地银行开立客户资金账户？

MiCA 本身没有要求“必须本地银行”。
但在捷克实务上：

CNB 更倾向 CASP 在 欧盟银行/EU EMI 开立客户资金账户
若客户基数大，经常要求在 捷克本地银行 开基本账户

捷克银行对加密行业较谨慎，因此通常需要：

强 AML 文件
业务说明书
客户结构说明
投资人背景资料

仁港永胜可以协助安排 可开户银行名单 + 成功开户路径。

Q13：捷克 CASP 是否需要“法律意见书（Legal Opinion）”？

MiCA 本身不强制要求，但 CNB 实务审核时常会要求：

业务模型法律意见
Token 分类意见
风险评估法律意见

特别是提供 RWA、DeFi、Crypto Lending 服务时，通常需要第三方律师出具法律意见。

Q14：捷克 CNB 是否允许提供 DeFi / DEX 服务？

MiCA 对 去中心化服务（Fully Decentralized Services） 不适用监管。
但如果出现以下情况：

有前端
有“运营者”
有风险披露者
有费用收入
有客服团队
有托管桥或路由器
有市场做市关键控制人

CNB 将认定您是“受监管营运者”，必须申请 CASP 牌照。

纯链上无控盘的 DeFi 才能豁免。

Q15：捷克 CASP 可以向全球客户提供服务吗？

可以，MiCA 无地域限制，但需遵守：

当地国家的监管
禁止向被制裁国家提供服务
加强对高风险国家客户（EDD）
必须使用 MiCA 护照进入 EU/EEA 国家
非欧盟国家客户须符合 AML 客户尽调要求

总结：
全球展业可以，但必须处理跨境合规义务。

Q16：捷克 CASP 对于稳定币（Stablecoin）要遵守哪些规则？

视稳定币分类：

1. EMT（电子货币代币）

→ 要求由具有 EMI 牌照 的机构发行（不能由 CASP 发行）

2. ART（资产参考代币）

→ 需要额外申请 ART 发行人授权（非常复杂）

3. CASP 可提供服务：

EMT/ART 的交换
托管
执行订单
平台交易

但不得发行稳定币。

Q17：捷克 CASP 是否可以提供“Crypto Lending（加密借贷）”？

可以，前提：

必须向 CNB 披露借贷模型
必须纳入风险管理
必须提供透明息率披露
客户风险说明必须显著（高风险产品）
资金池不能混同
不能向零售客户“承诺固定收益”

实际上 CNB 对 Crypto Lending 非常谨慎，属于“高监管风险业务”。

Q18：捷克 CASP 是否可以提供“Staking 服务”？

可以，但区分两类：

1）技术性 Staking（Non-custodial）

用户自行授权
平台不接触私钥
监管风险较低

2）托管型 Staking（Custodial/Operator Staking）

这是“投资服务”
必须向 CNB 披露完整逻辑
必须在 ICS、AML、风险管理中体现

CNB 更倾向：

不保证收益
不包装为“理财产品”
不对冲“slashing 风险”

Q19：捷克 CASP 是否可以发行自己的平台 Token？

可以，但符合 MiCA：

实用型 Token（Utility Token）无需申请白皮书批准，只需通知
若涉及投资性质 → 可能需要 MiFID 服务牌照
若与稳定币挂钩 → 属 ART/EMT，监管极严

CNB 会重点审查：

资金用途
担保结构
市场操控风险
是否触发“证券型代币规则”

建议通过我们准备 Token Legal Opinion。

Q20：捷克 CASP 是否允许提供“代持/做市”业务？

做市 = 自营交易（Own Account Trading）
→ 属 MiCA 规定服务，需要 75 万欧元资本金

代持 = 托管服务
→ 属 MiCA 托管，可申请

但代持+做市同一主体同时提供 → 需确保：

客户资产隔离
内部防火墙（Chinese Wall）
避免利益冲突
撮合与自营功能分离

CNB 对利益冲突非常敏感。

Q21：捷克 CASP 在 MiCA 下是否可以“自行发行 ICO”？

可以，但必须：

编写白皮书（MiCA Whitepaper）
通知 CNB（对于非 ART/EMT）
完整披露收益模型与风险
不得向零售客户误导宣传
必须遵守 AML/KYC

如果 ICO 带有“投资属性”，则可能触发 Prospectus Regulation（招股说明书）。

Q22：MiCA 在捷克的过渡期（Transition Period）如何规定？

一般 MiCA 过渡期：

2024.12.30 → EMT/ART
2025.06.30 → 全面 CASP

捷克预计：

既有 VASP（加密经营登记）需在 2025 年前 完成 MiCA 升级
否则无法继续经营

仁港永胜可协助 先登记 VASP → 再升级 MiCA 牌照。

Q23：捷克 CNB 是否对“集团结构（Group Structure）”要求透明度？

非常严格。
CNB 要求：

UBO 穿透（全链条透明）
非欧盟控股 → 高风险
必须披露集团其他牌照、其他国家业务
若集团中有“加密或高风险业务”，可能提高审查要求

集团结构越复杂，补件越多。

Q24：捷克 CASP 是否可以“完全外包（Fully Outsourced）业务模式”？

不能。

CNB 明确：

核心功能必须在捷克实体内部
董事须有实际控制权
AML Officer、Risk Officer 不可外包
ICT 关键职能不可完全外包
客户投诉处理不可外包

MiCA 是“Substance-based（实质经营）” 牌照，不能纯外包或空壳运作。

Q25：捷克是否允许 CASP 使用国外技术团队（例如中国/越南技术团队）？

可以，但要求：

不得接触私钥
不得接触客户数据
必须在 ICS + DORA 架构中描述
必须具备“可监管性”（Auditability）

关键技术团队（如 CTO、Security Lead）建议在 EU 内。

Q26：捷克 MiCA CASP 申请是否可以“加急审查”？

不能。
CNB 不提供加急渠道，但可以：

预先技术沟通（Pre-application Meeting）
提前准备高质量文档 → 缩短补件次数
使用专业顾问（如仁港永胜）降低补件量

通常时间：6–9 个月。

Q27：捷克 MiCA CASP 是否允许“预申请阶段提交草稿文件”？

允许且建议。

CNB 在以下阶段可接受草稿：

商业计划草稿（BP Draft）
风险管理政策草稿
ICT 架构草稿
组织结构图
AML 程序草稿

预审沟通可减少后续补件 20–40%。

Q28：捷克 CASP 是否允许在申请期间已经运营业务？

不允许。
MiCA 明确说明：

❌ 未获授权前不得提供 CASP 业务
❌ 不得向公众市场宣传
❌ 不得进行交易、托管、执行订单等活动

您可以：

✔ 进行技术开发
✔ 进行内部测试（Sandbox）
✔ 进行内部使用
✔ 进行合规建设

Q29：捷克 CASP 是否需要准备“Wind-down Plan（有序退出计划）”？

必须。

MiCA 要求退出计划包括：

客户资产处理方式
托管资产清算
业务关停流程
投诉处理
数据保留
技术系统关闭流程
外包终止流程

CNB 对此文档要求比奥地利更高。

Q30：捷克 CASP 是否必须准备“利益冲突政策（Conflict of Interest Policy）」？

必须，这是 MiCA 核心要求之一。

政策需包含：

自营 vs 客户利益
关联方交易
做市与交易平台冲突
托管与运营冲突
董事/管理层利益披露
独立性机制（Chinese Wall）

CNB 会直接根据该政策判断“业务能否控风险”。

第二章：业务模式与业务范畴（Q31～Q70）

这一章是 MiCA 审查中最重要的一章之一，CNB 特别关注：

您到底做什么业务？
是否触发 MiCA 10 类授权？
是否触发 MiFID II 证券属性？
是否包含托管义务？
是否涉及平台运营？
是否涉及做市？
是否涉及风险管理不足？

仁港永胜 CAN（Crypto Architecture Navigator）结构化解析体系将在这一章体现核心优势。

第二章｜业务模式与业务范畴（Q31～Q70）

Q31：捷克 CASP 可以经营哪些 MiCA 规定的 10 类加密服务？

MiCA 全部分业务均可申请：

托管（Custody）
运营交易平台（Trading Platform）
接收与传送订单（Reception & Transmission）
执行订单（Execution）
交换服务（Crypto-to-Fiat / Crypto-to-Crypto）
自营交易（Own Account Dealing）
投资建议（Investment Advice）
投资组合管理（Portfolio Management）
代币发行协助（Placement）
Crypto Lending（加密借贷）

捷克 CNB 不额外减少，也不增加类别。

Q32：哪些业务最容易获批？哪些业务最难？

最容易获批（监管风险低）

接收 & 传送订单
执行订单
交换服务
投资建议类
非托管型服务（Non-custodial）

难度中等

托管（Custody）

最难（高度敏感）

交易平台（Trading Platform）
自营交易（Market Making）
Crypto Lending（加密借贷）
Staking-as-a-Service
RWA（资产实物挂钩）

捷克 CNB 对 托管＋撮合＋做市 的组合格外敏感。

Q33：业务模式要如何向 CNB 说明？（关键模板）

CNB 要求您在 BP（商业计划书）中清楚描述：

业务链（Business Flow）
交易链（Trading Flow）
钱包链（Wallet Flow）
资金链（Fiat Flow）
风控链（Risk Flow）
合规链（Compliance Flow）
ICT 架构（System Flow）

仁港永胜提供的 MiCA 六链业务说明书模板 完全符合 CNB 审查要求。

Q34：CASP 是否可以“组合申请多个业务类别”？

可以，而且非常常见，例如：

托管 + 交换
执行订单 + 接收订单
交易平台 + 做市（Own Account）
投资建议 + 投资组合管理

⚠️ 注意：类别越多，风险管理文件越复杂。
组合申请必须证明：

组织结构足够完整
人员足够
资本金足够
系统能承担职责
风险利益冲突得到解决

仁港永胜可协助在组合申请中做“利益冲突隔离结构”。

Q35：捷克 CNB 对“交易平台（Exchange）”型 CASP 有哪些特别要求？

交易平台必须满足：

有序市场（Orderly Market）机制
明确撮合逻辑
无暗池（No Dark Pool）
无优先队列（No Preferential Queue）
清晰撮合算法
市场监控系统（Market Surveillance）
价格操控防护
做市规则披露
订单类型（Market/Limit/Stop）
清晰收费结构
最终交易确认流程

缺少任何一项 → 补件（RFI）增加约 20–40 条。

Q36：捷克 CASP 可以提供 OTC 服务吗？

可以，但要区分：

1）撮合型 OTC（Broker Model）

→ 属 “接收、传送、执行订单”
→ 需要申领相关类型

2）对手方型 OTC（Principal Model）

→ 属自营交易（Own Account）
→ 高资本要求（≥75 万欧）

3）大额 OTC（Block Trade）

→ 必须建立 AML 高额交易监控
→ 可能触发 STR
→ 必须防止市场操控

仁港永胜会为 OTC 业务制作完整 OTC Risk Memo + OTC AML Policy。

Q37：捷克 CASP 是否可经营“NFT 交易”业务？

MiCA 不监管 NFT，除非：

不是“非同质性”（其实是批量、可互换、通证化权益）
NFT 具有金融属性
NFT 的经济模型触发“证券化”
NFT 平台具备撮合功能 → 属“交易平台”

捷克 CNB 会按 实际功能而非名称 判断。

Q38：捷克 CASP 是否可以运营 P2P 交易平台？

可以，但务必澄清：

P2P 是否涉及“托管暂存”
平台是否持有客户资产
是否提供担保
是否提供撮合引擎
是否收取费用
是否提供钱包服务
是否有市场操控风险

如果平台参与程度较高，即便名为 P2P，也会被 CNB 视为“交易平台”。

Q39：捷克 CASP 是否可以做“Crypto Payment（加密支付）”？

MiCA 不覆盖支付业务。
若涉及：

加密支付 → 法币结算
商户接入（Merchant Acquiring）
虚拟资产钱包 + 支付功能
加密充值卡或 VISA/MC 卡

则很可能需要：

PSD2 PI 或 EMI 牌照

如果不想处理 PI/EMI，必须：

明确“非支付服务”
仅为“价值交换”
仅为 crypto-to-crypto

仁港永胜可提供：
Crypto Payment vs PSD2 Clash Avoidance 模型 → 避免误触 PSD2。

Q40：捷克 CASP 是否可以经营 RWA（资产通证化业务）？

可以，但重点是：

RWA 是否为证券？
是否触发 MiFID II？
是否涉及基金管理？
是否涉及证券托管？
是否与现实资产挂钩（房地产、债券、收益权）？

如果 RWA 有“收益承诺”→ 很可能要求证券牌照。

仁港永胜可协助提供：
RWA Token Classification Legal Opinion（捷克与欧盟双版）

Q41：捷克 CASP 是否可以提供“财富管理或金融咨询（Financial Advisory）”？

可以，但：

若属“加密资产投资建议” → 属 MiCA
若涉及证券 → 属 MiFID II 规定

必须划清界线：

只建议 crypto? → MiCA
混合建议（Crypto + Securities）？ → 需要 双牌照结构（CASP + MiFID Firm）

Q42：CASP 是否可以充当“托管银行”角色？

不可以。

MiCA 托管 ≠ 银行托管。

托管银行属于：

银行（Credit Institution）
或投资公司（Investment Firm）

CASP 托管是特殊制度，不能替代银行托管。

Q43：捷克 CASP 是否可以提供“保证金交易（Margin Trading）」？

不能。

保证金交易属于：

杠杆
信贷
金融衍生品

MiCA 不涵盖杠杆衍生品，属于 MiFID II 衍生品监管范围。

若提供杠杆 → 必须获得：

⚠️ MiFID 投资公司牌照（Investment Firm License）

Q44：捷克 CASP 可否发行“收益凭证型代币（Yield Token）」？

高风险。
可能触发：

ART（资产参考）
证券型条款
集体投资计划

除非：

完全无收益承诺
完全不属于投资类别

否则法律意见通常会警告 → 必须申请证券牌照。

Q45：捷克 CASP 是否可以“做市（Market Making）」？

可以，但：

属自营交易类（Own Account）
资本金 ≥75 万欧
需披露 MM 规则
需设立独立风控
必须建立 Market Surveillance
防止操控
披露 Spread、库存管理机制

这是 MiCA 最敏感业务之一。

Q46：捷克 CASP 是否可以向机构客户（如基金、家族办公室）提供服务？

可以，而且：

机构客户 → 风险更低
AML 更严格
更可能触发“专业投资者模式”
CNB 对机构业务更友好

但文件与合规要求依然严格。

Q47：捷克 CASP 是否可以经营“Crypto ATM 加密货币自动售卖机」？

可以，但按 MiCA 分类：

兑换服务（Crypto Exchange）
托管不得发生（除非用户钱包整合）
必须提供 AML/KYC
需防止匿名使用
必须限制现金交易

捷克 AML 对现金使用极其严格（高于 EU 平均水平）。

Q48：捷克 CASP 是否可以提供“多重身份 KYC（Multi-tier KYC）」？

可以，但必须：

清晰风险分级（Risk-based Approach）
低风险 → 简化尽调（SDD）
高风险 → 加强尽调（EDD）
禁止匿名客户
禁止“仅邮箱注册”模式

MiCA 强调“实名制 + 可追踪性”。

Q49：捷克 CASP 是否可以提供“代扣税功能（Withholding Tax for Customers）」？

不是强制，但 CNB 会鼓励：

DeFi 收益
Staking 收益
Lending 收益

若能协助客户正确缴税 → 有利于监管评价。

捷克财税局对加密收益非常关注。

Q50：CASP 是否允许用户“无 KYC 小额交易”？

不能。

捷克 AML 法明文禁止：

❌ 匿名
❌ 无 KYC
❌ 仅邮箱
❌ 现金无限额交易

欧盟 AML 法接近“完全实名制”。

Q51：捷克 CASP 是否可以提供“托管型钱包 + 借记卡（Crypto Card）」？

可以，但需分业务：

托管钱包 → MiCA Custody
卡片支付 → PSD2 或 EMI 牌照

因此若提供 Crypto Card，多数需要“双牌照结构”：

✔ CASP
＋
✔ EMI（发卡 + 电子货币）

若不想申请 EMI，可以采用：

第三方 EMI 代发行
CASP 仅负责加密端

仁港永胜擅长设计 CASP + EMI 联合结构。

Q52：捷克 CASP 是否可以使用智能合约替代托管业务？

不能完全替代。

MiCA 托管是“法律责任”，必须有人负责：

私钥保管
客户资产隔离
丢失赔偿责任

智能合约可以作为工具，但不能作为“托管主体”。

Q53：捷克 CASP 是否可以运营“代币 Launchpad」？

可以，但必须：

白皮书符合 MiCA
透明风控
不能承诺高收益
KYC + AML 合规
风险披露文件
不得宣传“快速致富”
不得向被禁国家销售

若项目具有金融属性，需法律意见书。

Q54：捷克 CASP 是否必须提供法币通道？

不是强制。
您可以：

✔ 仅提供 crypto-to-crypto 服务
✔ 无需接触法币
✔ 无需使用银行
✔ 风险更低

越简单的业务 → 越容易获批。

Q55：捷克 CASP 是否允许使用跨境支付服务（如 USDT/USDC 作为存取款）？

MiCA 明确指出：

USDT/USDC 属“EMT（电子货币代币）”
EMT 必须由 EMI 发行
CASP 仅能提供“服务”，不能“替代支付”

因此不能把 USDT 存取款当作“支付渠道”。

Q56：捷克 CASP 是否可以完全不触碰加密资产，只做“技术服务”？

可以，但：

若客户资产未被平台控制
若不执行订单
若不撮合
若不托管

才属于“非 CASP 技术服务”，不用牌照。

仁港永胜擅长设计“免牌照业务结构”，符合工程团队需求。

Q57：捷克 CASP 是否允许用户“多账户模型（Multi-Account per User）」？

允许，但必须：

有 KYC link（统一身份）
客户资产聚合到用户层级
无匿名
无洗钱风险

MiCA 允许技术上多账户，但 AML 必须单一用户视角。

Q58：捷克 CASP 是否可以经营“点对点借贷（P2P Lending）」？

可以，但 CNB 会审查：

是否属于“信用机构业务”
是否与平台收益挂钩
是否向零售客户推广
是否需要 MiCA Lending 许可
是否触及利率法规
是否可能被视为 Collective Investment

P2P Lending 是 高风险业务。

Q59：捷克 CASP 是否可以提供“Robo-advisor AI 投顾」？

可以，但必须：

清晰算法说明
风险披露
纳入 ICS 与 AML
避免误导“无风险收益”
可解释性（Explainable AI）

若涉及证券 → Trigger MiFID II。

Q60：捷克 CASP 是否可以进行“跨链桥（Bridge）」服务？

可，但 CNB 对跨链桥高度担心：

交易不可逆
滥用可能性高
费用不透明
被黑客攻击的案例众多

必须：

说明技术架构
提供审计报告
提供漏洞修复计划
建立反洗钱控制（链上分析）

Q61：捷克 CASP 是否可以提供 Layer2 Rollup 相关服务？

可以，但需说明：

结算链
主链桥接
Sequencer 风险
Rollup 资金流
技术责任边界

必须避免“custodial sequencer”形式（监管极敏感）。

Q62：捷克 CASP 是否可以成为 DAO 的运营者？

可以，但若：

DAO 有接管权
DAO 有平台规则
DAO 有资金管理
DAO 有收益分配

→ 运营者仍需申请 CASP 牌照。

DAO ≠ 监管豁免。

Q63：捷克 CASP 是否可以从事“广告代理 / 推广业务”？

可以，但：

广告内容不得误导
禁止承诺收益
必须发布风险声明
不能针对未成年客户
不能面向被制裁国家

MiCA 对广告有明确规则。

Q64：捷克 CASP 是否可以仅做“白标交易所”业务？

可以，但 CNB 会审查：

您是否实际运营？
是否控制订单？
是否触发托管？
是否共享责任？
技术提供者是否安全？

白标交易所往往仍需 CASP 牌照。

Q65：捷克 CASP 是否可以使用总部 + 分公司模式？

可以，但 MiCA 要求：

Home Member State（捷克）负责监管
分公司受 Host Member State 的 AML/消费者保护监管
必须提交护照通知（Passporting Notification）

CNB 会审查总部是否有足够资源。

Q66：捷克 CASP 是否可以不托管资产，只做“非托管钱包（Non-custodial Wallet）」？

可以，这类业务更容易获得 CASP 授权。

但必须说明：

如何证明“不控制私钥”
如何处理链上分析
如何管理高风险客户
如何防止混合托管
如何满足客户尽调要求

非托管服务仍需 AML/KYC。

Q67：捷克 CASP 是否可以运营“流动性池（Liquidity Pool）」？

高风险。

若平台：

控制用户资产
设置参数
收取费用
提供池子规则
管理池子升级
分配收益

→ 多数情况下 CNB 会认定为 MiCA 托管 + 投资服务。

Q68：捷克 CASP 是否可以进行“积分、点数、游戏 Token」业务？

可以，但需法律意见说明：

是否非金融属性
是否无收益承诺
是否无法兑换现实价值
是否属于“封闭系统”

只要“可兑换价值”，就可能属于 MiCA Crypto-Asset。

Q69：CASP 是否可以提供“托管 + 投资组合管理（Portfolio Management）」？

可以，但属于高级 MiCA 授权：

高度合规
高 AML 风险
高冲突风险
高资本要求
高运营责任

需要单独撰写 Portfolio Management Policy。

Q70：捷克 CASP 是否可以同时经营多类业务（例如交易所 + 托管 + Staking + Lending）？

可以，但难度巨大。

CNB 会审查：

每一类业务的风险
风险是否叠加
是否有利益冲突防火墙
是否有独立人员
是否有独立 ICT
风险模型是否清晰
客户资产保护机制是否足够
资本金是否匹配
是否能提供“有序市场”

项目越复杂 → 审查时间越长 → 补件越多。

仁港永胜可为多业务结构提供 MiCA 全业务矩阵（Business Mapping Matrix），帮助一次性通过 CNB 补件。

第三章：牌照申请流程 + 补件（RFI）+ 监管面谈（Q71～Q110）

第三章是“实际申请中最常遇到补件的部分”，也是捷克 CNB 最严谨的审查阶段。
以下 40 条问答完全对标：

MiCA 授权程序
CNB 审查风格
欧盟通用监管流程
仁港永胜过往 MiCA 项目经验（奥地利/德国/爱沙尼亚/捷克）

第三章｜申请流程 + RFI 补件 + 监管面谈（Q71～Q110）

Q71：捷克 CASP 牌照申请的整体步骤是什么？

完整流程如下：

第 1 步：业务模型评估（Business Model Assessment）

由项目方 + 仁港永胜完成 BM Mapping
分析是否触发 MiCA 类别
确认资本金、人员、系统要求

第 2 步：成立捷克公司（s.r.o / a.s）

第 3 步：文件准备（Documentation Stage）

共 30~50 份监管文件，包括：

BP、ICS、AML、ICT、风险政策、托管政策等

第 4 步：正式提交申请（Submission to CNB）

第 5 步：RFI 补件阶段（Regulatory Q&A）

一般 1～3 轮，每轮 20~80 条问题

第 6 步：监管面谈（Supervisory Interview）

第 7 步：正式获批（Authorization）

正常完整周期：6–9 个月
复杂结构：9–12 个月

Q72：捷克 CASP 申请需要提交多少份文件？

一般情况：
30～50 份监管文件（Policies & Procedures）

包含：

BP（商业计划）
AML Manual
ICS（Internal Control System）
ICT & DORA 报告
Outsourcing Policy
Custody Policy
Market Abuse Policy（若有交易）
Governance Framework
风险登记册 Risk Register
组织架构图
合规声明

仁港永胜完整模板包可直接使用。

Q73：文件提交方式是什么？可以在线提交吗？

当前 CNB 采用：

混合方式：电子档 + 正式书面提交
正式材料需 捷克语 + 英文 双语
某些政策仅接受捷克语版本
邮寄至 CNB 授权部门（Licensing Division）
后续 RFI 可使用电子沟通

仁港永胜可负责全程提交与沟通。

Q74：是否可以用英语提交全部文件？

不行。

CNB 最终审查 必须包含捷克语版本：

核心制度文件（AML/ICS/ICT）必须捷克语
非核心文件（BP/技术说明）可英文
面谈通常使用英语，但需准备捷克语支持文件

仁港永胜可安排 专业捷克语法律翻译（Reg-Tech Translator）。

Q75：递交申请后多久会收到第一次补件（RFI）？

一般 3～6 周。
第一次 RFI 通常包含：

业务模型问题
AML 细化要求
风险管理框架
ICT 系统问题
董事、股东相关补件

第一次 RFI 数量通常为 20～60 条。

Q76：RFI 补件通常分几轮？

常见情况：

2～3 轮（常见）
4～5 轮（如果业务复杂）
最快情况下：仅 1 轮

平台型、托管型会更多补件。

Q77：RFI 补件需要在多长时间内回复？（截止日期）

CNB 通常给予：

10 个工作日
可申请延长至 20～30 天
超过期限可能导致流程中断

仁港永胜会协助准备补件草稿，并统一交付前审查。

Q78：RFI 常见问题有哪些？（捷克 CNB 热点）

最常出现的问题类别：

业务链不清晰
托管架构说明不足
Risk Register 不够细
AML KYC 场景不够具体
ICT 网络安全不足
外包责任划分模糊
董事经验不足
资本金充足性解释不充分

仁港永胜拥有 300+ 条 RFI 官方风格题库 可套用。

Q79：RFI 补件通常以什么形式提交？

标准格式：

正式信函（Letter to CNB）
附件（Attachment）
更新后的制度文件（Redline + Clean）
风险矩阵

仁港永胜常用 RFI Matrix Template，可清晰呈现：

问题
回复
附件
风险缓解

Q80：面谈是什么形式？是审查重点吗？

非常重要。
面谈形式：

CNB 官员 + 申请公司董事 / AML Officer
一般采用在线（MS Teams）
时间：60–120 分钟

面谈重点：

业务理解
风控能力
私钥管理
AML 流程
ICT 架构与外包
董事是否实际参与经营

仁港永胜可提供模拟面谈训练。

Q81：面谈前必须准备哪些材料？

至少要准备：

组织结构图
业务流程图
钱包架构图
合规制度摘录
DORA 控制框架
风险登记册（最新版本）
Stress Testing 报告（如交易平台）
Outsourcing Map

我们会准备“面谈资料包（Interview Pack）”全套。

Q82：面谈时 CNB 常问的问题有哪些？

示例：

为什么选择在捷克申请？
您如何防止客户资产混同？
私钥如何管理？
如果客户资产被盗怎么办？
如何界定高风险客户？
贵公司的备援计划是什么？
如何保证做市不会操控市场？
您的 AML Officer 为何具备资格？

仁港永胜有 面谈问答库 可直接套用。

Q83：申请过程中是否可与监管保持沟通？

可以且强烈建议：

Pre-application meeting
Submission Clarification
RFI Clarification Meeting
面谈前沟通

沟通有助减少补件量。

Q84：CNB 面谈是否允许法律顾问或顾问团队参与？

可以，但：

顾问不能代替申请公司回答
顾问只能补充信息、解释制度
核心问题必须由董事或 AML Officer 回答

仁港永胜可辅导角色分工。

Q85：是否必须聘请当地董事（Local Director）？

MiCA + 捷克公司法要求：

至少一名董事必须为 欧盟居民
（捷克、斯洛伐克、奥地利、德国、荷兰等 EU 国家）

若董事会全部在欧盟以外 → 必定会补件。

Q86：是否必须聘请当地 AML Officer？

必须。
捷克 AML 法（Act 253/2008）要求：

AML Officer 必须居住在 EU
最好在捷克当地办公
必须能与 FAU（捷克 FIU）实时沟通
必须熟悉捷克 AML 实务

这是 CNB 最看重的角色之一。

Q87：董事/高管必须亲自参加面谈吗？

必须。
如果董事缺席：

监管会质疑“是否实际参管经营（Mind & Management）”
可能导致审查延迟
在复杂案例中直接导致拒牌

仁港永胜会训练董事面谈技巧，使其回答简明、专业、合规。

Q88：如果 RFI 回答不佳，会怎样？

常见后果：

进入下一轮补件
CNB 认为申请材料不成熟
要求提供更多文件
延长审查期限
甚至 终止申请程序

仁港永胜会在提交前进行三重质检，避免此风险。

Q89：申请是否可能被拒绝？常见拒绝原因是什么？

可能拒绝。

常见原因：

业务模型与文档不一致
董事经验不足
AML 架构不成熟
私钥托管架构风险高
风险管理不合格
ICT 安全不足
外包关系太复杂
无法证明本地实体运作

拒绝率：

简单业务 → 低
交易所型 → 中高
托管 + 做市 → 高

Q90：是否需要证明资金来源？（Source of Funds / Source of Wealth）

必须。
适用对象：

股东
董事
投资人
实际控制人（UBO）

常见资料：

银行流水
税单
投资收益
企业股权证明
法律意见书（如必要）

Q91：需要准备商业计划书（BP）吗？巴同（BaFin 风格）还是 MiCA 风格？

需要。
必须包含：

业务说明
风控说明
市场分析
财务预测（3 年）
外包结构
资本金计划
风险场景
人员安排

仁港永胜提供 MiCA 标准版 BP 模板（捷克 CNB 专用）。

Q92：BP 需要预测多少年的财务数据？

通常 3 年财务预测：

收入（按业务类别）
运营成本
ICT 成本
合规成本
人员成本
资本充足性预测

CNB 会特别关注“1 年后是否现金流为正”。

Q93：是否必须聘请捷克会计师和审计师？

必须聘请：

捷克本地簿记公司（Accounting）
年度强制审计（Auditor）

MiCA 要求审计师必须能够出具：

客户资产隔离报告
资本金合规报告
年度审计报告

仁港永胜可提供 CNB 接受的会计/审计团队名单。

Q94：CNB 是否会到办公室检查？（On-site Inspection）

可能。

若 CNB 有疑虑，将要求：

到当地办公室
检查 ICT 系统
检查文件
检查人员是否实际运作
检查外包关系是否可控

许多在爱沙尼亚/马耳他“空壳运作”的团队会被 CNB 直接拒绝。

Q95：是否可以提前提交“预审材料”？

可以。

推荐提交：

BP Draft
AML Draft
ICS Draft
ICT 架构
外包框架图

预审有助减少 20–40% 补件量。

Q96：申请需要准备哪些 KYC/AML 流程文件？

至少包含：

KYC Flow
EDD Flow
Customer Risk Scoring
Transaction Monitoring Flow
STR Filing Flow（向 FAU 上报）
Sanction Screening Flow
Onboarding Questionnaire

仁港永胜提供完整 AML Suite。

Q97：监管是否要求模拟案例（Case Study）？

CNB 常要求：

3–5 个 onboarding case
3 个高风险客户案例
交易监控触发案例
STR 上报案例
风险评分示例
场景触发说明

仁港永胜提供内置案例库。

Q98：是否必须准备 Outsourcing Register（外包登记册）？

必须。
MiCA 明确要求：

完整外包列表
服务边界
SLA
风险评估
监控机制
退出计划

DORA 更强调 ICT 外包。

Q99：监管是否会要求进行 ICT Penetration Test（渗透测试）？

强烈建议提供：

Pen-test 报告
Vulnerability Assessment
Bug Fix Report

交易平台/托管业务 → 几乎必查。

Q100：申请流程中是否需要提供客户资金隔离证明？

任何涉及托管或资金流的业务必须提交：

资金隔离说明
银行账户结构
客户 vs 公司基金分离图
Reconciliation Flow（对账流程）

否则 CNB 会补件要求。

Q101：是否需要提供 Custody Key Management Framework？

若业务涉及托管，必须提供：

HSM/MPC 架构
Key Generation Ceremony
Key Rotation 计划
Key Recovery 流程
冷热钱包策略
权限控制

这是托管服务能否获批的核心文件。

Q102：监管是否需要 Stress Testing / Scenario Analysis？

如果您是交易平台／做市商，必须：

极端行情冲击测试
流动性压力测试
系统并发压力测试
安全事件测试
资金耗尽测试

仁港永胜可准备 Stress Test 模板。

Q103：申请过程中是否需要解释“业务为什么选择捷克”？

常见回答结构：

捷克位于欧盟中心，适合护照
CNB 监管风格严谨但可沟通
公司希望在 EU 建立长期实体
选择欧盟中心地带做合规业务
与当地 AML 要求匹配

不建议回答：

❌ “捷克容易获牌”
❌ “捷克便宜”
❌ “捷克监管宽松”

Q104：申请是否需要准备 Governance Framework？

必须。

Governance Framework 包含：

董事会
高管层
AML Officer
Risk Officer
ICT Officer
合规官
决策机制
报告机制

若 Governance Structure 不完善 → 必定补件。

Q105：是否必须提供 Risk Register（风险登记册）？

必须。
内容包括：

运营风险
市场风险
流动性风险
ICT 风险
洗钱风险
交易操纵风险
客户资产风险
Outsourcing 风险
RegTech 风险

仁港永胜提供 EU Risk Matrix 版本，包含 100+ 风险条目。

Q106：要提交组织架构图（Org Chart）吗？

必须。

至少包括：

董事会
管理层
AML 部门
风险部门
IT 部门
客服部门
外包供应商链接

CNB 会关注人员是否足够。

Q107：CNB 是否要求解释股东结构？

必须。

包括：

详细股权结构图
所有中间层公司
UBO
控股结构穿透
所有国家事先说明
高风险国家必须额外解释

结构越透明越容易获批。

Q108：是否必须提交 Fit & Proper 文件？（诚信、能力证明）

必须。
文件包括：

无犯罪记录
CV
资质证书
证明过往经验
财务诚信声明
监管历史声明

董事/AML Officer/Risk Officer 是重点。

Q109：是否必须提交 Customer Journey（客户旅程）？

建议提交。
包括：

注册流程
KYC 流程
上传文件
风险评分
交易限制
提币限制
客户等级
客诉流程

CNB 会根据 Customer Journey 判断业务合规度。

Q110：什么时候会正式收到牌照批准？

一般：

所有补件完成
监管面谈通过
无重大风险
资本金到位
实体已经准备就绪
→ 就能获得 Authorization Letter。

正式授权后，可立即使用护照进入欧盟市场。

第四章｜治理结构、人员要求、实体要求（Q111～Q150）

本章完全对标 MiCA + 捷克《Act on Capital Market Undertakings》+ CNB 实务审查逻辑。
重点覆盖：

董事会（Board）
高管层（Senior Management）
AML / MLRO
Risk Officer
ICT / DORA 合规
Outsourcing 实体要求
Mind & Management（实际经营）
本地实体要求

仁港永胜唐生根据多国项目经验（奥地利 / 德国 / 爱沙尼亚 / 捷克），整理如下深度 FAQ。

第一节：治理结构要求（Governance Requirements）

Q111：捷克 CASP 必须设立哪些治理机构？

必须具备以下机构：

董事会（Board of Directors）
高级管理层（Senior Management）
合规部门（Compliance Function）
风险管理部门（Risk Management Function）
AML/MLRO（Anti-Money Laundering Officer）
内部控制（Internal Control）
ICT / 网络安全功能（ICT Function – DORA 要求）

托管类、交易平台类，还需配备：

Custody Function（私钥管理与资产保管责任人）
Market Integrity Function（如有订单簿/做市/撮合）

Q112：治理结构中哪些角色 CNB 最看重？

监管最关注的 5 大关键岗位：

AML Officer / MLRO（反洗钱负责人）
Risk Officer（风险官）
ICT Officer（信息安全 / 网络安全负责人）
Compliance Officer（合规负责人）
董事会主席 / Managing Director

特别强调：
❗ AML Officer & Risk Officer 是否驻 EU，是审查重点
❗ ICT Officer 是否能理解托管技术（HSM / MPC / Cold Wallet）
❗ 董事会是否有金融、审计或密码学背景

Q113：是否允许同一人兼任多个岗位？

允许，但需满足条件：

岗位	是否可兼任？	限制
合规官 + AML 官	❌ 不可	MiCA & AML 法律明确禁止
风险官 + AML 官	❌ 不可	存在利益冲突
风险官 + 合规官	✔ 可	必须解释如何避免冲突
ICT 官 + DPO	✔ 可	DPO（数据保护官）不独立要求
董事 + MLRO	✔ 可	若具备 AML 经验

简要总结：
✔ 可兼任：风险+合规、董事+AML、ICT+DPO
❌ 不可兼任：合规+AML、AML+风险

仁港永胜会根据团队背景出具“兼任冲突缓解说明”。

Q114：董事会成员必须具备哪些经验？

至少需要：

过往金融行业 3–5 年经验
风险/合规/支付/交易平台经验
管理经验（management role）
了解欧盟金融规则
学历需本科以上（法律、金融、工商、IT 优先）

若董事没有金融经验 → 必定补件。

Q115：董事人数有最低要求吗？

MiCA 规定：

至少 2 名董事（4-eyes principle）
其中至少 1 名须为 EU 居民
不能是“挂名董事”或“秘书公司董事”

若全部在海外 → CNB 将要求提供说明并可能拒绝。

Q116：董事必须驻捷克吗？

不要求“必须”，但必须有：

至少一名董事或高管驻 EU
面谈必须能即时参与
能证明“Mind & Management 在 EU”

若无人驻 EU → 难以获批。

Q117：董事名单提交后可以更换吗？

可以更换，但需：

向 CNB 报备
更新 Fit & Proper 文件
更新 Governance Framework
若已在 RFI 阶段 → 延迟审查
若更换 AML Officer → 必定补件

建议：申请期间尽量稳定管理层。

Q118：是否必须聘请独立监事或外部顾问？

非强制，但建议：

外部合规顾问（仁港永胜）
外部风险顾问
外部 ICT 顾问（DORA 专家）

可增强监管信心。

Q119：业务规模很小是否可降低治理结构要求？

不可。
MiCA 对 CASP 治理要求与业务规模无关，必须满足“最低职业标准”。

Q120：公司必须在捷克设置实体办公室吗？

必须。

最低要求：

独立办公场所（真实办公室）
可用于 CNB 现场检查
本地 AML/合规可实体办公
可展示实体运营证据：
- 办公合同
- 办公照片
- 本地员工名册

虚拟办公室 → 100% 拒绝。

第二节：人员要求（Fit & Proper Requirements）

Q121：人员审查（Fit & Proper）包含哪些要素？

CNB 审查 3 大维度：

诚信（Integrity）
- 无犯罪记录
- 无监管处罚
- 无破产记录
能力（Competence）
- AML / Compliance 专业经验
- IT / 风险管理技能
时间投入（Time Commitment）
- 是否兼职过多
- 是否能投入足够管理精力

Q122：AML Officer 的核心要求是什么？

四大要求：

必须为 EU 居民
必须具备 2+ 年 AML 经验
必须熟悉欧盟 AMLD5 / AMLD6
必须了解捷克 AML 法（Act 253/2008）

额外：

必须能直接与捷克 FIU（FAU）沟通
需熟悉 STR 程序

AML Officer 是获牌关键角色。

Q123：Compliance Officer（合规官）有哪些要求？

需具备：

欧盟金融法经验
MiCA / PSD2 / AMLD 法律理解
过往合规经验 2–5 年
英语能力良好

监管要求其实际“独立”，避免冲突。

Q124：Risk Officer（风险官）需要哪些条件？

必须熟悉：

运营风险
ICT 风险
市场风险
客户资产风险
交易欺诈风险
Outsourcing 风险
交易监控（如有平台）

通常必须具备：

金融风险经验
风控体系设计能力
STRESS TEST 理解

Q125：ICT Officer（信息安全 / 网络安全）有哪些要求？

ICT Officer 必须能够：

制定 ICT 政策
解释网络安全措施
理解 DORA（欧盟数字运营韧性条例）
监督外包 IT（如 AWS、Fireblocks）

托管类业务需具备私钥管理知识。

Q126：是否可以聘请外部 ICT 服务商？

可以，但条件：

不可完全外包
公司必须保留“最终控制权”
必须提供 ICT Outsourcing Register
必须制定 Incident Response Plan
必须提交 SLA、退出机制

若无内部 ICT Officer → 100% 补件。

Q127：MLRO（反洗钱报告官）是否必须与 AML Officer 分开？

CASP 结构中：

AML Officer 与 MLRO 可以是同一人
但必须具备向 FIU 报告的权限

若业务复杂（如交易所）→ 建议分开岗位。

Q128：关键岗位是否必须全职？

是。
以下岗位必须全职：

AML Officer
Compliance Officer
Risk Officer
ICT Officer
Custody Officer（如有托管）

兼职 → 易被 CNB 质疑“资源不足”。

Q129：人员背景不够强可以通过培训提升吗？

可以，但必须提供：

培训计划
考试记录
能力补强证明

但培训不能替代经验，核心岗位仍需要实际经验。

Q130：是否可以聘请顾问团队作为外部合规支持？

可以，但：

顾问不可代替关键岗位
顾问只能负责政策撰写、流程设计、内部审查
核心决策权必须在公司内部

仁港永胜可提供 External Compliance Support。

第三节：实体要求（Substance Requirements）

Q131：MiCA 对实体要求（Substance）强吗？

非常强。
MiCA 明确要求 CASP 必须具备：

真实办公
本地人员
本地控制
本地技术（或可控外包）
实际运营证据
资金流和客户资产透明度

比 VASP 注册模式严格得多。

Q132：是否必须在捷克聘请本地员工？

必须至少有：

AML/Compliance（EU 居民）
Risk（EU 居民）
ICT（EU 居民）

如聘请捷克本地员工更好，但并非强制。

Q133：是否需要提供“运营证明”？

必须，包含：

办公合约
IT 系统演示
员工在职文件
Outsourcing 服务合同
流程 SOP
系统操作证明

面谈时监管会看截图与流程图。

Q134：是否可以将技术外包给母公司？

可以，但必须满足：

SLA（服务等级协议）
Outsourcing Register
母公司受监管（最好）
清晰划分责任
显示本地公司仍有控制权

如果母公司位于高风险国家 → 审查会更严格。

Q135：是否可以使用 AWS / GCP 等云服务？

可以，但必须提供：

数据位置说明（EU 内优先）
备援方案
数据安全（加密）
访问权限管理
灾备计划（BCP/DRP）

若存储客户数据在 EU 之外 → 必定补件。

Q136：监管是否会要求访问源代码？

通常不要求，但以下情况会：

托管类（钱包系统）
撮合引擎（Matching Engine）
做市系统
复杂自动化交易系统

通常要求提供系统架构与安全审查结果。

Q137：是否必须将客户资产保存在捷克境内？

不要求，但必须：

保存在 MiCA 认可的托管结构
具备透明的私钥管理流程
EU 数据保护（GDPR）
客户资产隔离（segregation）
完整对账（reconciliation）

如使用 Fireblocks、Coinbase Custody → 监管认可。

Q138：是否允许客户法币资产托管？

若涉及法币，必须适用：

PSD2 / EMD2（支付机构或电子货币机构）
不能由 CASP 单独托管
必须委托银行/EMI

CASP 本身不能触法币的“支付服务”。

Q139：是否需要提交 Business Continuity Plan（BCP / DRP）？

必须。

需包括：

灾备环境
私钥灾备（多地点保管）
冷备 + 热备场景
关键人员替代机制
系统恢复时间（RTO / RPO）

Q140：是否需要提交 Outsourcing Risk Assessment？

必须。

包括：

供应商背景调查
SLA
退出计划
监控机制
风险评分

仁港永胜可提供 Vendor Due Diligence Template。

Q141：MiCA 对“Mind & Management（实际经营地）”要求是什么？

必须证明：

核心决策在 EU
AML Officer、Compliance Officer 常驻 EU
董事会定期开会
本地有真实运营

若公司全部高管在亚洲 → 审查困难。

Q142：是否需要展示 IT 系统截图？

面谈时通常需要，包括：

KYC 流程截图
Transaction Monitoring 截图
冻结账户流程
Withdraw/Deposit 流程

越透明越容易通过。

Q143：是否必须提供 Incident Response Plan？（安全事件应急计划）

必须。

至少包含：

安全事件分类
通报流程
技术处理时序
与监管沟通机制
客户沟通机制

Q144：是否需要提供市场滥用监控机制？（如适用）

如果业务包含：

撮合交易
做市
订单薄交易

则必须提交 Market Abuse Monitoring Policy。

监管重点包括：

Wash Trading
Insider Trading
Layering / Spoofing
Pump & Dump

Q145：实体规模是否会影响资本金要求？

MiCA 明文规定：
资本金=最低资本金 + 风险加成

风险加成根据：

用户数量
交易量
托管资产规模
订单簿复杂度

仁港永胜可根据模型计算资本金建议。

Q146：是否可以申请多个 CASP 类别？

可以，但文件量会加倍。

例如：

接单 + 托管
托管 + 交易平台
做市 + 运营平台

组合越复杂 → RFI 越多。

Q147：非欧盟公司是否可以做捷克 CASP？

可以，但必须满足：

本地实体
EU 董事
EU AML Officer
EU ICT Officer

若股东全部为非 EU → 必须证明合法资金来源。

Q148：是否必须提交 GDPR / Data Protection 文件？

必须。

包括：

数据地图（Data Map）
DPA（数据处理协议）
隐私政策
数据流向图
数据加密机制

Q149：是否需要对员工进行年度合规培训？

MiCA 要求：

AML 培训
风险培训
ICT 安全培训
反欺诈培训

一年至少一次，并要保留记录。

Q150：是否需要提交公司五年发展计划？

建议提交三年，但最好附带：

“五年业务增长情境”
技术路线
EU 市场扩张计划
护照规则应用计划

监管喜欢看到“长期稳定”。

第五章｜资本金、财务预测、审计要求（Q151～Q180）

Q151：捷克 CASP 在 MiCA 下的最低资本金是多少？如何区分？

MiCA 设定的是“按业务类别”的最低实缴资本金（Paid-up Capital Requirements），大致为三档：

5 万欧元级（低风险服务）：
- 接收与传送订单
- 执行订单
- 投资建议
12.5/15 万欧元级（中等风险服务）：
- 交换服务（Crypto-Fiat / Crypto-Crypto）
- 托管服务（Custody）
- 组合管理等（视具体 MiCA 条文）
75 万欧元级（高风险服务）：
- 自营交易（Own Account Dealing / Market Making）
- 大型交易平台运营（如具备深度订单簿 + 做市）

⚠️ 实务上：

CNB 会将业务组合整体评估：组合多类业务 → 可能要求更高资本缓冲。
“刚好踩线”的资本金（只存入最低数额）通常会被认为风险偏高。

Q152：资本金必须一次性实缴到位吗？可以分阶段注资吗？

一般原则：

申请获批前，至少要 实缴到法定最低资本金；
若商业计划书显示前 1～2 年有亏损，CNB 可能要求额外“资本缓冲”；
实务操作上，可以分阶段注入，但在授权前必须证明 “账户里已经有钱 + 不带杠杆”。

建议做法：

初期注入：最低资本金 × 1.2～1.5 倍，减轻监管担忧；
业务放量后，再视实际运营情况增加资本。

Q153：资本金是否允许来自股东借款或外部贷款？（Shareholder Loan / Debt）

MiCA 和 CNB 都强调：

监管资本金应当为 “自有资金（Own Funds）”，不应以容易被撤回的方式提供。

因此：

不建议用股东借款或金融机构贷款作为资本金来源；
如果确实存在 Shareholder Loan，需要 法律与财务结构解释，证明其“次级、不可随时追回”；
最理想：现金出资 + 股权形式 + 无对价可撤回条款。

Q154：资本金可以用加密资产注入吗？例如用 BTC/ETH 作为出资？

不可以。
MiCA 与捷克公司法都要求：

监管资本金必须为 法定货币（Fiat） 形式的出资；
可以是欧元或捷克克朗（CZK），视公司章程与银行账户而定；
加密资产可以在业务中持有，但不能计入“法律资本金”。

Q155：资本金是否可以用于日常运营开支？（还是要“锁死不动”？）

监管关注的是：

净自有资金（Net Own Funds） 是否持续保持高于监管要求；
资本金不是完全禁止动用，但动用之后，必须确保净资产仍 ≥ 监管资本要求。

实务上：

资本金注入后，部分可用于 IT、合规、人员成本；
但每年审计时，审计师要出具报告：自有资金持续达标。
若净资产跌破监管底线 → 必须增资弥补，否则可能被要求限制业务甚至撤牌。

Q156：CNB 如何评估“资本金是否足够”？

评估逻辑通常包括：

业务类型与风险级别
- 托管、做市、杠杆类业务 → 要求更高 buffer
三年财务预测（3-Year Financial Projection）
- 营收、成本、税费、亏损年限
压力测试（Stress Test）
- 在最差行情 + 费用不变情况下，公司还能坚持多久
集团支持（Group Support）
- 是否有母公司担保或资金支持安排

仁港永胜会帮你准备“资本充足性说明信（Capital Adequacy Memo）”。

Q157：是否必须提交三年财务预测报表？格式如何？

必须，通常包括：

利润表（P&L） – 收入/成本/利润
资产负债表（Balance Sheet） – 资本金、资产结构
现金流量表（Cash Flow） – 投入资本、运营现金流、资本支出

并须按业务模块拆分收入：

交易费收入
托管费收入
兑换费收入
咨询费收入
其他收入（如 Listing Fee、技术服务等）

仁港永胜有标准 Excel 模板：“MiCA 3-Year Financial Projection Template – Czech Edition”。

Q158：财务预测中的“客户数量、交易量”等假设会被 CNB 深度质疑吗？

会，而且经常被问：

您如何得出“第 1 年 1 万客户、第 3 年 10 万客户”的预测？
客户获取成本（CAC）如何估算？
市场竞争情况如何？
为什么认为捷克/欧盟会选择你们的平台？

如果预测脱离现实（比如第一年就做到 Binance 规模），只会引起监管不信任。
建议采用：“稳健 + 可解释” 的预测模型。

Q159：财务预测是否需要考虑“极端行情下的亏损”？

建议明确写入：

假设 BTC/ETH 下跌 60–80% 的压力情景；
交易量下降 50% 的情景；
再叠加运营成本刚性存在 → 看公司还能撑多久；
若在压力情景下仍不至于“资不抵债”，监管会更放心。

这类内容可以写进：“Stress Scenario Analysis” 附录。

Q160：审计要求是什么？是否每年都要审计？

是的，MiCA + 捷克法律要求：

每个财政年度必须进行年度审计（External Audit）；
审计师需就以下事项出具意见：
- 财务报表真实性
- 客户资产隔离情况
- 监管资本是否达标
某些情况下可能还需专项审计（如托管资产报告）。

建议在申请阶段就指定审计师，并附上意向书或合约草案。

Q161：是否必须选择捷克本地审计师？可以用 Big4 吗？

两种均可：

捷克本地中型审计师事务所（成本相对可控）；
国际 Big4（PwC、EY、KPMG、Deloitte）也可以，但成本会明显上升。

监管关心的是：审计师是否具备审查加密业务的能力。
仁港永胜可以介绍熟悉 Crypto / MiCA 结构的审计团队。

Q162：会计记账标准采用哪一套？IFRS 还是本地 GAAP？

捷克允许：

使用 捷克本地会计准则（Czech GAAP） 作为法定报表基础；
为集团或投资者需要，也可以单独编制 IFRS 报表。

MiCA 本身不强制 IFRS，但要求：

资产分类清晰（包括 Crypto Asset 的会计处理）；
客户资产与自有资产分开列示（Off-Balance or Segregated）。

Q163：加密资产在财务报表里如何计量？

通常处理方式（在多数欧盟国家）是：

将 Crypto Asset 视作 无形资产（Intangible Asset) 或 “Inventories”；
不作为“现金”等价物；
按成本或减值模型计量；
不会因为市价波动直接进入 OCI（与证券有所不同）。

具体处理应由审计师 + 会计师联合决定，仁港永胜可提供“监管接受度较高”的做法建议。

Q164：客户持有的加密资产是否计入公司资产负债表？

原则：客户资产不能计入公司资产。

客户资产属于 Off-Balance（只在附注中披露规模与风险）；
公司的托管责任在附注中说明：
- 规模
- 风险管理
- 保障机制

若把客户资产计入公司资产，会被视为 “混同+误导”。

Q165：客户法币资金如何在报表中体现？

一般处理：

客户法币存放于 “客户资金专户”（bank account in trust）；
记作 “客户负债 + 对应受限资产”；
或以 Off-Balance 构造 + 注释披露方式呈现。

关键目的是向监管与客户证明：

“这些钱不是公司自己的、不能挪用”。

Q166：CNB 会不会对收费模式（Fee Model）提出监管意见？

会，典型关注点：

收费是否透明、合理；
是否存在隐形费用、复杂费用结构；
商品价格明显高于市价是否构成“误导”；
是否对零售客户设置“不合理门槛”或“高额惩罚性费用”。

建议：

在 BP / Terms & Conditions 中清晰列出收费项目 + 费率区间；
对于 VIP 协议，可附上示例说明。

Q167：是否需要提交“费用与收入结构说明书（Fee & Revenue Breakdown）」？

建议提交一份简短但清晰的说明，包括：

每项服务的收费逻辑（按交易量 / 按托管规模 / 按固定费）；
是否对机构与零售差异定价；
是否存在“返佣、返点、推荐奖励”等安排；
是否通过差价（Spread）作为收入来源（尤其是 OTC 模型）。

监管关注：收益来源是否与客户利益存在冲突。

Q168：是否需要准备“资本计划书（Capital Plan）」？

对于成长型平台与交易所，强烈建议准备 Capital Plan，包括：

初始资本金结构（股权注入情况）；
未来 3 年是否有增资计划；
若亏损大于预期如何补充资本；
母公司或投资人是否承诺支持。

可以附上：

股东承诺函（Letter of Support）
或资金来源说明（Funds Availability Letter）。

Q169：监管是否会关心“股息分配政策（Dividend Policy）」？

会。
如果公司计划在前几年大量派息，监管会担心：

资本缓冲不足；
无法覆盖风险事件；
对客户资产安全造成间接威胁。

因此，建议：

在前 3 年 不设立主动派息计划；
说明“公司将优先用于再投资与风险缓冲”。

Q170：是否必须进行税务筹划？（捷克公司税、预提税等）

从 MiCA 角度讲，税务不在授权范围；
但从 审慎经营 与 持续经营能力 考虑，监管期待：

公司已理解捷克公司所得税率（目前约 19%）及税基；
已与税务顾问沟通 Crypto 收入的计税方式；
准备符合当地法律的纳税计划。

仁港永胜可协同税务顾问提供“Crypto Tax Memo – Czech 版”。

Q171：是否必须提供银行出具的“资金证明（Bank Confirmation）」？

建议在授权临近阶段提供：

证明公司账户中持有的资本金额及币种；
说明该资金已无附带条件、可随时用于营运；
若为集团注资，也须说明无还款义务。

有些监管会在最终决议前要求银行证明信。

Q172：资本金可以通过多名股东分散出资吗？

可以，但需说明：

每位股东的出资比例；
各自资金来源（Source of Funds）；
是否有实际控制人（UBO）；
若过度碎片化（例如几十个小股东），会加重 AML 与控制风险评估。

通常结构建议：

一到两名主股东 + 一定比例管理层持股（Management Incentive）。

Q173：集团公司可以对 CASP 提供“内部资金支持安排（Intragroup Support）」吗？

可以，且是优点：

通过集团内部资金支持信（Letter of Comfort / Letter of Support）；
说明当 CASP 资本金不足时，集团将补充资金；
但注意：
- 监管不会完全“算作资本金”；
- 但会提高监管对“持续经营性”的信心。

Q174：审计报告中是否需要单独披露“Crypto 相关风险」？

安全起见，建议让审计师：

在附注中单独一节说明 Crypto 风险；
包括市场波动、技术攻击、监管变化、流动性风险等；
披露公司风控与资本缓冲措施。

这样便于监管与投资者理解整体风险水平。

Q175：是否需要定期（如季度）向监管提交财务数据？

大型 / 高风险 CASP 通常会被要求：

季度性监管报表，包括：
- 自有资金情况
- 客户资产规模
- 营收与成本
- 交易量与用户数
年度审计报表则用于正式审查。

具体频率由 CNB 按风险等级安排。

Q176：如果年度审计发现资本金不足，会发生什么？

可能产生以下后果：

CNB 要求 限期增资；
限制部分高风险业务（如做市、借贷）；
多次发现问题 → 可能导致：
- 罚款
- 业务限制
- 吊销牌照（严重时）

因此要建立内部 Capital Monitoring 机制，监控净资产水平。

Q177：是否可以透过“保险（Insurance）」代替部分资本金要求？

不能直接“代替监管资本”，但可以：

以业务责任险（Professional Indemnity Insurance）降低运营风险；
在 Risk Register 和 Capital Adequacy 说明中，作为“风险缓释工具”。

监管仍重点看“真实资本金”。

Q178：在财务预测中是否需区分 B2B 与 B2C 模式？

建议清晰区分：

B2B 收入（技术服务费、白标、API 使用费）；
B2C 收入（交易费、托管费等）；
不同模式下，成本结构也应明显不同。

这有助于：

向监管说明“客户群体风险画像”；
合理解释收入结构与风险水平。

Q179：财务预测可以使用“乐观情景 + 基准情景 + 悲观情景」吗？

这是非常加分的做法，推荐：

Base Case（基准情景） – 按理性假设
Best Case（乐观） – 收入略高、成本略优化
Worst Case（悲观） – 收入打折、成本刚性维持

监管更关心：

在 Worst Case 下，公司是否仍具持续经营能力、资本金是否足够。

Q180：资本金相关材料由谁来准备更合适？财务团队 / 审计师 / 顾问？

最佳组合：

业务数据与模型 → 由项目方提供（对自己业务最清楚）
财务模型结构 → 由财务顾问或 CFO 设计
监管口径与披露方式 → 由合规顾问（如仁港永胜）把关
会计处理与审计可接受度 → 由会计师与审计师最终确认

也就是说：

资本金与财务部分，一定是“项目方 + 顾问 + 审计”三方协同的成果，而不是单独某一方闭门造车。

第六章｜AML / CFT / KYC & 捷克 AML 法专章（Q181～Q210）

本章结合：

MiCA（Reg. EU 2023/1114）
欧盟 AMLD5 / AMLD6
捷克《反洗钱法 Act No. 253/2008 Coll.（又称 AML Act）》
捷克 FAU（Financial Analytical Office）实务要求
CNB（捷克国家银行）的 CASP AML 审查逻辑
仁港永胜在捷克、奥地利、爱沙尼亚、德国项目经验

内容深度覆盖完整 AML 体系、KYC、EDD、交易监控、STR 上报、制裁筛查等监管核心重点。

第一节：AML 架构要求（Governance + 体系设计）

Q181：捷克 CASP 的 AML 体系必须包含哪些核心文件？

至少包括以下“六大 AML 核心文件”，监管必查：

AML / CFT Internal Policy（反洗钱内部政策）
KYC / CDD Program（客户尽调程序）
EDD Program（高风险客户强化尽调程序）
Sanction Screening Program（制裁名单筛查程序）
Transaction Monitoring Program（交易监控程序）
STR Filing Procedure（可疑交易报告程序）

另外还需要：

Risk Assessment（风险评估报告）
Customer Risk Scoring Model（风险评分模型）
Record-Keeping Policy（记录保存）
PEP 识别机制
KYB（企业客户尽调）

仁港永胜会提供一整套“捷克专版 AML 政策合集”。

Q182：AML Officer（MLRO）必须是捷克居民吗？

不必须是捷克居民，但必须满足：

欧盟居民（EU Resident）
可 24/7 对接捷克 FAU（Financial Analytical Office）
具备 AMLD5/6 经验
必须有能力独立上报 STR

捷克 FAU 处理 STR 的效率极快，因此 AML Officer 要能及时响应。

Q183：KYC / CDD 是否可以完全使用外包供应商？例如 SumSub、Onfido？

可以，但必须注意：

✔ 可外包部分

身份验证（eKYC）
文件 OCR
活体检测（Liveness Check）
制裁与名单筛查（Sanction Screening）

❌ 不可外包部分

最终 CDD 决策（必须由 CASP 自己做）
风险评级模型
AML Officer 的最终批准
高风险客户（EDD）的人工审查
客户拒绝（Reject）决策

监管逻辑：KYC 可外包，CDD 决策不可外包。

Q184：是否可以允许客户使用“海外护照 + 海外地址”开户？

可以，MiCA 没有限制国籍。

但必须遵守：

FATF 高风险国家 → 必须 EDD
制裁国家 → 禁止开户（OFAC / EU 制裁）
非欧盟客户 → 更强的 CDD 文件要求

重点：

风险国家 ≠ 禁止国家
高风险客户可以开户，但必须进行强化尽调。

Q185：对于企业客户（KYB），CDD 需要核查哪些内容？

必须核查：

公司注册证书
董事名单
股东结构（Shareholding Structure）
UBO 穿透（直至自然人）
公司业务性质
年报 / 财务报表（如必要）
公司是否在制裁名单
公司是否涉及高风险行业（Crypto、现金业务等）

若 UBO 在高风险国家 → 必须进行 EDD。

Q186：是否需要识别 UBO（Ultimate Beneficial Owner）？

必须。

要求：

穿透公司结构直至自然人（≥ 25% 持股）
若无单一持股 ≥25%，则识别“实际控制人”
UBO 需进行 KYC & 名单筛查
若 UBO 是信托 → 需识别 Settlor/Trustee/Protector/Beneficiary

监管不接受“复杂结构 + 模糊控制权”。

Q187：客户风险评分（Customer Risk Score）如何设计？

评分通常由三部分组成：

1. 地理风险

客户居住地
护照签发国
FATF 风险等级

2. 客户性质风险

零售 / 机构
PEP
行业（如赌场、跨境金流等高风险行业）

3. 产品风险

托管
OTC
大额交易
隐私币（若平台支持）

风险评分必须可解释 + 可自动化计算。

Q188：是否必须对 PEP（政治敏感人物）进行额外尽调？

必须，EDDs 包括：

额外身份证明
资金来源说明（Source of Funds）
财富来源说明（Source of Wealth）
交易行为监控加强
高级管理层批准开户（Senior Management Approval）

未做足 EDD → 必定遭监管处罚。

Q189：是否允许平台使用“风险基于模型（RBA）」处理 KYC？

MiCA + AMLD6 明确要求：
必须使用 RBA（Risk-Based Approach）制度。

但要注意：

RBA 不能作为“宽松开户”的借口
风险越高 → 审查越多
低风险客户也不能完全不审查

示例：
从瑞士来的客户 ≠ 自动“高风险”；
来自中国的客户 ≠ 自动“禁止”。
重点在于完整的风险分析逻辑。

Q190：是否可以允许客户用加密地址（Blockchain Address）作为地址证明？

不可以。
地址证明必须是：

水电账单
税单
银行对账单
政府信件

且有效期通常不超过 90 天。

Q191：是否需对客户的“加密资产来源”进行核查？（Source of Crypto Funds）

是的，尤其适用于：

大额（> €15,000）
OTC
高风险国家
PEP
巨额链上转账（如 > €50,000 / 笔）

核查方式包括：

链上分析（Chainalysis / Elliptic）
提供交易截图
提供矿工收入证明
交易记录（CEX withdrawal history）

MiCA 不允许接受“来路不明的加密资产”。

Q192：是否必须设置“交易监控系统（Transaction Monitoring Tool）」？

必须。

系统应能够：

监控异常交易
标记高风险行为
自动生成 Alerts（告警）
支持 AML Officer 人工复核
支持链上分析工具（If crypto-in/out）

人工监控 ≠ AML 部门。

Q193：交易监控系统必须实时吗？

监管最佳实践：

准实时（near real-time） 或
每日批次（daily batch）

托管型或交易所：建议实时。
低风险业务：每日批次也可接受，但要能解释理由。

Q194：哪些行为属于必须触发“AML 告警”？

典型包括：

高频买卖（suspicious pattern）
多账户循环交易
使用混币器（Mixer / Tornado Cash）
来自暗网的链上地址
异常大额提币
不一致的 KYC 数据
与制裁国家相关的地址

监管最关注：链上风险。

Q195：是否必须使用链上分析工具（Chainalysis/Elliptic/Merkle Science）？

对于含有：

托管（Custody）
存取款（Deposit / Withdrawal）
OTC
交易所（Exchange）

的 CASP → 强烈建议使用。

在 RFI 时监管经常会问：

你们如何识别“高风险来源地址”？

没有链上分析 → 很难说服监管“有效识别加密风险”。

Q196：是否必须对客户进行持续尽调（Ongoing CDD）？

必须。

包括：

每 12 个月更新 KYC（高风险：6 个月）
地址变更更新
黑名单每日筛查
交易行为监控
风险等级重新评估

缺乏持续监控 → 监管高风险信号。

Q197：是否必须向捷克 FAU 上报可疑交易（STR）？

必须。

触发条件包括：

来自混币服务
无合理经济目的的大额交易
PEP 异常交易
客户拒绝提供资金来源证明
匿名高风险地址
背景与交易不匹配

STR 必须由 AML Officer 直接提交。

Q198：STR（可疑交易报告）提交后是否要通知客户？

不可以。

根据捷克 AML 法：

STR 必须“非通知”（Non-Disclosure）。

若通知客户 → 构成刑事责任。

Q199：STR 必须在多久内提交？

越快越好。

捷克 FAU 没有明确“小时级”要求，但 AML 最佳实践：

高风险：24 小时内
中风险：2～3 天内
低风险：不适用 STR（但要记日志）

仁港永胜可协助设置 STR 时序流程图（SOP）。

Q200：KYC 是否可以使用视频认证（Video KYC）？

可以。
监管接受：

视频面谈
远程验证
活体检测

但：

视频必须保存
需有录制的时间戳
需要明确验证步骤（问答逻辑）

视频认证可用于高风险客户的 EDD。

第二节：制裁、名单筛查与风险国家要求

Q201：是否必须对客户进行制裁名单（Sanctions List）筛查？

必须。

包括：

EU Consolidated Sanctions
OFAC（美国）
UN Lists
UK OFSI
国家本地名单（如捷克无独有制裁名单则沿用 EU）

建议使用自动化工具。

Q202：平台是否可以向俄罗斯、伊朗等高风险国家提供服务？

遵循：

EU 制裁框架
OFAC 制裁（如果与美元相关）
MiCA AMLD6 规则

通常：

伊朗、朝鲜 → 绝对禁止
俄罗斯 → 大部分个人可开户，但限制交易规模 + 加强 EDD
古巴、叙利亚、西巴勒斯坦等 → 强 EDD

仁港永胜可提供完整“国家风险矩阵”。

Q203：如何判断客户来自高风险国？

从以下信息判断：

护照签发国
居住地址
IP 地址
付款来源银行
链上来源地址
KYB 公司所在地

不同来源可能冲突 → AML Officer 必须复核。

Q204：是否需要对高风险国家客户进行 Face-to-Face KYC？

非强制，但建议：

视频面谈
收集更多文件
核查资金来源（SOF）
获取财富来源（SOW）

MiCA 的精神：

风险越高，尽调越严格。

第三节：资金来源 / 财富来源（SOF/SOW）审查

Q205：哪些情况下必须获取“资金来源 SOF（Source of Funds）」？

包括：

大额充值（> €15,000）
PEP
高风险国家客户
机构客户（KYB）
OTC
从匿名来源（Mixer）存入
链上高风险标签（Darknet、Rugpull 等）

Q206：哪些情况下必须获取“财富来源 SOW（Source of Wealth）」？

严格条件：

PEP
巨额链上资产（≥ €100,000）
高风险国家
高净值客户（HNW）

SOW 文件可包括：

资产证明
投资收益证明
税单
股权分红记录
创业收入证明

Q207：是否可以接受客户提供的“声明信（self-declaration）」作为 SOF/SOW？

不能作为唯一依据。

可接受：

客户声明
- 交易记录截图
- 银行对账单
- 链上证明

监管最看重“可验证性”。

Q208：是否需要对“链上资产转入”做溯源分析？

必须。

分析范围：

来源地址风险评分
是否与攻击、诈骗、混币关联
是否来自 CEX（如 Binance/OKX）
是否来自已知黑名单地址

必须有：链上交易追踪报告（On-chain Report）。

第四节：交易监控（TM）与行为分析（BA）

Q209：交易监控应重点检查哪些异常模式？

包括：

分拆交易（Structuring）
循环交易（wash trading）
可疑套利
高频转账
与制裁国家的地址交互
交易行为与客户资料不符
OTC 异常价差
巨额提币
充值后立即提币（典型洗钱行为）

平台必须具备自动监控能力。

Q210：是否需要对客户的“IP 地址 + 装置资讯” 做行为监控？

建议做，尤其：

VPN 使用
异国登录异常
多设备登录
多账户共用设备
可疑自动化交易（BOT）

MiCA 并未强制要求，但捷克 CNB 认为行为监控是 交易监控体系的一部分。

第七章｜ICT、网络安全、DORA & 托管技术（Q211～Q240）

第一节：ICT 总体架构与监管期望

Q211：捷克 CASP 在 ICT 方面，监管的总体期望是什么？

监管的核心逻辑：你的技术架构必须匹配你的业务风险。
重点包括：

系统可用性（Availability）：
- 交易平台 / 托管系统不能频繁宕机；
- 关键服务应具备冗余（冗余数据库、负载均衡等）。
数据完整性（Integrity）：
- 交易、余额、订单记录不可被篡改；
- 有完善对账（Reconciliation）机制。
保密性（Confidentiality）：
- 客户数据加密；
- 权限分级控制；
- 防止内部滥用及外部攻击。
可监管性（Auditability）：
- 日志记录完整；
- 关键操作留痕；
- 监管或审计可追溯。

MiCA + DORA 时代：ICT 不再是“纯技术问题”，而是监管核心。

Q212：是否必须编写独立的 ICT Policy / IT Security Policy？

必须。
内容至少包括：

IT 治理结构（谁负责什么）；
系统架构概览（System Architecture Diagram）；
访问控制（Access Control）；
数据加密策略；
日志记录与留存；
漏洞管理策略（Patch Management）；
渗透测试要求；
外包 IT 管理机制。

监管会把 ICT Policy 视为 技术版 ICS（内部控制系统）。

Q213：ICT 文档需要多技术细节？是否要写到“代码级”？

不需要写到代码级，但至少要覆盖：

系统组件清单（Web / API / DB / Wallet / Admin Panel 等）；
各组件之间的数据流向图；
安全边界（Firewall / WAF / VPN）；
用户端与后台如何认证（2FA / MFA）；
加密机制（传输 + 存储）；
隔离区（DMZ / Internal Zone / Admin Zone）。

原则：监管需要理解“系统如何降低风险”，而非“你用什么语言写代码”。

Q214：是否必须采用云服务（如 AWS/GCP/Azure），还是可以自建机房？

两者皆可，关键是：

云服务 → 要符合 DORA 对“关键第三方 ICT 服务”的要求；
自建机房 → 要证明具备专业的物理与网络安全能力。

多数 CASP 选择：

云 + HSM/MPC 托管方案；
仅极少数选“完全自建机房”。

监管不会强制云或自建，但会要求你说明理由与风险管理。

Q215：客户数据（包括 KYC 文档）是否必须存放在欧盟境内？

最佳实践：数据中心在欧盟境内。
如果：

数据存于 EU 以外（例如美东 / 亚洲某国），需要：
- GDPR 合规评估；
- 额外数据传输保护措施（SCC 等）；
- 向监管清晰说明为什么这样设计。

MiCA + GDPR 的叠加效果是：

“尽量让客户数据待在 EU 境内，会简单很多”。

Q216：是否必须实现多因素认证（MFA / 2FA）？

对于以下用户操作，强烈建议并几乎已是监管“隐性要求”：

登录后台管理系统（Admin Panel）；
AML / Risk / Ops 后台；
客户提币操作；
修改安全设置、重置密码。

对零售客户前端：

建议支持 Google Authenticator、短信、Email 2FA 等方式。
监管问到时，回答“只用账号 + 密码”会非常难解释。

Q217：必须建立什么级别的访问控制（Access Control）？

至少做到：

RBAC（Role-Based Access Control）；
每个角色权限明确定义（Read/Write/Admin）；
关键操作“四眼原则”（Two-man Rule / 4-eyes Principle，如大额提币审批）；
所有管理操作必须日志化（Audit Trail）。

例如：

普通客服 → 只能查看部分客户信息；
AML Officer → 只能对交易做标记、不直接动钱；
Wallet Ops → 可发起提币，但需第二人审批。

Q218：后台操作与开发运维是否需要“环境分离”？

是的，建议划分：

生产环境（Production）
测试环境（UAT/Test）
开发环境（Dev）

原则：

开发人员不得直接在生产环境“随意改代码”；
变更须通过 CI/CD + 变更管理流程；
测试数据与真实客户数据隔离。

第二节：DORA 合规与 ICT 风险管理

Q219：什么是 DORA？为何与 CASP 有关？

DORA 全称：Digital Operational Resilience Act（欧盟数字运营韧性条例）。

核心要求：

金融机构（包括 CASP）必须具备 抵抗 ICT 风险的能力；
包括系统中断、网络攻击、故障、外包 ICT 风险等；
要建立 ICT 风险管理框架、事件报告、测试计划、第三方管理。

MiCA + DORA = “牌照 + 数字韧性双轨监管”。

Q220：捷克 CASP 在 DORA 下的最低合规动作有哪些？

至少包括：

ICT Risk Management Framework（ICT 风险管理框架）；
Incident Management & Reporting（事件管理与汇报）；
Digital Operational Resilience Testing（数字韧性测试）；
Third-party ICT Risk Management（第三方 ICT 管理，如云服务商、钱包服务商）；
ICT 业务连续性与灾备（BCP/DRP）。

在申请阶段，必须以政策 + 流程图方式呈现。

Q221：是否要编写独立的 ICT Risk Register（ICT 风险登记册）？

非常建议，而且是 DORA 精神所在。
ICT Risk Register 至少应列出：

网络攻击风险；
DDoS / Bot 攻击风险；
数据泄露风险；
钱包私钥泄露风险；
系统宕机场景；
外包 ICT 供应商中断风险；
软件漏洞与补丁管理风险。

每条风险都要有：Likelihood × Impact + Mitigation。

Q222：DORA 是否要求必须进行“渗透测试（Pen-test）」？

是的，属于“Digital Operational Resilience Testing”的重要部分。
监管期待：

至少每年一次 Penetration Testing；
对外网入口（Web/API）、管理后台进行渗透测试；
对钱包系统与关键模块进行专门测试；
对已发现漏洞要有 修复记录。

提交申请时，可以附上最新的 Pen-test Summary。

Q223：对于第三方 ICT 服务（如云、钱包托管），DORA 有何要求？

DORA 把这类供应商定义为“Critical ICT Third-Party Service Provider”，要求：

供应商应该有良好声誉与成熟合规（AWS、GCP、Azure、Fireblocks 等）；
外包前进行尽调（Due Diligence）；
有明确 SLA（服务水平协议）；
有退出计划（Exit Plan）；
有监控与年度评估机制；
关键外包必须纳入 Outsourcing Register。

Q224：是否需要制作 ICT Business Continuity & Disaster Recovery Plan（BCP/DRP）？

必须，而且是 ICT + 业务结合文档，需包含：

数据备份（Backup）策略；
备援节点 / 可用区（Multi-AZ / 多机房）；
冷备 / 热备环境；
灾难场景（断电、机房故障、云服务中断、网络被攻击等）；
恢复目标（RTO / RPO）；
定期演练记录。

第三节：虚拟资产托管架构 & 钱包设计

Q225：捷克 CASP 的托管服务，监管最关心哪几个点？

三大核心：

客户资产是否真正隔离（Segregation）；
私钥管理是否安全可靠（Key Management Security）；
一旦出问题，是否有可执行的恢复 / 赔付机制（Recovery & Compensation）。

技术多样性可接受，但“责任不可模糊”。

Q226：热钱包（Hot Wallet）与冷钱包（Cold Wallet）比例有硬性规定吗？

没有固定比例，但业界与监管的“共识”是：

热钱包只保留一定比例的可用余额（如 3–10%）；
冷钱包存储绝大部分长期持有资产；
提供阈值机制：
- 超过某个金额必须从冷钱包补充；
- 冷钱包操作须多重签名、多人员参与。

不建议将大部分资产留在热钱包（尤其在没有保险的情况下）。

Q227：是否必须采用 HSM 或 MPC 技术？

MiCA 没有写死“必须 HSM/MPC”，但监管对以下方案特别友好：

HSM（Hardware Security Module）：
- 硬件安全模块，监管熟悉，传统金融也在用；
MPC（Multi-Party Computation）：
- 新一代托管方案，Fireblocks、Qredo 等广泛使用；
- 可符合多签 + 无单点私钥暴露的理念。

你可以不用 HSM/MPC，但必须证明：

“我的私钥管理机制至少不弱于 HSM/MPC 的安全效果”。

Q228：不同钱包体系（自建 / 第三方托管）对监管有何影响？

两种典型模式：

自建钱包系统（Self-custody Infrastructure）
- 必须详细说明技术架构；
- 提供安全审计报告（Security Audit）；
- 监管会看得非常细。
使用第三方托管（如 Fireblocks、Copper、BitGo 等）
- 必须提供服务协议 + 架构说明；
- 监管会评估该第三方背景与合规性；
- 自身仍需负责风险管理与接口安全。

不管哪种方案：法律责任始终在 CASP 身上。

Q229：是否必须有“Key Ceremony（密钥生成仪式）」？

对于托管型 CASP，非常建议：

在首次生成主私钥 / MPC Key 时：
- 进行正式仪式；
- 视频录制；
- 记录参与人、地点、时间；
- 记录密钥分片的存放地点；
- 签署会议纪要。

监管看到 Key Ceremony Report，一般会增强信心。

Q230：私钥备份应如何设计合规？

通用做法：

使用 Shamir Secret Sharing / MPC 分片；
密钥分片（Shares）分散存放于不同地理位置（不同保险柜 / 金库）；
参与人分工明确、不可单独完成恢复；
有“密钥恢复流程 + 审批机制”。

后台文档中应描述：

备份介质（HSM、硬件钱包、纸质、金属板等）；
物理安全（银行保险箱 / 安全设施）；
恢复步骤（Recovery Runbook）。

Q231：是否可以让用户“自托管（Non-custodial Wallet）」以降低托管责任？

可以，但需要确保：

平台确实无法接触私钥；
所有签名操作由用户本地设备完成；
平台不存储助记词 / 私钥 / 种子；
仅提供交易路由与订单撮合功能。

此模式下，CASP 托管责任降低，但 AML 责任仍然存在（需核查资金来源）。

Q232：是否可以同时提供托管钱包（Custodial）和非托管钱包（Non-Custodial）？

可以，但必须：

产品界面清晰区分两种模式；
合同与风险披露中解释：
- 谁对资产负责；
- 出现问题谁负责赔偿；
IT 架构两套分离；
AML 视角仍需对资金流进行监控。

监管最怕的是：客户以为是自托管，实际上平台也能动钱。

Q233：提币审批流程如何设计才比较“监管友好”？

建议多层机制：

额度限制：
- 单笔 / 单日 / 单周限额；
- 高额需人工复核 + 二次认证。
智能风控：
- 对高风险地址 / 新地址设额外审核；
- 利用链上分析结果辅助。
多重签名 / MPC 阈值：
- 后台由多名员工批准；
- 防止单人滥用权限。
延迟提币（Withdrawal Delay）：
- 某些异常提币延后执行，便于 AML 审查。

Q234：是否需要针对“托管资产规模”设定内部风险阈值？

建议设定：

当托管资产规模达到某一数值：
- 触发额外审查（例如增加冷钱包比例）；
- 更新资本金评估；
- 更新保险额度（如购买 Crime / Cyber Insurance）。

监管期望你能展示：

“资产越多，防护越强，而不是仍旧按小平台的配制在跑”。

第四节：事故响应、日志、审计与通知机制

Q235：ICT / 钱包相关重大事件发生时，必须有哪些应急流程？

典型 Incident Response 包括：

识别事件（Detection）
评估影响（Impact Assessment）
技术隔离（Containment）
修复与恢复（Eradication & Recovery）
内部与外部沟通（Comms）
向监管/FAU 报告（Regulatory Reporting）
事后总结与改进（Post-Incident Review）

MiCA & DORA 下，事件响应必须制度化。

Q236：何种事件需要向监管机构 / FAU 报告？

至少包括：

大规模资产损失或被盗；
客户数据泄露；
系统长时间中断（影响客户交易）；
重大 ICT 安全漏洞；
涉嫌恐怖融资、制裁规避的交易；
大批量 STR 相关行为。

报告对象可能包括：

CNB（CASP 监管）；
FAU（AML 金融分析办公室）；
数据保护机构（GDPR 相关事件）。

Q237：ICT 与托管系统是否必须记录完整日志（Audit Logs）？

是的，日志是“监管救命绳”。

日志应包括：

登录记录；
配置变更；
管理后台操作；
提币审批记录；
用户关键操作；
风控与 AML 告警处理记录。

日志留存期：一般至少 5～10 年（与 AML 及财务记录要求对齐）。

Q238：是否需要“第三方安全审计（Code Review / Smart Contract Audit）」？

如涉及：

自建智能合约（DeFi / Staking / RWA 合约）；
自建钱包管理逻辑；
自行实现关键加密模块。

建议：

提供第三方安全审计报告；
说明审计机构资质；
说明已修复的漏洞列表。

监管不会审代码，但会看你有没有“找人看过”。

Q239：是否需要对 ICT / 托管体系进行“年度内部审计（Internal Audit）」？

虽然 MiCA 对 CASP 不一定强制要求传统“内部审计部门”，
但最佳实践是：

每年至少一次对 ICT 与托管进行内部评估；
可以由外部专家协助完成（Outsourced Internal Audit）；
将结果报告给董事会与 Risk Committee。

对于交易平台 / 托管量大的 CASP，这是监管强烈鼓励行为。

Q240：对客户，应如何披露 ICT 与托管相关的风险与保护措施？

建议在以下文档中进行统一披露：

Terms & Conditions（服务条款）；
Risk Disclosure Statement（风险披露声明）；
Custody Terms（托管条款）；
Privacy Policy（隐私政策）。

披露要点包括：

平台如何托管资产（Hot/Cold/MPC/HSM）；
发生黑客攻击时，平台责任边界；
是否有保险；
用户自身安全责任（设备安全、2FA、钓鱼风险）；
出问题后的沟通机制与赔偿规则（若有）。

透明的风险披露 + 清晰的托管条款
= 监管信任 + 客户信任的基础。

第八章｜捷克 Crypto Tax + 会计与税务处理专章（Q241～Q270）

仁港永胜唐生温馨提示：本章为监管与实务合规视角的 Crypto 税务与会计处理 FAQ，仅供结构参考，不构成当地税务 / 会计法律意见，实际申报仍需由捷克持牌税务顾问 / 会计师最终确认。

第一节：总体税务框架 & 监管视角

Q241：在捷克设立 CASP 公司，适用的主要税种有哪些？

对一个在捷克落地的 CASP 主体而言，常见税种主要包括：

企业所得税（Corporate Income Tax, CIT）
增值税（VAT） —— 视业务性质与收费类型而定
预提税（Withholding Tax, WHT） —— 向海外股东分红等情况
工资相关税费 —— 员工工资的个税 & 社保
加密资产相关的资本收益或营业收益税处理 —— 视 Crypto 资产属性与业务模式而定

MiCA 处理“牌照与监管”，而实际纳税义务仍以捷克本地税法为准。

Q242：捷克公司从事加密资产服务，收入如何分类？

收入通常分为：

手续费收入（Fees & Commissions）
- 交易手续费（Maker/Taker）
- 托管服务费（Custody Fee）
- 兑换服务费（Spread / Commission）
技术服务 / 白标服务收入（Tech / White-Label Service）
- 提供 API、撮合引擎、钱包托管技术
加密资产相关收益
- 自营持仓收益（Trading Gain/Loss）
- Staking / Lending/ Yield 相关收益（视结构可能被视为利息/服务收入）

所有以上收入，实务中大多计入 “营业收入”，而不是“资本利得税”单独税目。

Q243：公司持有的 Crypto（自营仓位）产生的浮盈/浮亏如何纳税？

一般以会计处理为基础：

若采用 成本法 + 减值测试：
- 仅当资产处置 / 减值时才确认损益；
若采用 公允价值模式（Fair Value）：
- 会按期计入重估损益（取决于会计政策与审计师认可）。

税务上 通常以“已实现收益（Realised Gain/Loss）”为纳税依据：

即卖出时，卖出价 – 税务成本价 = 应税收益 / 可扣除损失。

Q244：Crypto 收入是否可以按“资本利得（Capital Gain）」而非正常营业收入计？

对于**公司主体（CASP 法人）**而言：

监管与税务机关更倾向把 Crypto 相关利润视为 “正常企业应税所得”；
不太会像个人那样单独享受“资本利得”税率；
不同类型收入（手续费 / 自营交易）可能在会计科目上区分，但最终统合到企业所得税口径。

简化理解：

CASP 是经营机构，Crypto 收入本质上是营运利润。

Q245：客户支付的交易手续费是否需要缴纳捷克增值税（VAT）？

这要看服务类型的法律定性：

若被定性为“金融服务（例如兑换货币、支付服务）”，部分可能享受 VAT 免税；
若为纯技术服务 / IT 服务，则多半需要计入 VAT；
跨境 B2B 服务可适用「反向计税（Reverse Charge）」规则。

因此，交易手续费是否含 VAT、如何开票，需要：

由当地税务顾问结合具体业务模式作出判断；
很多 Crypto 交易所会将交易手续费定性为“金融服务”，争取 VAT 免税处理；
但也要考虑对进项税抵扣的影响。

Q246：客户托管费（Custody Fee）是否需要缴 VAT？

托管费可能有两种定性路径：

金融服务型托管（类似证券托管）
- 可能适用 VAT 免税（exempt with no credit）；
纯 IT 托管 / 数据托管服务
- 需缴 VAT，但可抵扣进项税。

定性的关键：

是否涉及资金 / 资产的法律权属与金融监管；
托管责任是否类似金融机构。

MiCA 下的托管 CASP 更可能被视为“金融服务型托管”。

Q247：Staking、Lending、收益型产品的收入如何纳税？

对 CASP 公司而言：

服务费部分 → 计入营业收入，应按企业所得税缴税；
自营持有的 Staking 收益 → 可视作“其他营业收益 / 利息性质收益”，亦需纳入企业所得税口径；

监管关注点：

是否构成“准存款 / 类银行业务”；
若是借贷平台或收益保证型产品，可能触及额外牌照要求。

税务上关注：

这些收益不太可能被视为“税务免税收入”。

Q248：Crypto“空投（Airdrop）」或“项目激励 Token」如何计税？

对 CASP 公司而言，常见情况：

若 Airdrop 是对公司提供服务的对价（例如做市奖励 / 流动性激励）：
- 应认定为营业收入，按公允价值计入；
若属“无对价赠与”，则要看是否有后续处置：
- 在处置时确认收入与税务成本差额。

审计师往往要求：

对重要 Airdrop 和奖励 Token 做单独披露。

Q249：客户层面的 Crypto 税务处理，CASP 是否有义务“代扣代缴”？

目前大多数欧盟辖区（包括捷克）：

对 个人客户 Crypto 交易所得：
- 由客户自行申报个人所得税或资本利得税；
- CASP 一般不负“代扣代缴”义务。
但 CASP 可能被要求：
- 配合提供交易报表；
- 在未来欧盟 DAC8 框架下，对税务机关进行数据报送。

即：

CASP 不是客户的“税务代理人”，但必须做好“税务信息报告”准备。

Q250：捷克 CASP 是否会受到 DAC8 / CRS 等信息申报框架影响？

是的，欧盟正在通过 DAC8 规范 Crypto 资产税务信息自动交换。
预期影响：

CASP 将被纳入“报告义务主体”；
需向税务机关报送客户 Crypto 资产相关信息；
涉及：交易量、收益、持仓等维度；
部分跨境信息可能通过欧盟内部交换、与 CRS 接轨。

建议：

在设计 IT 与报表系统时，提前预留 “Tax Reporting Module”。

第二节：会计处理与报表呈现

Q251：Crypto 在会计上应该作为“金融工具”还是“无形资产”？

目前欧洲实务中较为典型的处理方式有两种：

无形资产（Intangible Asset）
- 适用于长期持有、非用于短期交易目的；
- 按成本计量 + 减值测试；
存货 / 资产持有待售（Inventories）
- 若 Crypto 作为“交易商品”频繁买卖；
- 可按存货或公允价值计量。

具体采用哪种模式：

取决于商业模式（HODL、做市、自营交易等）；
需由会计师和审计师根据 IFRS / Czech GAAP 统一确定。

Q252：如何在报表中区分“公司自有 Crypto”和“客户 Crypto”？

原则：

客户 Crypto 不属于公司资产，只是托管。

报表呈现方式：

公司自有 Crypto → 计入资产负债表（Intangible / Inventory 等）；
客户 Crypto → 不计入资产负债表，仅在附注中披露：
- 总规模
- 托管种类
- 风险说明

这有助于说明：
“公司不会动用客户资产，也不会将其作为自有资产支撑业务风险。”

Q253：客户资产是否需要在报表中设置“负债对应科目”？

多数做法是：

若结构为“Trust / Fiduciary 形式”托管：
- 可能以 Off-Balance 表达；
如果法律结构要求公司对客户资产承担一定偿付义务：
- 则可设置“客户资产对应负债科目”。

最佳实践：

由法律意见 + 会计意见共同决定；
在附注中对客户资产的法律属性做清晰披露。

Q254：如何处理加密资产价格波动对报表的影响？

两种典型路径：

成本法 + 减值测试：
- 下跌：计提减值；
- 上涨：不确认收益，直到出售；
公允价值变动计入当期损益：
- 每期按照市价重估；
- 价格上涨、下跌都直接影响当期 P&L。

监管最关注的是：

是否因 Crypto 波动导致资本充足性恶化。

Q255：加密资产计价应使用什么汇率 / 报价源？

应建立正式的“定价政策（Pricing Policy）”，包括：

使用哪个价格源（例如：Binance、Coinbase、第三方指数）；
使用哪个时间点价（收盘价 / 日均价）；
多数交易所价格时应采用“加权平均价”；
对流动性较差 Token 应特别说明定价方法。

该政策应获得审计师认可。

Q256：Crypto 与法币兑换形成的差价如何入账？

例如：

客户用 EUR 购买 BTC；
公司在流动性池或上游交易所买入 BTC → 可能有价差。

差价计入：

“交易收入 / Spread 收入”；或
“外汇 / 交易收益”。

建议明确区分：

纯服务费（Fee）；
价差收入（Spread）；
自营交易收益。

Q257：平台代收代付的“第三方资金”如何反映在财务报表中？

如果 CASP 只是“代收代付”而非真正持有资金：

应在会计政策中说明其“代理性质”；
可使用“过渡科目 / Clearing Account”；
避免将不属于公司风险敞口的资金计入自有资产。

否则会有监管误解为“吸收存款 / 類銀行”。

Q258：是否需要为 Crypto 相关业务设置单独的管理账（Management Accounts）？

强烈建议设立多维管理账：

按产品线拆分：交易、托管、OTC、Staking；
按币种拆分：BTC、ETH、Stablecoins；
按客户类型拆分：零售 / 机构。

管理账可用于：

内部风险监控；
资本金评估；
向监管报告时，各条线风险更清淅。

Q259：是否需要为 Crypto 交易记录做“链上 + 账面”的对账？

必须。

对账要素包括：

后台数据库余额 vs 区块链余额；
冷热钱包余额合计 vs 客户+公司资产总额；
发现差异要立即调查并更正。

“链上对账”是 Crypto 审计的基本要求，
也是 CNB 容易问到的实务问题。

Q260：若平台提供杠杆、衍生品等业务，对会计与税务有何额外影响？

额外复杂点：

盈亏确认时点变化；
衍生品可能被视作“金融工具”，需按 IFRS 9 处理（FVPL 等）；
税务上可能需要区分“利息收入 / 手续费收入 / 交易收益”；
资本金要求通常会显著提升。

建议：

若涉及杠杆/衍生品，必须提前安排“金融工具会计 + 税务顾问”参与结构设计。

第三节：税务合规与客户沟通

Q261：捷克 CASP 是否需要向客户提供“年度交易报告（Tax Report）」？

目前不是硬性监管义务，但属于最佳实践：

提供年度交易汇总报表：
- 买入 / 卖出 / 手续费 / 收益；
客户可用来向本国税务机关申报个税 / 资本利得税。

未来 DAC8 落地后，这几乎会变成“事实标准”。

Q262：是否建议在 Terms & Conditions 中加入“税务免责声明」？

强烈建议，内容包括：

平台不提供税务建议；
客户应自行向税务顾问咨询；
平台可在合理要求范围内提供交易数据支持；
若税法变化，平台有权调整报表格式与数据范围。

避免被客户误认为是“税务顾问”。

Q263：平台是否可以主动为客户提供“税务计算服务」？

可以，但要注意：

建议通过独立第三方（Tax Tech 公司 / 税务顾问）提供；
平台需强调“不构成官方税务意见”；
服务条款中须明确责任边界。

否则，一旦客户因报税出错被罚，容易牵连平台。

Q264：是否需要制定《税务合规政策（Tax Compliance Policy）」？

对于中大型 CASP，建议制定，内容包括：

公司税务申报流程；
税务风险评估框架；
Crypto 的计税基础与政策选择；
与税务顾问的合作机制；
向税务机关的沟通与解释流程。

这在 RFI 阶段，如果 CNB 对“税务可持续性”有疑问，是非常有用的辅助文件。

Q265：税务筹划在监管眼中是“加分项”还是“风险点」？

取决于方式：

合法、透明的税务筹划（选择 EU 内合理辖区、结构清晰） → 属于正常商业决策；
利用复杂离岸架构 + 高风险辖区避税 → 监管会认为增加 AML & 监管风险。

MiCA 时代：

监管对“税务透明度”的要求越来越高，尽量避免“过度激进的避税设计”。

Q266：集团架构中若有 BVI / Cayman / Seychelles 等离岸公司，会不会影响捷克 CASP 审批？

不会“一刀切”拒绝，但必须做好：

UBO 穿透（直至自然人）；
解释离岸结构商业合理性（融资、股权安排等）；
提供额外 SOF/SOW 证明；
解释税务居民地安排与 CRS / DAC 的合规性。

越透明、越容易获批。

Q267：捷克 CASP 是否可以利用“欧盟内其他国家税收协定」减少预提税？

通常可以：

若股东是其他 EU 公司，
- 可以适用欧盟「母子公司指令」或双边税收协定；
- 享受减少或免除股息预提税的待遇（视具体条约）。

这属于 Tax Treaty Planning，应由税务顾问具体设计。

Q268：Crypto 相关的税法未来是否存在较大不确定性？

是的，监管普遍承认：

Crypto 发展速度 > 税法更新速度；
很多地方适用“类比原则”（例如类证券、类外汇、类无形资产）；
未来几年内，欧盟及成员国很可能继续就 Crypto 课税进行细化。

因此，对于 CASP：

税务政策与会计政策应具有可调整性；
不建议用“过度极端操作”去赌政策空白。

Q269：在申请捷克 CASP 时，是否需要提交“税务顾问参与证明」？

不是强制要求，但如果：

在 BP 中明确提及：
- 公司已委托捷克税务顾问；
- 已就 Crypto 定价、收入分类、VAT 处理取得专业意见；

会显著提升监管对“持续合规能力”的信心。

Q270：如果未来税法或监管政策发生变化，CASP 需要做什么应对？

建议预设“合规升级机制”：

设立 Tax & Regulatory Watch Function
- 定期跟踪欧盟与捷克 Crypto 税法更新；
维护动态合规矩阵
- 税务要求
- 报表要求
- DAC8 / CRS 报告要求
在条款中写明
- 当法律变更时，公司有权修改费用结构、报告格式、服务条款。

这样既保持合规性，又避免与客户的合约争议。

第九章｜监管沟通、现场检查与持续义务（Q271～Q285）

Q271：捷克 CASP 获牌后，与监管机构（CNB）的日常沟通频率大概是怎样的？

一般来说，获牌后与 CNB 的互动主要体现在：

日常书面沟通
- 对监管问询函的回复
- 对规则更新的反馈
定期报告
- 年度报告 / 财报 / 审计报告
- 可能的季度 / 半年度监管报表
不定期事项通报
- 重大变更（股权、董事、业务范围等）
- 重大 ICT / 安全事件
- 重大 AML 相关事件（配合 FAU）

频率通常是“平时较少打扰，但有事必须第一时间报告”。

Q272：CNB 会不会对 CASP 进行“现场检查（On-site Inspection）」？

会，尤其在以下情形更常见：

首批获牌后 1～2 年内的“后评估检查”；
业务规模较大、托管资产较多的平台；
曾出现严重事故或客户投诉较多的机构；
AML 风险较高、涉及高风险国家较多的机构。

检查重点不止是文件，还包括：

实地办公场所
系统演示
AML / KYC 操作流程
钱包托管与私钥管理
内部控制与实际运行是否一致

Q273：现场检查前，监管通常会提前通知吗？会给到“检查范围”？

一般会提前通知：

拟定检查日期 / 周期；
提供一份“检查清单（Inspection Scope）」或至少列明重点领域；
要求预先提交部分文档（Policies、报表、日志样本等）。

但对于某些特殊 AML / STR 相关事项，
也不排除会进行突击式现场检查。

Q274：现场检查时，管理层和 AML Officer 必须到场吗？

必须。重点对象包括：

董事会成员 / Managing Director；
AML Officer / MLRO；
Compliance Officer；
Risk Officer；
ICT / 安全负责人；
如涉及托管：Custody / Wallet 负责人。

监管希望看到的不是“律师代表”，而是真正控制和运营公司的人。

Q275：CNB 在现场检查中，最常问的核心问题有哪些？

典型问题包括（但不限于）：

你们的商业模式与目标客群？
AML / KYC 如何实际执行？举具体例子。
高风险客户与高风险国家如何处理？
交易监控系统如何设定阈值与规则？
发生过哪些可疑交易？你们如何处理？
最近一年有没有重大 ICT 事件？如何应对？
钱包托管架构如何设计？私钥管理流程？
你们如何确保资本金持续满足监管要求？

基本逻辑：把申请时写在纸上的东西，逐条验证是否真的在执行。

Q276：监管对“变更事项”的事前/事后报告要求有哪些？

通常需要报告的变更包括：

股东结构变化（特别是 UBO 变更）
董事 / 高管变更
AML Officer / Compliance Officer / Risk Officer / ICT Officer 变更
业务范围扩展 / 新增产品线（例如新增 Staking、衍生品等）
重大外包安排变化（例如更换托管服务商、云服务商等）

部分变更需要事先审批，部分变更可以事后通报，
建议由合规顾问整理一份“变更事件矩阵”，区分清楚。

Q277：如果公司想增加新业务（比如从单纯兑换增加托管），需要重新申请牌照吗？

一般不能“默默上线”，需要：

向 CNB 提交业务变更说明（Business Change Application）；
提供新业务的风险评估、流程、政策、系统说明；
若涉及新类别的 CASP 服务，对应的资本金要求也可能变更；
监管批准后，才能正式对公众推出。

MiCA 精神：业务变更 = 风险变更 = 必须重新审查。

Q278：如果公司计划进入其他 EU/EEA 国家展业（护照机制），需要向 CNB 报告吗？

需要。一般流程为：

向 CNB 提交“护照通知（Passporting Notification）」：
- 拟进入国家列表
- 提供业务概要
- 目标客户类型等
CNB 审阅后，将信息转发到目标成员国监管机构；
完成护照程序后，方可在相关国家以“MiCA CASP 身份”开展业务。

护照本身不是自动生成的，必须经过明确通知程序。

Q279：CNB 会不会对“营销与广告内容”做监管？

会，对以下方面特别敏感：

是否存在“保本、无风险”之类误导性表达；
是否对收益做不现实的承诺；
是否正确披露风险（尤其是衍生品 / 杠杆 / 复杂产品）；
是否针对不适合的客群营销（例如大众零售推高风险结构性产品）。

建议制定 Marketing & Communication Policy，
把合规过滤纳入广告投放流程。

Q280：获牌后没有及时开展业务，会不会有牌照被收回的风险？

会。MiCA 与各国本地法通常会规定：

如授权后在一定期限内未开始业务，监管可以：
- 撤销授权；或
- 限制或暂停权限
如长时间处于“休眠状态”，也可能被视为资源浪费或监管套利。

通常建议：

在获牌后 6～12 个月内，至少有 实质性运营迹象（少量客户、系统上线、团队运作）。

Q281：持续合规成本主要有哪些？

典型持续成本包括：

人员成本：AML、合规、风控、ICT、安全等关键岗位薪酬；
外部顾问：法律、合规、税务、技术审计等；
系统成本：KYC、Chainalysis、监控系统、云计算、Fireblocks 等；
年度审计费用；
监管报告编制成本；
员工培训与内部审计预算；
保险费用（Cyber / Crime / D&O 等）。

所以“获牌后持续运营成本”往往远大于“一次性申请成本”。

Q282：如果公司出现经营困难甚至亏损，会影响牌照吗？

视情况而定：

短期亏损但资本金仍充足 → 一般问题不大；
长期亏损且净资产接近或低于监管资本 →
- 监管可能要求增资或限制业务；
- 若拒不增资或风险过高，可能走向“自愿退出或被动撤牌”。

最重要的是：

持续向监管证明“有能力保护客户资产 + 维持金融稳定”。

Q283：CASP 是否可以主动申请“自愿退牌（Voluntary Withdrawal）」？

可以。流程包括：

停止接收新客户、新业务；
通知既有客户，安排资产赎回或迁移；
提交清算或关闭计划给 CNB；
待 CNB 同意并确认风险已解除后，完成退牌。

建议在设计商业计划时保留“有序退出机制（Orderly Wind-Down Plan）」。

Q284：若公司被处罚（罚款或整改），对品牌与未来合规会有多大影响？

影响层面：

监管记录：
- 未来变更业务或护照申请时，监管会更谨慎；
客户信任：
- 尤其涉及 AML、客户资产管理问题时，客户信心受损更大；
银行合作：
- 对接银行、支付机构时，对方会调取监管记录作为 KYC 一部分。

因此，与其“事后补救”，不如前置合规设计做足。

Q285：如何构建一个长期、稳定、正向的监管关系？

建议遵循三条原则：

透明：
- 不隐瞒问题，必要时“早报告、早沟通”；
专业：
- 所有对外文件、回复信函、会议纪要都体现专业性与严谨性；
一致性：
- 内部实际运行、外部披露与对监管表态三者保持一致。

很多成功案例表明：

能与监管形成“长期可信关系”的机构，往往能在政策调整中获得更多空间与信任。

第十章｜项目实战建议、常见错误与仁港永胜服务模式（Q286～Q300）

Q286：从实务经验看，捷克 CASP 申请中最常见的失败原因是什么？

典型“雷区”包括：

业务模式模糊且文档前后矛盾；
治理结构不符合欧盟标准（单董事、无本地人员）；
AML / KYC 体系只是“样板文件”，无法落地；
ICT 与托管技术说明过于空泛；
财务预测严重脱离现实；
股东 / 资金来源不透明；
与监管沟通方式不专业或拖延。

简单一句话：

“写得好看但做不到” 是最致命的问题。

Q287：如果现在才启动捷克 CASP 项目，合理的时间预期应该是多少？

在不考虑极端补件的情况下，一般包含：

前期规划与结构设计：2～3 个月
文档准备与内部协调：3～4 个月
正式提交至“第一次完整受理”：1～2 个月
监管审查 + RFI 往返：6～12 个月（有时更久）

总体而言，从“立项”到“获牌”：

12～18 个月是相对稳健的预期区间，
做得好、团队配合度高可以相对压缩，
但不太建议向股东承诺“6 个月搞定”。

Q288：对于中国 / 亚洲背景股东，捷克 CASP 项目有哪些额外注意事项？

重点在于两块：

UBO 与资金来源透明度
- 提前准备 SOF / SOW 文档（税单、分红凭证、上市公司信息等）；
- 避免使用过于复杂的多层离岸结构；
团队本地化与欧盟实质（Substance）
- 至少在 EU 配置核心岗位成员（AML / Compliance / Risk / ICT）；
- 显示真正“Mind & Management 在欧盟”，而非纯“牌照外包”。

Q289：项目组内部如何分工，才能高效推进 CASP 申请？

建议的“项目小组”结构：

项目负责人（Project Lead）：统筹对接股东、内部团队与顾问；
业务负责人（Business Lead）：输出商业模式、产品逻辑；
合规负责人（Compliance Lead）：配合顾问打磨政策与流程；
技术负责人（Tech Lead）：提供系统架构、接口、测试；
财务负责人（Finance Lead）：负责 BP、预算、资本金模型；
外部顾问（Legal/Compliance/Tax/Tech Security）：提供监管口径与文档模板。

仁港永胜通常会担当：架构顾问 + 文档牵头 + 监管沟通翻译器 的角色。

Q290：项目早期最应该优先确定的“三件事”是什么？

从实战来看，最关键的是：

业务范围与牌照类别选型
- 只做兑换？做托管？做平台？做自营？
- 是否涉及 Staking、借贷、衍生品？
股权与资本结构
- 谁是控股股东？UBO 是谁？资金从哪来？
- 是否未来引入 VC / 投资人？
落地国家与护照策略
- 先捷克？还是奥地利/马耳他/德国？
- 未来护照到哪些目标市场？

这“三件事”确定清楚后，其他都是执行问题。

Q291：是否有必要同时布局多个国家的 MiCA CASP 项目？

取决于：

预算与团队承载能力；
目标客户分布；
对监管多样性与政策风险的考量。

常见两种策略：

单国深耕型：
- 先拿一个国家 CASP，再通过护照布局全欧；
双国互补型：
- 例如捷克 + 马耳他 / 奥地利 / 德国，
- 在业务结构、税务、监管关系等方面形成互补。

不建议在资源有限的情况下“铺太多摊子”。

Q292：对于已有牌照（如 EMI / PI / 投资服务牌照）的机构，申请 CASP 有哪些优势？

优势主要体现在：

既有的治理与合规框架可复用；
AML / KYC 体系成熟；
已有银行合作关系；
审计与报告体系已运作多年；
对金融监管沟通有经验。

监管往往更愿意把 CASP 授权给“已有监管 track-record 的机构”。

Q293：反过来，如果先拿 CASP，未来再申请其他金融牌照（如 EMI），有帮助吗？

有一定帮助，但不如“传统金融牌照 → CASP”的效果大。
作用体现在：

显示项目团队具备合规意识；
证明已通过一次本地监管审查；
可以展示真实运营记录与客户数据。

但每类牌照的审查标准仍然独立，不能简单视为“互认”。

Q294：申请过程中，是否应该“过度承诺”未来业务规模和技术能力？

强烈不建议。

过度宏大 → RFI 问题会成倍增加；
技术能力夸大 → 现场检查时无法证明；
业务规模过大而资本金不足 → 被质疑风险管理能力。

建议采用“适度保守但逻辑合理”的业务预期与能力描述，
把重点放在：合规可控、稳健运营，而不是故事讲得多大。

Q295：项目方自己写申请材料好，还是交给顾问好？

最佳实践是“混合模式”：

业务细节 & 产品逻辑 → 项目方自己提供、最了解；
监管口径 & 结构设计 → 由专业顾问把关；
文档初稿可由顾问提供模板，由项目组填入真实运营内容。

如果完全自己写、完全不懂监管语言，
往往会出现：写很多，但关键点一个没踩到。

若完全丢给顾问不参与，又会变成：纸面方案好看，但项目方自己也不理解。

Q296：仁港永胜在 MiCA / CASP 项目中，一般提供哪些“全套服务模块”？

可拆分为几个典型模块（可选打包）：

前期结构咨询
- 业务范围与牌照类别选型
- 落地国家对比（捷克/奥地利/马耳他/德国等）
- 股权与资本结构建议
文档与制度编制
- BP / Financial Projection
- AML / CFT / KYC 全套政策
- ICT & Custody Policy / DORA Framework
- Risk Management & Governance 文档
申请过程陪同
- Forms 填写
- RFI 问答草拟
- 与监管沟通策略设计
获牌后持续合规支持
- 年度审查准备
- 政策更新
- 新业务扩展合规评估

根据项目需要可定制组合。

Q297：如果项目中途调整，例如更换 UBO 或改变业务模式，仁港永胜如何协助？

典型协助方式包括：

进行“ Change Impact Assessment”（变更影响评估）；
更新相关文档（股东结构说明、风险评估、业务模式描述等）；
准备“变更说明信（Change Notification Letter）」；
协助与 CNB 沟通变更原因与风险控制安排；
必要时帮助重新调整资本金与资源配置。

目标是：

在“合法合规 + 尽量少额外监管疑问”的前提下完成变更。

Q298：项目时间紧、股东又催得急，应该如何合理向投资人解释时间与风险？

推荐沟通框架：

监管节奏不是完全可控变量
- 有监管队列，有内部决策流程；
时间换空间
- 时间用于减少失败风险、降低补件次数、提升质量；
一次过 vs 多次重来
- 过于仓促的申请，可能导致直接被拒，反而拖得更久；
提供里程碑计划
- 通过 Gantt 图与里程碑节点，让投资人看到“过程与进度”，而非“黑盒子”。

仁港永胜可帮你设计一版“对内对股东用的路演版时间表”。

Q299：对于还在犹豫“是否一定要走 MiCA / CASP 正规牌照”的团队，应该如何做决策？

可以自问三个问题：

是否真的面向欧盟/欧洲主流市场？
- 如果只是做小规模海外用户，可能还没到必须 MiCA 的阶段；
是否希望长期做合规品牌资产？
- 真正要做机构盘 / 银行 / 大型机构客户，MiCA 几乎是“门票级要求”；
是否有能力承担持续合规成本？
- 牌照意味着长期责任，而不是一次性工程。

如果上述三问中，有两项以上回答“是”，
那基本可以认定：走 MiCA / CASP 是战略必然，而非选装件。

Q300：如果我们决定正式启动“捷克 CASP 申请”，跟仁港永胜合作的第一步通常是什么？

通常第一步是一个 “项目诊断 + 结构规划 Call”，主要做三件事：

快速梳理你现有状况
- 股东结构 / 资金来源
- 现有业务 / 技术基础
- 目标市场与产品路线
评估适配度与可行性
- 捷克是否最合适？
- 是否有更契合你场景的国家（比如奥地利、马耳他等）？
- 是否需要先做过渡方案（例如轻量化牌照 / 其他司法辖区）？
给出一个“可落地的路线图 + 预算概览”
- 核心里程碑
- 预估时序
- 必要的人力与成本区间

如果你不想在一开始就陷入大堆文书，可以先从这一步开始，
把方向和路径选对，再谈执行细节。

第十一章｜虚拟资产托管技术（Custody Tech）专章（Q301～Q330）

说明：本章适用于 捷克 MiCA-CASP 托管类业务，由仁港永胜唐生提供讲解。

第一节：总体架构与监管关注点

Q301：监管在审核 CASP 托管技术方案时，核心到底看哪几件事？

通常聚焦四个关键点：

资产安全性
- 是否有明确的冷/热钱包分层；
- 是否采用 MPC/HSM 等机构级安全方案；
- 私钥是否存在单点失控风险。
客户资产隔离性
- 客户资产是否与公司自有资产完全隔离；
- 是否存在挪用、质押、重复使用客户资产的可能。
可审计与可追溯性
- 每一笔链上交易是否能回溯到系统操作与审批记录；
- 是否有完整日志与报表支持监管/审计检查。
事件响应与恢复能力
- 遇到黑客、系统故障、人为错误时如何应急；
- 有无灾难恢复（DR）与业务连续性计划（BCP）。

一句话：

“你如何具体做到——客户的币不会莫名其妙丢，也不会被你悄悄挪用。”

Q302：设计 Custody 体系时，为什么一定要把“技术架构”和“法律条款”一起看？

因为：

技术上可能是 Omnibus 地址（混合托管），
法律条款却写成“每个客户资产完全独立隔离”，

一旦出事：

在法律上难以界定“哪一笔币属于哪位客户”；
在清算与赔偿顺序上容易产生纠纷；
监管会认为“技术实现与法律承诺不一致”。

正确的做法是：

先定好法律结构（信托/委托/混合），再设计与之匹配的钱包结构与账务规则。

Q303：一个合规的 CASP 托管体系，最低需要哪些技术模块？

最少应具备：

钱包管理模块（Wallet Management）
- 冷/热/温钱包管理；
- 地址生成与分配。
密钥管理模块（Key Management / MPC / HSM）
- 私钥生成、分片、存储、使用、轮换、销毁。
账务与总账模块（Ledger System）
- 记录每个客户和每个币种的余额变化；
- 与链上余额对账。
风控与审批模块（Risk & Approval）
- 提币、异常交易审批；
- 额度控制与多级授权。
日志与审计模块（Logging & Audit Trail）
- 记录所有敏感操作与交易；
- 支持监管与审计查询。
监控与报警模块（Monitoring & Alerting）
- 监控钱包余额、异常流量、风险地址；
- 实时告警。

第二节：私钥全生命周期管理（Key Lifecycle）

Q304：什么叫“私钥全生命周期管理（Key Lifecycle Management）”？

指的是对私钥从“出生”到“死亡”的全过程控制，典型包括：

生成（Generation）
分发（Distribution）
使用（Usage / Signing）
备份（Backup）
轮换（Rotation）
存储（Storage）
销毁（Destruction / Decommission）

监管希望看到的是：

“每一步都有明确规则、负责人员、审计记录，而不是随便谁拿着一只硬件钱包就能转钱。”

Q305：在私钥生成阶段，有哪些“必做”的合规动作？

建议至少做到：

在受控环境（安全机房/离线室）生成密钥；
使用通过验证的随机数发生器（CSPRNG）；
过程有书面 SOP、参与人员名单、视频记录；
由技术+合规+风险多方在场见证（Key Ceremony）；
生成后即刻记录密钥元数据（用途、创建时间、责任人）；
不允许在普通开发机、个人电脑上生成正式托管密钥。

这些材料在监管补件和审计中都非常重要。

Q306：采用 MPC 方案后，还需要关心“单一私钥泄露”问题吗？

MPC 的优势是：

完整私钥从未在单一节点形成或存储；
只有密钥分片（Shares）分布在多个节点；
单个节点被攻破并不足以完成签名。

但仍需关注：

所有 MPC 节点部署位置与运维权限；
是否存在“单一实体控制多数节点”的情况；
节点之间通信安全（TLS、认证、反重放攻击）；
是否存在后门可以导出完整密钥。

监管会问的不是“你是否用了 MPC”，
而是“你的 MPC 架构是否真的避免了单点失控”。

Q307：如何设计冷钱包（Cold Wallet）层级？

一般做法：

冷钱包作为“长期仓库”，存放大部分客户资产；
完全离线（Air-gapped），使用硬件设备或 HSM；
操作频率低（例如每周/每月进行一次补热钱包或资产重组）。

关键是：

冷钱包操作必须采用多人在场、多级审批；
全程录像 + 操作日志；
设备存放于实体金库/保险柜中，双重钥匙管理；
对冷钱包中总金额设定阈值与报告机制。

Q308：热钱包（Hot Wallet）的安全目标是什么？

热钱包的目标是：在保证安全的前提下提供出入金效率，因此：

托管总资产中只有一部分在热钱包（例如 5～10%）；
签名流程使用 MPC/HSM，避免单一服务器泄露；
对单笔提币、日提币总额设置限额；
异常行为（大额突发提币、频繁小额提现）要有风控规则；
热钱包环境加强系统加固与安全监控。

监管接受“热钱包无法做到绝对零风险”，
但要求你通过结构设计把 安全事件的最大损失控制在可承受范围内。

Q309：冷/热钱包之间的资金调拨，有必要做成“类内控审批流程”吗？

必须要做。典型流程：

系统检测热钱包余额低于某阈值（或运营人员发起补仓需求）；
生成补仓计划（金额、币种、目标地址）；
多人审批（至少运营+风控/合规双签）；
冷钱包操作团队按 SOP 在离线环境完成签名；
交易广播至链上，并记录 TXID；
对账确认资金已到账热钱包。

整个过程要形成“可复核的审批链”，
否则冷钱包就变成“谁心情好就可以转”。

Q310：私钥备份如何做，既能防止单点故障，又不把风险放大？

建议采用“三个原则”：

有限份数：
- 备份数量足够容错但不过度（例如 2～3 份），
- 避免分发过多拷贝导致泄露面放大。
物理分散：
- 不同备份保存在不同地点（城市/金库/机构）；
- 同时避免“一个灾害事件毁掉所有备份”。
访问受控：
- 访问备份需要多重身份认证与事先审批；
- 有访问日志与录像记录；
- 定期核查备份完整性与可恢复性。

对于 MPC 分片备份，还要说明分片组合阈值与恢复流程。

Q311：是否有必要为核心密钥设置“定期轮换（Key Rotation）」？

建议对 “系统级/中间级密钥” 进行定期轮换，例如：

用于 API 签名、内部服务间通信的密钥；
用于派生成千上万地址的根密钥（可通过 HD Wallet 结构）；

对于在链上与客户资产绑定的地址密钥，
轮换要谨慎，避免频繁更换地址导致：

客户资产追踪复杂化；
审计成本上升。

可以采用策略：

“客户地址较长期稳定，内部操作密钥与会话密钥定期轮换”。

Q312：销毁（Destruction）阶段为什么也很重要？

销毁阶段的风险在于：

看似“弃用”的密钥仍被保存在某处介质上；
未来被找回或恢复，就变成攻击者的“后门钥匙”。

因此需要：

对废弃密钥进行安全擦除（Secure Erase）；
在 HSM/MPC 系统中标记为废弃并限制调用；
对参与销毁的人员、时间和方法做记录；
在审计时可证明该密钥已无法被正常使用。

第三节：访问控制、权限与内部人风险

Q313：为什么必须对钱包相关操作实行“职责分离（Segregation of Duties）」？

因为内部人风险是真实存在的，包括：

单人可以发起并完成大额提币；
技术人员拥有生产环境 Root 权限，可绕过审批；
管理员可以篡改日志，掩盖未经授权操作。

职责分离的典型做法：

提币发起人与审批人不同人；
钱包操作与审批/审计分属不同团队；
运维人员不能直接访问私钥，只能操作系统层面；
合规/风控有只读监控权限，但不能改业务数据。

Q314：具体到钱包操作，权限管理应拆到什么颗粒度？

建议从三维去拆：

功能颗粒度
- 创建地址、发起交易、审批交易、查看余额、导出日志等分别授权；
额度颗粒度
- 每个角色拥有的单笔/日累计额度；
- 超限操作自动升级到更高级别审批。
币种与钱包类型颗粒度
- 某些人员只允许操作 Stablecoin；
- 某些人员只拥有测试环境或小额热钱包的权限。

这样的权限设计，有利于把风险局限在某个“安全域”内。

Q315：如何防止“管理员改日志掩盖痕迹”？

可以采用以下手段：

日志写入 WORM（Write Once Read Many）存储；
对日志定期做 Hash 并上链或存入独立系统；
使用集中式日志系统（SIEM），运维人员不能随意删除；
关键系统产生的日志同步备份到审计方只读节点；
对日志系统本身进行访问控制和双重审计。

监管非常看重“日志不可篡改性”，
这是事后追责和风险还原的基础。

Q316：对于远程办公与VPN访问，会不会削弱托管系统安全？

会，如果设计不当。注意：

核心钱包系统原则上不能通过普通 VPN 从公网访问；
如必须远程访问，需要多重保障：
- 专用堡垒机；
- 双因素认证（2FA / MFA）；
- IP 白名单；
- 精细化操作记录。

大部分托管操作应仅限于 安全办公网络或安全机房，
而非所有员工可以从家里随时接触。

Q317：如何应对“社工攻击（Social Engineering）」对托管团队的威胁？

防护包括：

对关键岗位员工（钱包、运维、合规）做安全意识培训；
所有敏感指令必须通过正式渠道（工单系统/邮件白名单），不通过社交软件口头传达；
拒绝通过电话/聊天软件修改收款地址、提币地址；
对关键变更（权限、白名单地址）要求回拨/双重确认；
定期做“红队演练”，模拟钓鱼邮件、假管理员指令。

Q318：是否需要对钱包操作人员做背景调查（Background Check）？

强烈建议，尤其是以下人员：

具有钱包操作权限或冷钱包密钥接触权；
具有生产数据库与关键系统访问权；
参与审批大额交易的管理层。

背景调查内容包括：

犯罪记录/金融犯罪历史；
个人信用状况；
工作履历真实性。

监管对于“关键岗位人员适当性（Fit & Proper）”有明确期待。

第四节：对账、监控与事件响应

Q319：托管体系里的“每日对账（Daily Reconciliation）”最少要做到什么程度？

最少覆盖三组数据：

链上总余额
- 所有钱包地址的链上余额合计；
系统钱包余额
- 内部钱包系统记录的各地址余额；
客户+公司账面余额
- 客户资产总额 + 公司自有资产总额。

目标是：

三者之间可解释一致，任何差异都有明确原因与处理记录。

Q320：发现对账差异时，标准处理流程应如何设计？

可参考步骤：

标记对账异常，自动触发 Incident；
初步分类：链上错误？账务系统错误？延迟确认？
指派技术+运营+风控小组联合排查；
记录调查过程与最终原因；
如果涉及客户资产，需要评估是否需暂停相关服务；
若金额重大或影响广泛，向管理层与合规部门报告，视情况通报监管。

对账异常不可“简单抹账冲销”，
必须形成完整事件闭环。

Q321：对于大额提币或异常行为，如何做到“事中监控”而不是事后补救？

建议：

设置实时规则引擎（Rule Engine）：
- 单笔大额提币阈值；
- 短时间内频繁小额提币；
- 向高风险国家/地址提币；
- 使用新设备/IP 触发的大额转出。
一旦命中规则：
- 进入人工复核通道；
- 暂缓广播交易或延时处理；
- AML/风控参与判断。

这实际上是 Custody Risk Engine + AML TM 的融合。

Q322：如果热钱包被黑客攻破，第一时间应该做什么？

紧急动作包括：

立即暂停提币服务；
快速评估受影响资产规模；
将尚未被转走的资产迅速迁移到安全地址/冷钱包；
启动 Incident Response Team（技术+风控+合规+法务）；
封存相关日志与系统快照；
通知管理层、保险公司、必要时通知监管；
根据事件性质决定是否公告告知客户。

事后要完成：

根因分析（Root Cause Analysis）；
补丁与架构调整；
内部与外部审计。

Q323：是否有必要为托管体系单独制定《重大事件应急预案（Incident Response Plan）》？

必须有，而且最好是：

文本化的正式文件；
包含不同场景（黑客、私钥泄露、系统故障、机房灾难）；
明确责任分工、决策机制、外部沟通渠道；
至少每年演练一次（Table-top Exercise）。

监管、审计和机构客户都会要求看到这类预案。

Q324：托管技术与 DORA（数字运营韧性法规）有什么交集？

DORA 更关注：

ICT 风险管理框架；
关键系统的业务连续性与灾备；
重大 ICT 事件的报告与应对；
第三方 ICT 服务（云服务、SaaS 钱包）的风险管理。

托管系统一般属于 “关键业务服务（Critical/Important Functions）”，
因此在 DORA 框架下需要更高标准的：

风险评估；
连续性计划；
供应商管理。

第五节：第三方托管、机构客户与产品设计

Q325：可以把全部托管功能外包给第三方托管机构吗？

理论上可以，但需要：

自己仍然对客户资产安全承担最终责任；
对托管机构进行充分尽调与持续监控；
签署详细的服务协议，明确各方责任；
在披露与合同中清楚告知客户；
在许可申请材料中向监管充分说明架构与控制措施。

监管不会接受“我都外包了所以不关我事”的逻辑。

Q326：在选择第三方托管商（Fireblocks、BitGo 等）时，应重点关注哪些合规指标？

重点包括：

是否有 SOC 2 / ISO 27001 / 其他安全认证；
是否为其他受监管机构提供服务（银行、券商、主流交易所）；
是否在欧盟/受信任司法辖区设有实体与数据中心；
技术架构说明（MPC/HSM、多区域冗余）；
服务可用性 SLA 与赔偿条款；
出现重大事件时的责任分配与信息通报机制；
退出机制（Exit Plan）：如何迁移资产与密钥。

Q327：机构客户（银行、基金）通常会问哪些托管技术问题？

常见问题包括：

你们使用自建托管还是第三方？是哪家？
有无安全认证/审计报告可提供？
私钥如何生成和存储？采用 MPC 还是 HSM？
冷/热钱包比例和切换机制如何？
资产对账与估值机制？
发生黑客事件或丢币后，赔偿机制如何？
是否购买保险？保险公司是谁？保额多少？

提前准备一份 《托管技术与安全白皮书》，
会大幅提升对接机构的效率。

Q328：对于“大额单一机构客户”，是否建议提供“专户托管”服务？

非常建议。模式包括：

独立链上地址或专属钱包；
独立审批流程与提币限额；
定制化报表与审计接口；
可选的双重签名规则（平台+客户共同授权）。

这样可以：

增强机构客户对资产隔离与安全性的信任；
减少“混合地址”引发的法律与合规争议。

Q329：在产品设计上，如何平衡“自托管（Non-Custodial）”与“托管（Custodial）」服务？

可以考虑组合策略：

对零售客户：
- 提供简单易用的托管钱包；
- 同时提供“导出私钥 / 接入自托管钱包”的选项；
对机构客户：
- 提供托管型方案（方便合规和报表）；
- 也可以对接其现有自托管或第三方托管。

关键是要：

技术架构与法律条款对应；
不要出现“名义自托管，实质上平台仍可签名”的灰色结构。

Q330：从 MiCA-CASP 托管视角看，一个“成熟方案”应具备哪些关键特征？

可以用 “6 个 C” 来概括：

Core-Safe（核心安全）
- MPC/HSM、冷/热分层、密钥全生命周期管理完善；
Clear-Legal（法律清晰）
- 托管法律结构与技术结构一致，客户权利义务明确；
Controlled（可控）
- 权限管理细致、流程可控、额度有限制、内部人风险低；
Checkable（可审计）
- 日对账、全日志、审计接口健全，可随时向监管/审计证明；
Continuity（可持续）
- 有应急预案、灾备、BCP，系统与组织能扛事故；
Credible（可信）
- 有第三方审计与认证、与合格托管服务商或金融机构合作、对外披露透明。

只要能在申请材料和实际运营中证明自己做到这“6 个 C”，
无论是 捷克监管、审计师、银行还是机构客户，
对你的托管体系一般都会给出比较正面的评价。

关于仁港永胜

我们仁港永胜在全球各地设有专业的合规团队，提供针对性的合规咨询服务。我们为受监管公司提供全面的合规咨询解决方案，包括帮助公司申请初始监管授权、制定符合监管要求的政策和程序、提供季度报告和持续的合规建议等。我们的合规顾问团队拥有丰富经验，能与您建立长期战略合作伙伴关系，提供量身定制的支持。

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

仁港永胜（香港）有限公司
合规咨询与全球金融服务专家

官网：www.jrp-hk.com
香港：852-92984213
深圳：15920002080（微信同号）

办公地址：

香港湾仔轩尼诗道253-261号依时商业大厦18楼
深圳福田卓越世纪中心1号楼11楼
香港环球贸易广场86楼

注：本文中的模板或电子档可以向仁港永胜唐生有偿索取。
【手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档】

✅ 委聘专业顾问团队（如仁港永胜）负责文件、面谈准备与监管沟通。
本文由仁港永胜（香港）有限公司拟定，并由唐生（Tang Shangyong）提供专业讲解。
仁港永胜——您值得信赖的全球合规伙伴。

免责声明

本文由仁港永胜（香港）有限公司拟定，并由唐生提供专业讲解。
本文所载资料仅供一般信息用途，不构成任何形式的法律、会计或投资建议。具体条款、监管要求及收费标准以捷克国家银行（CNB）及相关当地主管机关官方政策为准。仁港永胜保留对内容更新与修订的权利。

如需进一步协助，包括申请/收购牌照、合规指导及后续维护服务，请随时联系仁港永胜 www.jrp-hk.com
手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）获取帮助，以确保业务合法合规！

如欲查询更多捷克共和国（MiCA）加密资产服务提供商（CASP）牌照常见问题（FAQ 大全）有关的资料，请与我们仁港永胜的专业顾问联络，我们将为您提供免费咨询服务。[点击联系公司注册专业顾问]

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

上一页： 丹麦（MiCA）加密资产服务提供商（CASP）牌照常见问题（FAQ 大全），Denmark crypto license
下一页： 香港有限合伙基金（LPF）有限合伙协议（LPA）详细介绍