《斯洛伐克 Slovakia（MiCA）加密资产服务提供商（CASP）牌照申请注册指南》

Slovakia (MiCA) Crypto-Asset Service Provider (CASP) License Registration Guide

服务商：仁港永胜（香港）有限公司｜Rengangyongsheng (Hong Kong) Limited
本文由 仁港永胜（香港）有限公司 拟定，并由 唐上永（唐生，Tang Shangyong） 业务经理提供专业讲解。

适用对象：拟以斯洛伐克 Slovakia为 MiCA 申请国（Home Member State），申请并运营 CASP（Crypto-Asset Service Provider），并通过 MiCA 护照机制（passporting）向全欧盟跨境展业的机构。
法律依据：MiCA（EU 2023/1114）统一授权与持续监管框架
监管入口（关键结论）：在斯洛伐克，从事相关加密资产业务需要向斯洛伐克国家银行 NBS（National Bank of Slovakia）申请/对接授权与监管要求，NBS 已明确其为斯洛伐克的主管监管机关。

交付提示（PDF/附件索取）：可提供可编辑交付包（有偿）：
Master Checklist（A–I）、BP 模板（监管可读版+财务模型）、AML/Travel Rule 端到端 SOP、ICT/DORA/外包治理制度、RFI（补件）应答包、面谈题库（100–300 题）、MiCA 护照通报包等，可向仁港永胜唐生有偿索取。

✅ 点击这里可以下载 PDF 文件：斯洛伐克 Slovakia（MiCA）CASP 牌照常见问题（FAQ 大全）
✅ 点击这里可以下载 PDF 文件：斯洛伐克 Slovakia（MiCA）加密资产服务提供商（CASP）牌照申请注册指南
✅ 点击这里可以下载 PDF 文件：关于仁港永胜

---

一、牌照名称、监管坐标与“斯洛伐克路径”一句话结论

1）牌照名称
牌照名称：MiCA 体系下 Crypto-Asset Service Provider（CASP）授权（以斯洛伐克为 Home Member State，获批后可依 MiCA 护照机制在欧盟跨境提供获批范围内的加密资产服务）。

2）斯洛伐克监管坐标（最重要入口信息）

• 主管机关（NCA）：NBS（National Bank of Slovakia）。NBS 已公开说明：在斯洛伐克从事相关加密资产业务需取得主管机关授权，主管机关即 NBS。

• 跨境“规则与一般良好（Rules of General Good）”：NBS 已发布针对“来自其他成员国的 CASP 在斯洛伐克提供服务”需遵守的一般良好规则文件，用于护照展业合规落地（营销、消费者保护、投诉等常落在此类“本地一般良好规则”框架里）。

3）一句话结论（给老板/投资人）
斯洛伐克 CASP 的关键不在“写材料”，而在于：把 MiCA 的授权材料做成 NBS 可审查、可补件、可演示（系统证据链）的交付包，并从 Day-1 把 TFR/Travel Rule、AML、DORA/ICT、外包治理、客户披露与投诉机制做成可运行体系。

---

二、MiCA 统一框架价值 + 选择斯洛伐克作为 Home Member State 的策略优势

2.1 MiCA 统一框架的核心价值

• 单一授权 + 欧盟护照（passporting）：在一国获批后，可向其他成员国通报跨境提供服务/设分支。

• 统一经营规则：治理、利益冲突、信息披露、客户保护、外包治理、记录保存与报告制度统一。

• 与 Travel Rule 并行：加密资产转账随行信息规则由 TFR（EU 2023/1113）确立，直接影响托管、转账、交易平台对接与数据留痕。

2.2 斯洛伐克路径的实操优势（项目管理视角）

• 监管口径明确：NBS 已公开“监管入口与授权必要性”，利于前期对接、预沟通与材料映射。

• 护照展业“本地规则”已形成文件化抓手：NBS 对跨境来斯提供服务的 CASP 发布“Rules of General Good”文件，有助于你把跨境营销、语言披露、投诉与客户沟通制度提前模块化。

• 中东欧运营成本与合规中台搭建的可行性：适合将合规、风控、技术运营做成“欧盟合规中台”，再通过护照扩展到其他市场（但目标国的消费者保护/营销规则仍需逐国补丁）。

---

三、适用法律全景（EU 主法 + 关键配套：必须逐条映射）

交付建议：在 BP 与制度包中建立“条款映射矩阵（Article → Policy/SOP → System Evidence → Appendix No.）”，提升审批效率与补件应答质量。

3.1 欧盟层面（主法+配套）

• MiCA：Regulation (EU) 2023/1114（CASP 授权、持续义务、客户保护、资本/审慎、外包与记录保存等）。

• TFR/Travel Rule：Regulation (EU) 2023/1113（加密资产转账随行信息、参与方信息传递与留存）。

• DORA：Regulation (EU) 2022/2554（ICT 风险管理、第三方 ICT 风险、事件管理、韧性测试）。

• AMLA：Regulation (EU) 2024/1620（欧盟反洗钱管理局设立，推动 AML 监管趋同与更一致的执行预期）。

• DAC8：Council Directive (EU) 2023/2226（加密资产税务信息交换/报告，倒逼数据治理与可报告能力）。

3.2 斯洛伐克层面（AML/本地执法与报告接口）

• 反洗钱法：Act No. 297/2008 Coll.（反洗钱与反恐融资框架；异常交易/可疑交易报告机制等）。斯洛伐克财政部网站明确要求向金融情报单位报送异常金融交易等。

---

四、监管机构与分工：NBS（主审）+ AML 报告链条（FIU/财政部体系）

4.1 NBS（National Bank of Slovakia）

• NBS 明确：在斯洛伐克开展相关加密资产业务需取得授权，主管机关为 NBS。

• 对申请方而言，NBS 的审查会高度聚焦：治理可问责、资本与持续经营、关键外包可控、ICT/安全与证据链、客户保护与投诉机制。

4.2 AML 主管/报告接口（FIU + 主管部门协同）

• 斯洛伐克财政部页面明确：金融机构需向 Financial Intelligence Unit（Finančná spravodajská jednotka）报送异常金融交易等，依据 Act No. 297/2008。

• 实操提示：CASP 的 AML/STR（可疑交易报告）与 Travel Rule 字段留存、链上分析、制裁筛查记录要形成“可回放证据链”。

---

五、CASP 服务范围（MiCA 服务清单）与“申请组合策略”

5.1 先讲清楚：MiCA 下 CASP 是“按服务项授权”，不是“拿一个牌照想做什么就做什么”

在欧盟 MiCA 体系下，CASP 授权的核心是：你申请哪些服务（scope），监管就按这些服务逐项审查你是否具备“制度 + 人 + 资本/审慎 + 系统证据链 + 外包可控”的能力。服务边界不清，是补件（RFI）最常见源头之一。

NBS 在 FAQ 中明确：CASP 授权申请请求的框架在 MiCA 第 59–65 条，并将由 ESMA/EBA 的授权申请细则进一步具体化；并建议申请前可向 NBS 做业务模式咨询（提供服务类型与业务说明）。

5.2 MiCA 常见 CASP 服务“目录化拆解”（交付写法：服务→流程→制度→系统证据→资本/风控）

你在申请书与 BP（Business Plan）里建议用“服务映射表”呈现（每一行一个服务项）：

• Custody & Administration（托管与管理）
  核心审查：客户资产隔离、密钥治理、对账、转出控制、保险/保障安排、外包与审计权、事件响应。

• Operation of a Trading Platform（运营交易平台）
  核心审查：平台规则、撮合与公平性、市场监测、滥用/操纵识别、上币/下币治理、数据留痕与取证。

• Exchange（兑换：Crypto-Crypto / Crypto-Fiat）
  核心审查：报价来源、价差与费用披露、冲突管理、异常报价过滤、滑点/执行质量披露、对账单。

• Execution of Orders / Reception & Transmission of Orders（执行/传递订单）
  核心审查：订单生命周期、最佳执行/公平执行、客户指令留痕、录音录像/工单与争议处理。

• Transfer Services（代表客户转移加密资产）
  核心审查：Travel Rule 字段与流程、VASP 对接机制、异常/缺失信息处理、记录保存、制裁拦截。

• Advice / Portfolio Management（投顾/组合管理）（如申请）
  核心审查：适当性/合适性、利益冲突、产品分层、绩效披露、客户授权与风险揭示。

交付建议（写作结构）：每项服务都必须交付一套“SOP + 控制点 + 留痕证据链”，而不是一段描述。监管面谈常会追问：“你们系统里怎么点、怎么审、怎么拦、怎么导出日志”。

5.3 “申请组合策略”（监管难度 × 资本/系统压力 × 商业可行性）

把申请组合做成“三层策略”，方便董事会决策与项目管理：

（A）低系统压力 / 先拿牌策略（合规入门组合）

• RTO + Execution + Transfer
  适用于：偏经纪/代客执行、OTC 结构化、法币通道已外部合作、先建立欧盟合规中台。
  重点：AML/Travel Rule、记录保存、投诉处理、执行质量与披露。

（B）中系统压力 / 以交易为核心（交易所增强组合）

• Exchange（含 Crypto-Fiat） + Trading Platform
  适用于：以撮合/平台费为核心。
  重点：平台规则、市场监测与滥用识别、上币治理、异常行情控制、系统证据链。

（C）高系统压力 / 全栈重牌策略（最“吃资本与安全”）

• Custody + Platform + Exchange（可能再叠加 Transfer）
  适用于：想把钱包托管、交易、出入金、跨境服务一体化。
  重点：资产隔离、密钥安全（MPC/HSM/多签）、SOC/SIEM、灾备、第三方审计权、保险/保障、持续资本与现金流。

仁港永胜实务建议：先把“服务边界”定死，再倒推资本、岗位、制度、系统与外包条款包；不要反过来“先写制度再决定做什么”，会导致目录重做与补件反复。

---

六、申请主体与“实质运营（Substance）”要求（斯洛伐克落地核心门槛）

6.1 监管底层逻辑：Effective Management + 可问责 + 可检查（不是“注册一个地址”）

斯洛伐克 NBS 的公开口径强调：CASP 授权是 MiCA 框架内的授权；并提供申请前咨询机制，要求申请人提交业务模型详细描述与拟提供的服务类型。
这意味着：监管从一开始就会评估你是否真的能在斯洛伐克/欧盟有效管理（effective management），并在检查时能立即调取证据链。

6.2 “Substance 交付三件套”：三张图 + 三本账 + 三类留痕

（1）三张图（监管最爱问、也最容易一眼看穿真假）

1. 集团穿透结构图：股权、投票权、控制权、董事委派权、否决权、协议控制（到自然人 UBO）。

2. 组织架构图（含三道防线）：谁负责业务、谁合规/风控、谁内审/独立审查；汇报线清晰。

3. 系统数据流/权限流图：KYC→交易→链上/链下监测→告警→调查→STR→归档；外包系统如何接入。

（2）三本账（监管要“看得懂 + 算得出 + 对得上”）

• 客户资产账：客户币、平台自有币、热/冷钱包、托管第三方钱包的隔离与对账。

• 资金账（法币）：客户资金隔离账户、清算账户、运营费用账户、手续费收入账户。

• 风险与合规账：风险评分、告警工单、EDD 决策、豁免审批、STR 决策与反馈记录。

（3）三类留痕（现场检查时必须“秒出”）

• 开户与尽调留痕：KYC/KYB/UBO、EDD、制裁/PEP/负面新闻命中与处置。

• 交易与监测留痕：订单生命周期、链上追踪、规则命中、调查结论、处置动作。

• 治理留痕：董事会/委员会纪要、外包年度评估、重大事件复盘、整改闭环。

6.3 “最低可解释的人员实质模型”（小团队也能成立）

监管看的是“关键控制职能是否能有效履职”，不是堆人头。建议最低配置（可按规模调整）：

• Management Body（董事会/高管）：能覆盖战略、审慎、外包重大决策、事件升级。

• Compliance Officer（合规）：MiCA 行为义务、披露、投诉、营销合规、冲突管理。

• MLRO（反洗钱负责人）：AML/CFT、STR、制裁、Travel Rule、培训与年度审查。

• Risk / ICT Security（风控/信息安全）：ICT 风险、权限、日志、事件响应、BCP/DR。

• Internal Audit（内审/独立审查）：可外包，但必须有审计权、年度计划与整改闭环。

唐生点评：关键不是“能不能外包”，而是：外包后你是否仍然拥有控制权、可解释性、可审计、可退出（见第十九章）。

---

七、资本金与审慎保障（MiCA 取高规则）+ 现金流可持续证明

监管最怕：纸面资本满足，但现金流扛不住合规成本（平台/托管尤其明显）。

7.1 审慎保障的“取高逻辑”（交付口径）

• 最低资本（按服务类别） + 持续审慎保障（如固定开支比例等） → 取高满足，并建立持续监测机制。

• 输出三件核心交付：

  1. 资本测算表（服务类别 → 最低资本档位 → 实缴证明/资本来源）

  2. 固定开支口径说明（人力、外包、AML/TFR 工具、SOC/SIEM、审计、渗透测试、保险等全纳入）

  3. 资本补充机制（触发条件+股东承诺函+融资路径+时间表）

7.2 现金流可持续（监管版写法）

• 12–18 个月 runway 的证明（含压力情景）：

  • 市场下行（交易量下降、价差收入压缩）

  • 合规成本上升（事件响应、外包审计、监管检查）

  • 黑天鹅（安全事件、冻结/清退、诉讼与赔付准备）

---

八、股东/UBO 与适当人选（Fit & Proper）+ SoF/SoW（资金/财富来源）

8.1 必须尽调的人群范围（建议按“强制 + 扩展”做）

• ≥10% 股东/重大持股人（qualifying holding）

• 控股股东/实际控制人

• 最终 UBO（穿透至自然人）

• 董事、关键管理层、MLRO/合规负责人等关键岗位

8.2 Fit & Proper 四维模型（交付版）

1. 声誉：刑事/行政处罚、重大诉讼、监管纪律、制裁/负面新闻。

2. 能力：与岗位匹配的金融/交易/托管/合规/科技经验；过往项目可证明。

3. 财务稳健：破产/高杠杆、重大债务、无法解释资产负债结构。

4. 诚信与独立性：利益冲突披露、关联交易透明、治理不被不当影响。

8.3 SoF/SoW（监管最严模块）

• SoW（财富来源）：财富形成路径（经营利润/股权退出/薪酬分红/投资收益/资产出售）+ 证明文件（审计报表、完税证明、协议、银行流水）。

• SoF（资金来源）：本次入资/增资/收购资金的每一跳路径图（Source→Bank A→FX/Payment→Bank B→资本金账户）+ 每一跳解释与佐证。

• 制裁/PEP/负面筛查报告：含命中处置结论与复核留痕。

8.4 持续通知义务（必须写入制度与股东协议的触发器）

• 股权达到/跨越 10% 的变动、控制权变化、UBO 变化

• 董事/高管/关键岗位变更

• 资金结构重大变化、质押/信托/表决权协议变化

• 关键外包/系统控制权迁移（含集团内迁移）

---

九、公司治理（Governance）与“三道防线”落地（监管可问责模型）

目标：让监管看到“谁决策、谁执行、谁监督、谁复核、谁承担责任”，并能抽样验证。

9.1 治理总包（建议目录）

• Governance Charter（治理章程）

• 委员会 TOR（风险/审计/合规委员会；可按规模简化但必须“可问责”）

• Delegation of Authority（DoA 授权矩阵）

• RACI 矩阵（流程责任分配）

• 冲突管理（Conflicts of Interest Policy）

• 员工交易与礼品招待、关联交易与回避机制

• 记录保存与证据固化策略（会议纪要编号、附件索引、版本控制）

9.2 三道防线（1LOD/2LOD/3LOD）如何“可审计”

• 1LOD（业务线）：开户、交易、客服、资产划转、异常处置的 SOP 与工单留痕

• 2LOD（合规与风险/AML）：规则库、阈值、抽样复核、STR 决策、合规意见与整改闭环

• 3LOD（内审/独立审查）：年度计划、抽样测试底稿、缺陷评级、整改跟踪；小公司可外包内审但要独立性与审计权

---

十、关键人员与岗位胜任力（面谈“必问模块”）

10.1 必备岗位（监管版证据链）

• 董事/高管：战略、治理、财务可持续、重大外包审批与监督

• 合规负责人：MiCA 行为义务、披露、客户协议、营销合规、投诉处理

• MLRO：AML/CFT、STR、制裁、交易监控、培训与独立审查

• 信息安全负责人：密钥/权限、日志、事件响应、BCP/DR、供应链安全
  （按你的服务范围增加：平台监测负责人、托管运营负责人、风险负责人、数据保护负责人等）

10.2 “合格”的可提交证据

• 履历（监管版）+ 岗位说明书（JD）+ 任命决议

• 值勤安排（驻场/远程）、汇报线独立性说明

• 资源证明（预算、人手、系统权限、数据访问权）

• 年度培训计划 + 测试题库 + 胜任力评估记录

10.3 面谈打法（仁港永胜）

• 用“条款依据 → 我做什么 → 留什么痕 → 谁复核”回答

• 先备 30–50 个核心问题标准答案卡，再扩展到 100–300 题题库

• 对平台/托管：准备“系统演示脚本”（权限、日志、对账、异常处置、Travel Rule 对接）

---

十一、所需材料清单（Master Checklist）A–I（交付版｜对齐 NBS 递交）

注：NBS FAQ 已提示授权框架在 MiCA（59–65）并将由 ESMA/EBA 的实施细则进一步规定；因此交付建议采用“ITS 表格字段 → 附件编号 → 证据链”的方式组织材料，便于监管审阅与补件。

下面给出交付版 A–I（可直接做成“附件索引 Index”）：

A｜申请人身份与公司法文件（Applicant & Corporate）

• 公司注册文件、章程、董事名册、注册地址与实际办公证明

• 集团结构图（股权/控制权/关联方）

• 申请服务范围声明（服务清单 + MiCA 映射表）

• 业务地点与实质运营说明（Substance Pack：租赁、工位、IT 资产、值勤安排）

B｜业务模式与商业计划（Business Plan & Operating Model）

• 3 年 BP（含市场进入策略、目标客户、产品矩阵、收入模型）

• 订单生命周期（下单→撮合/执行→清算交割→对账→争议）

• 费用与价差披露样稿、客户旅程（onboarding→交易→提现→投诉）

• 财务预测三表（P&L/BS/CF）+ 压力测试 + 资本补充机制

C｜公司治理与内控框架（Governance & Internal Control）

• 治理章程（Board Charter）、委员会设置与议事规则

• 三道防线模型（RACI/DoA 授权矩阵）

• 利益冲突政策、员工交易与礼品招待政策

• 投诉机制、记录保存政策、内部违规处理与上报机制

• 会议纪要模板与决议编号规则（便于检查）

D｜资本金与审慎保障（Prudential Safeguards）

• 最低资本满足证明（入资证明/验资/银行对账单）

• 固定开支口径说明（合规成本写实：AML/Travel Rule/安全/审计/外包）

• 客户资产保护与隔离方案（链上钱包结构/法币隔离账户/对账频率）

• 保险/保障安排（如适用）与赔付边界说明

E｜AML/CFT + Travel Rule + 制裁（Financial Crime Compliance）

• 企业级 ML/TF 风险评估（方法论、权重、年度复核）

• KYC/KYB/UBO 穿透、EDD 触发器、PEP/制裁/负面新闻处置

• 交易监控规则库（链上+链下）与告警工单闭环

• STR（可疑交易报告）流程与时效、质量复核机制

• Travel Rule（EU 2023/1113）端到端 SOP：字段、消息、对接、退回/缺失信息处理、留存

F｜ICT / DORA 数字韧性（ICT Risk & DORA Alignment）

• ICT 风险管理框架、资产清单、补丁与漏洞管理

• 密钥/钱包安全（MPC/HSM/多签）与权限分层（RBAC）

• 日志（不可篡改）、SIEM/SOC、渗透测试与整改闭环

• 事件分级、通报、复盘与整改计划

• BCP/DR（RTO/RPO、演练记录、恢复证明）

G｜外包治理与第三方风险（Outsourcing & Third-Party）

• 外包清单与重大外包识别（critical/important）

• 第三方尽调（安全、合规、财务稳定性、分包链）

• 合同条款包：审计权、监管可访问、数据权、分包限制、退出与迁移

• 年度评估与替代供应商预案（Exit Plan）

H｜客户保护与市场行为（Conduct, Disclosures & Client Protection）

• 客户协议（T&Cs）、风险披露、费用披露、执行政策

• 适当性/合适性（如投顾/组合管理）与知识测评题库

• 市场滥用/操纵防控政策（平台类必备）

• 投诉处理与 ADR 指引、客户沟通模板

I｜监管沟通、递交流程与护照通报（Regulatory Process & Passporting）

• ITS 表格化申请材料（字段→附件编号索引）

• RFI（补件）应答包模板（条款依据→改进→证据→责任人→日期）

• 护照通报包（目标成员国、服务清单、营销合规补丁、多语言披露）

---

十二、董事/股东/合规人员/管理人员要求：什么情况下符合申请人条件

12.1 “符合申请人条件”的监管判断：四句人话

1. 董事会/高管能问责：不是挂名，能证明决策与控制链在欧盟可追溯。

2. 关键控制职能能独立履职：合规、AML、风控、信息安全有权限、有资源、有升级通道。

3. 股东与 UBO 透明且资金可解释：穿透到自然人，资金/财富来源证据链能闭环。

4. 系统能跑、证据能导出：不是 PPT，能演示 KYC/监控/Travel Rule/日志/对账。

12.2 董事/高管（Management Body）——最低合格画像与常见“卡点”

最低合格画像（建议口径）

• 覆盖至少两类关键能力：交易/托管/风控/AML/ICT/外包治理

• 理解 MiCA 的客户保护、披露、冲突管理、记录保存、投诉机制

• 有“有效管理”证据：值勤安排、签批权限、会议纪要、事件升级链

典型卡点

• 高管全部在欧盟外、斯洛伐克仅空壳办公室

• 董事会无人懂托管安全或交易系统（平台/托管类高风险）

• 重大外包由集团拍板、主体无审计权/退出权

12.3 股东/UBO/重大持股（10%/qualifying holding）——穿透、声誉、资金来源、持续通知

建议直接做成“股东尽调包（Shareholder DD Pack）”：

• 穿透结构图（股权+投票权+控制权）到自然人

• 声誉与合规记录：刑事/行政处罚、监管处分、重大诉讼、破产清算

• SoF/SoW：本次入资资金来源 + 长期财富形成路径（审计报表/完税/股权退出/资产出售）

• 资金路径图（Source→Bank A→FX/Payment→Bank B→入资账户）每一跳解释

• 持续通知触发器：达到/跨越 10% 变动、控制权变化、UBO 变化、质押/信托安排变化、重大外包控制权变化

12.4 合规/MLRO/风控/内审——“独立性 + 资源 + 证据链”

结合斯洛伐克 AML 框架：义务主体需对异常交易进行评估并向 FIU 报告，并受保密义务约束；报告机制与留存是检查重点。
因此岗位必须能证明：

• 任命决议 + JD + 汇报线（可直达董事会）

• 预算与工具（制裁/链上分析/监控/SIEM）

• 年度计划（合规计划、AML 年审、培训、内审）

• 工单闭环：告警→调查→结论→STR→整改

12.5 “申请人条件成立”的 8 项自检表（可复制到 BP）

满足以下 8 项，基本进入“可递交”：

1. 服务边界清晰（MiCA 服务映射表完成）

2. 斯洛伐克实质运营成立（办公+关键岗位+决策链）

3. 资本满足且现金流可持续（含压力情景）

4. 三道防线与治理问责落地（纪要/授权链）

5. AML/Travel Rule 可运行可演示（字段+流程+留痕）

6. ICT/DORA 可解释（资产清单、权限、日志、演练证据）

7. 外包可控（审计权/退出权/监管可访问）

8. 客户保护与披露就绪（协议、费用、风险、投诉、ADR）

---

十三、AML/CFT + Travel Rule（TFR）端到端运营设计（详细交付版）

13.1 监管期待的不是“手册”，而是“可运行体系”

• 企业级 ML/TF 风险评估（方法论、权重、评分、年度复核）

• CDD/KYC/KYB + EDD（触发器、审批链、拒绝策略、复核记录）

• 制裁/PEP/负面新闻筛查（命中处置、误报复核、升级路径、留痕）

• 交易监控（链上+链下）：规则库、阈值、行为模型、黑名单/风险地址、告警分级

• STR/SAR（可疑交易报告）：调查底稿、决策记录、报送时效、质量复核

• 培训与考核：岗位分层、年度计划、题库与通过率

• 独立审查/内审：抽样测试、缺陷评级、整改闭环

13.2 Travel Rule（TFR）必须“字段+流程+对接+留存”

• 字段：发起人/受益人信息、钱包地址、身份信息、交易标识、目的等（按法规与实现标准落地）

• 传递：与其他 CASP/VASP 的消息交换机制（API/协议）、失败重试、超时与拒绝策略

• 校验：缺失/不一致时的人工复核、延迟入账、退回与冻结策略

• 留存：满足审计与监管检查的可检索、可导出、不可篡改日志

• 风险处置：未获取必要信息/对手方不合规 → 拒绝/限制/上报/加强监控（写清楚阈值与责任人）

13.3 斯洛伐克本地 AML 报送接口提示

• 按 Act No. 297/2008 框架向 FIU 报送异常金融交易/可疑事项等（需在制度中写明报送路径、时效、内部审批与保密机制）。

---

十四、客户保护与信息披露（“写给客户看的合规”）

14.1 四类“对外可提交/可上线”交付件

1. Disclosure Pack（披露包）：费用、风险、执行方式、资产保管方式、冲突披露、投诉渠道

2. 客户协议 T&Cs：权责边界、暂停/终止、资产处置、硬分叉/空投、争议解决

3. 风险提示 Risk Warnings：清晰可理解，需留存客户确认（点击确认、签署、时间戳）

4. 营销合规 Marketing Policy：禁止误导与收益承诺；受众分层（零售/专业）；KOL/代理管理（佣金披露与冲突管理）

14.2 客户资产保护（按服务类型拆）

• 非托管：边界披露（你不控制私钥、客户自担风险）

• 托管：钱包结构、隔离、对账频率、冻结/扣划条件、赔付机制与保险（如有）

---

十五、平台类业务（Trading Platform）专项制度（规则 + 监测 + 证据链）

15.1 平台规则手册（必须可审计）
订单类型、撮合规则、手续费与返佣、暂停/熔断、异常行情处置、交易纠错/冲正、对账、公告机制。

15.2 市场监测与滥用识别（证据链）

• 刷量、操纵、对敲、关联账户、异常波动、内幕信息泄露风险

• 监测规则库 + 告警分级 + 调查底稿 + 处置动作（限制/冻结/下架/上报）

• “时间同步+不可篡改日志”确保取证可用

15.3 上币/下币治理（治理+合规+风控合一）

• 评估维度：合规属性、技术安全、项目方背景、流动性与操纵风险、制裁风险、信息披露质量

• 委员会决策：会议纪要编号、利益冲突回避、投票记录

• 重大事件下架机制：触发条件、客户通知模板、清退/迁移方案

---

十六、托管（Custody）专项制度（资产隔离、密钥、对账、责任边界）

16.1 资产隔离三件套

• 链上地址隔离（客户分层/批量地址策略）

• 账务隔离（客户资产账与自有资产账）

• 权限隔离（业务人员与密钥审批人员分离）

16.2 密钥管理（监管最敏感）
HSM/MPC/多签、最小权限、密钥轮换、备份与灾备、紧急冻结、审批链与双人复核、特权账号审计。

16.3 对账与差异处置
日终/实时对账、差异工单、根因分析、客户通知与补偿规则、审计底稿。

16.4 托管协议边界
赔付责任、不可抗力、第三方托管、保险/保证（如适用）、硬分叉/空投处理、司法冻结与监管配合流程。

---

十七、兑换与执行（Exchange / Execution）专项制度

17.1 报价机制与公平性
报价来源、聚合与异常过滤、滑点披露、报价延迟控制、交易回滚/纠错政策。

17.2 最佳执行/公平执行（尤其零售）
执行政策（Execution Policy）、订单优先级与撮合公平、禁止抢跑与内幕利用。

17.3 利益冲突（做市/自营/客户）
信息隔离墙、员工交易政策、关联账户识别、返佣与代理披露、定价与费用透明。

---

十八、信息安全、系统合规与“可演示证据链”（决定审批效率）

18.1 把 IT 合规做成“证据链”

• 架构图：业务流/数据流/权限流

• RBAC 最小权限 + 特权账号审计

• 日志：不可篡改、留存、检索、导出

• 渗透测试/代码审计报告 + 整改闭环

• 事件响应预案 + 演练记录（桌面/实战）

• BCP/DR：RTO/RPO、演练与恢复证明

18.2 DORA 对齐的交付要点
ICT 风险管理框架、重大事件分级与通报、第三方 ICT 风险治理、韧性测试（按规模与风险选型）。

---

十九、外包与第三方治理（Outsourcing）+ 供应链风险

19.1 为什么外包是 MiCA 时代的“必考题”

CASP 典型外包：云、托管、KYC、链上分析、撮合引擎、Travel Rule 通道、客服与工单系统。监管的核心不是“你外包了没有”，而是：

• 控制权是否仍在你手里（能否指挥、能否替换、能否退出）

• 是否可审计（你能审计，监管也能查）

• 数据与日志是否可访问与可导出（尤其跨境云与分包链）

• 供应链事件如何响应（SLA、通报、替代、客户沟通）

19.2 重大外包识别（Critical / Important Outsourcing）——交付方法

建议用一个表把外包做分级：

• 服务内容、供应商、数据类型、关键性、替代性、RTO/RPO 影响、分包链
  并把“重大外包”纳入董事会审批与年度复核。

19.3 外包合同“八大必备条款”（条款包交付）

1. 审计权（含穿透到分包商）

2. 监管可访问性（监管检查时可获取信息/场所/系统协助）

3. 数据权与数据驻留/传输（加密、访问、日志留存、删除）

4. 分包限制（事前同意、清单披露）

5. 事件通报时限与分级（安全事件、数据泄露、服务中断）

6. SLA/KPI 与违约责任

7. 退出与迁移条款（Exit Plan）（格式、时间、协助义务）

8. 业务连续性与灾备要求（演练、证据提供）

19.4 第三方风险管理（TPRM）运营化：不是一次尽调，而是持续治理

• 准入：安全测评、SOC 报告/渗透测试摘要、财务稳健性、合规资质

• 在管：季度 SLA 报告、事件复盘、年度再评估

• 退出：替代供应商、迁移演练、客户沟通模板、监管通报模板

---

二十、数据治理（含税务/报告导向）与记录保存

20.1 数据治理为什么要“往 DAC8/监管报告”倒推

MiCA + Travel Rule 会把你推向“可报告、可回放、可审计”的数据体系。再叠加欧盟税务信息交换趋势（如 DAC8），你必须做到：

• 客户身份数据（税务居民、KYC、UBO）可信

• 交易数据（链上/链下）一致

• Travel Rule 字段随行、留存可导出

• 监管/税务报告可自动抽取、可解释

20.2 三层数据治理架构（交付建议）

（1）字段标准层（Data Dictionary）

• KYC 字段、风险评级字段、Travel Rule 字段、订单字段、钱包地址字段

• 统一字典 + 版本管理（字段变更要留痕）

（2）留存与追溯层（Evidence & Audit Trail）

• 不可篡改日志（关键操作、特权账号、审批动作）

• 工单系统留存（告警→调查→结论→处置）

• 证据封存机制（导出、哈希、时间戳、访问控制）

（3）报告抽取层（Reg/Tax Reporting Layer）

• 报告模板、自动抽取脚本/接口、复核与签批

• 报告质量控制（QC）：抽样核对、差异解释、纠错闭环

20.3 记录保存（Record Keeping）“清单化”

建议把“必须留存的证据”做成 1 张总表（监管检查时直接交）：

• 客户档案（KYC/EDD/授权/确认）

• 交易与订单（订单生命周期、成交、对账单）

• Travel Rule（发送/接收字段、对接记录、退回与处置）

• AML（告警、调查、STR 决策、培训、年审）

• ICT（资产清单、权限、日志、事件、演练、渗透测试整改）

• 外包（尽调、合同、年度评估、SLA、事件复盘、退出演练）

---

二十一、投诉处理、ADR 与争议解决

21.1 投诉机制 = “写给客户看的合规”，也是监管对行为监管的抓手

建议交付四件套：

1. 投诉政策（Policy）：定义、范围、渠道、时限

2. 投诉流程（SOP）：受理→分级→调查→回复→结案→复盘

3. 话术库与模板：确认函、补充资料通知、最终答复、升级说明

4. 统计与治理：投诉 KPI、根因分析、整改闭环、董事会报告

21.2 分级与时限（可直接抄进制度）

• 一般咨询：T+2 工作日反馈

• 一般投诉：T+10 工作日结案（或阶段性回复）

• 重大投诉（涉及资产安全/交易错误/疑似欺诈）：即时升级合规与管理层；必要时冻结、止付、回滚、公告

• ADR/争议解决：明确条件、路径、语言、管辖与证据要求

21.3 证据留存（投诉必留痕）

• 客服录音/聊天记录、邮件、工单、操作日志

• 交易与对账证据

• 处理决策、补偿计算依据、客户确认与签收

---

二十二、财务模型、定价与“可持续经营”证明

22.1 BdP/NBS 这类审慎视角最怕什么：纸面盈利、实际现金流撑不起合规成本

财务模型必须写实地把合规成本列进去：

• AML：制裁筛查、链上分析、交易监控、培训、年审

• Travel Rule：通道费用、对接开发、字段留存

• 安全：SOC/SIEM、渗透测试、漏洞管理、灾备演练

• 外包治理：审计、评估、替代方案准备

• 法律/审计：外部审计、合规顾问、数据保护

22.2 三表 + 三场景（交付建议：监管读得懂）

三表：P&L、资产负债表、现金流量表（至少 3 年，月度颗粒度建议前 12 个月）
三场景：

• Base：按计划增长

• Downside：市场低迷/交易量下降/获客成本上升

• Stress：安全事件/重大外包中断/监管要求升级带来成本激增

22.3 定价与披露：把“费用透明”做成可上线页面

• 交易费、价差、托管费、提现费、上币费（如有）

• 费用变更通知机制（提前多少天、客户确认方式）

• 执行质量披露（滑点、异常报价过滤规则说明）

• 对账单样式（客户可核对、可下载、可追溯）

22.4 资本补充机制（监管最喜欢你提前写清楚）

• 触发点：亏损、固定开支上升、风险暴露上升、重大事件

• 措施：股东增资承诺、信用额度、成本削减计划、业务收缩/有序退出预案联动（与第 23 章衔接）

---

二十三、有序退出（Wind-down Plan）与业务连续性（BCP/DR）（斯洛伐克 MiCA 交付版｜仁港永胜唐生讲解）

本章目标：把“最坏情况”做成可执行、可审计、可监管复核的计划文件与证据链，满足 MiCA 对 CASP 稳健运营、客户资产保护与持续合规的底线预期；同时对齐 DORA（数字运营韧性）对 ICT 事件、灾备与第三方风险的要求。MiCA 主法见 Regulation (EU) 2023/1114。

23.1 Wind-down 的监管逻辑（监管为什么极度重视）

监管问法通常只有一句话：“你如果明天必须停止提供服务，客户资产与数据怎么安全退出？”
Wind-down 的核心不是“写一份计划”，而是证明你具备：

• 触发机制：何时启动退出（定量+定性触发器）；

• 治理链条：谁决定、谁执行、谁复核、谁对监管沟通负责；

• 客户资产保护：托管/平台/兑换/转账各条线的清退与对账；

• 外包可退出：关键第三方可替代、可迁移、可审计；

• 数据与留痕：KYC/交易/日志/投诉/STR 等记录可封存可导出；

• 沟通与秩序：对客户、监管、银行与关键对手方的沟通模板与时间表。

23.2 Wind-down 触发器（Trigger Framework｜建议“红黄绿”分级）

建议在董事会批准的《Wind-down & Recovery Playbook》中，用三层触发器固化启动条件：

A. 资本与财务触发（Prudential / Going Concern）

• 资本/审慎保障低于内部阈值（例如“监管最低要求 + 内部缓冲”）；

• 现金流压力：未来 3–6 个月出现不可逆资金缺口；

• 重大亏损或收入断崖式下滑（例如核心收入来源被迫停止）；

• 核心银行账户/法币通道中断且短期无法恢复。

B. 合规与监管触发（Regulatory / Compliance）

• 被要求暂停或限制部分服务；

• 发生重大合规事件（客户资产隔离/披露/市场行为等红线）；

• 关键岗位缺失（如 MLRO/合规负责人/安全负责人）且无法在规定期限补位；

• AML/制裁/Travel Rule 重大缺陷被确认且短期不可修复。

C. ICT/安全与外包触发（DORA / ICT）

• 发生重大网络安全事件导致资产/密钥风险；

• 关键系统不可用超过 SLA 且恢复失败；

• 关键外包商重大违约或破产，退出/迁移不可控；

• 数据完整性受损（账务与链上/链下对账不可恢复）。

交付要求：每条触发器都要写清指标口径、数据来源、监测频率、升级路径、董事会决策门槛（例如“黄灯：管理层行动；红灯：董事会 24h 决策并通知监管”）。

23.3 Wind-down 治理与执行架构（Governance & Command）

建议“最小可监管模型”如下：

• Wind-down Owner（董事会指定）：通常为 CEO/COO 或授权管理层；

• 客户资产负责人：托管/资金隔离/对账与清退；

• 合规与监管沟通负责人：对 NBS 统一口径；

• AML/MLRO 负责人：存量客户风险处置、STR、制裁与高风险账户冻结策略；

• ICT/安全负责人：系统冻结、证据固化、密钥保护、灾备切换；

• 第三方/外包负责人：合同启动退出条款、迁移与监管审计权协调；

• 法务/争议负责人：客户条款解释、争议解决、诉讼预案；

• 财务负责人：清退资金安排、费用与优先级支付（工资/供应商/审计等）。

必备附件：董事会决议模板、RACI、DoA（授权矩阵）、7×24 值班表、监管通知模板（草案）。

23.4 客户资产清退（按服务类型拆 SOP｜必须“可回放”）

Wind-down 必须按你申请的 MiCA 服务清单拆成 SOP：

(1) 托管 Custody（最敏感）

• 客户资产盘点：链上地址/子地址/标签，链下账务映射；

• 资产隔离证明：客户资产与自有资产分离（地址、账簿、权限）；

• 提现/迁移策略：

  • 白名单地址与冷静期；

  • 大额多签/MPC 再授权；

  • 分批迁移与差错处理；

• 对账与差异处置：每日对账→差异工单→根因→修正→客户确认；

• 未响应客户处置：公告+多渠道通知+最后期限+托管迁移/司法托管预案；

• “密钥/签名人”连续性：关键签名人不可用时的应急签名链与恢复机制。

(2) 平台 Trading Platform

• 交易冻结策略：分阶段（新开户→新订单→撮合→提币）；

• 未完成订单处置：撤单、结算、费用回退规则；

• 市场异常监控：防操纵、防挤兑、防刷量；

• 做市/流动性安排终止：对做市商通知、保证金/费用结算；

• 客户历史数据导出：成交、对账单、费用明细、税务/报表字段。

(3) 兑换/执行 Exchange / Execution

• 报价源停用与异常报价保护；

• 客户资产兑换回退机制；

• 价差与费用披露：退出期不得“暗改规则”。

(4) 转移 Transfer Services

• Travel Rule 通道：退出期仍需满足信息随行与留存；

• 未能满足信息的转账：拒绝/延迟/人工复核与留痕。

23.5 BCP/DR（业务连续性/灾备）交付要点（对齐 DORA 预期）

DORA 自 2025-01-17 起适用，CASP 需把 ICT 风险管理、事件管理、韧性测试与第三方风险做成制度与证据链。
交付建议至少包含：

A. BCP/DR 目标参数

• RTO/RPO：核心系统（撮合/托管/账务/KYC/日志）分别设定；

• 灾备形态：冷备/温备/双活（按成本与风险画像）；

• 恢复优先级：客户资产安全 > 账务完整性 > 交易服务 > 报表。

B. 演练与证据

• 年度桌面演练 + 技术演练 + 供应商联合演练；

• 演练报告：场景、结果、缺陷、整改闭环（含责任人与期限）；

• 安全测试：渗透测试/漏洞扫描/代码审计与整改闭环；

• 日志留存与不可篡改：满足监管检查可检索、可导出、可关联工单。

C. “退出 + 灾备”联动

• Wind-down 期间的 DR 切换方案（防止“清退期系统崩溃”）；

• 关键第三方停服时的替代路径（KYC、链上分析、Travel Rule 通道等）。

---

二十四、授权申请流程（ITS 表格化递交）与补件打法（斯洛伐克 NBS 路径｜仁港永胜唐生讲解）

本章目标：把申请做成“表格化字段 + 附件编号证据链 + 可补件闭环”，并按 NBS 的办理节奏管理项目风险。NBS 明确：不适用简化授权程序；并说明其将按 MiCA 时限进行完整性审查与决定流程。

24.1 主管机关与程序口径（NBS 为斯洛伐克主管机关）

在斯洛伐克，国家主管机关为 Národná banka Slovenska（NBS），并公开了关于加密资产/MiCA 的说明与 FAQ。

24.2 NBS 受理与决定的关键时限（项目排期必须对齐）

NBS 公示口径（重要）：

• 25 个工作日：评估申请是否“完整”（completeness check）；

• 若完整：40 个工作日：自收到完整申请之日起做出批准或拒绝决定；

• 且 斯洛伐克不适用简化授权程序。

实操解读：决定你项目周期的不是“写材料速度”，而是一次性完整性与补件响应质量。建议把交付目标定为：首递交即“可受理”。

24.3 ITS 表格化递交流程（“表格—附件—交叉引用”三件套）

MiCA 对 CASP 授权申请信息要素采取“标准化字段 + 模板化附件”的方向推进；欧盟已通过与 CASP 授权申请相关的 ITS（标准表格/模板/程序）文本。

交付方法论（仁港永胜推荐）

1. 先定服务清单 → 映射 MiCA 服务类别（决定资本、制度、系统证据链）。

2. 建立 Index（总索引）：

   • 每一个 ITS 字段 → 对应附件编号（A1、B3…）→ 附件页码/段落号；

   • 同一证据不得重复写，统一引用即可。

3. 双层材料体系：

   • “监管表格包（字段答案）”

   • “证据附件包（制度+流程+系统证明+合同+报告）”

24.4 预沟通与递交策略（减少补件的关键）

A. 递交前预沟通（强烈建议）

• 以“服务范围 + 组织与实质运营 + 外包清单 + 资本测算 + 系统架构图”作为沟通最小集；

• 目的：确认 NBS 对关键外包、系统证据、人员配置的关注点与呈现方式。

B. 递交版本控制

• v1：可受理版本（complete-ready）

• v2：按监管反馈增强（RFI-ready）

• v3：面谈/现场检查版本（audit-ready）

24.5 补件（RFI）应答打法（把补件做成“可审计闭环”）

监管补件常见集中在：Substance、资金来源、外包条款、系统安全、AML/Travel Rule 端到端留痕、财务可持续等（你之前葡萄牙版也同样适用到斯洛伐克）。

标准应答模板（每一条 RFI 必须这样写）

• RFI 编号 / 问题复述

• 法规依据/监管关注点（MiCA/DORA/TFR）

• 现状说明（简洁、可验证）

• 整改与增强措施（具体到 SOP、系统、合同条款）

• 证据附件编号（A-xx / B-xx / …）

• 责任人 + 完成日期

• 残余风险与监控（如适用）

补件最忌讳

• 只解释不提供证据（没有日志、截图、合同条款、演练记录）；

• 只给制度不给流程（没有“谁做—怎么做—留什么痕—谁复核”）；

• 外包合同无审计权/监管可访问/退出条款（极易卡死）。

---

二十五、处罚与合规风险地图（MiCA 红线清单）（斯洛伐克落地｜仁港永胜唐生讲解）

本章目标：把“可能被罚/被停/被拒批”的风险做成红线清单 + 控制措施 + 监控指标（KRI）+ 责任人。MiCA 作为欧盟统一法规，已规定监管与执法框架、违规类型与措施逻辑。

25.1 风险地图的结构（建议 4×4：事件类型 × 监管后果）

• 事件类型：未授权经营、客户资产保护、市场行为、披露与营销、AML/制裁/Travel Rule、ICT/DORA、外包治理、报告与记录保存

• 监管后果：整改命令/限制业务/暂停或撤销授权/行政罚款与公开处罚/刑事移送（视本国法衔接）

交付建议：做一张《MiCA Compliance Red Lines Register》，每条红线至少包含：条款来源、控制措施、监测指标、证据、责任人、复核频率。

25.2 “一票否决级”红线（建议直接写进董事会风险偏好声明）

红线 1｜未授权经营/超范围经营

• 未获授权提供 MiCA 规定的加密资产服务；或获批后超出服务范围运营。
  控制：产品上架审批（Regulatory Mapping Gate）、服务边界白名单、变更管理与事前通知机制。

红线 2｜客户资产挪用/未隔离/对账不可证明

• 托管与平台类最容易触发：地址/账簿/权限未隔离、对账机制缺失、差异无闭环。
  控制：每日对账、资金隔离账户、链上地址管理、权限最小化、审计轨迹不可篡改。

红线 3｜重大误导披露与营销（“写给客户看的合规”不过关）

• 风险提示不清晰、费用不透明、收益暗示、KOL/代理不当宣传。
  控制：Marketing Policy、素材审批、留存客户确认、投诉与纠纷数据反哺营销整改。

红线 4｜AML/制裁/Travel Rule 不落地

• 客户尽调缺陷、制裁筛查处置不当、STR 机制缺失、Travel Rule 字段/流程/留存无法证明。
  控制：KYC/EDD/KYB、制裁与 PEP 筛查、规则库+调查工单、STR 决策留痕、TFR 端到端 SOP。

红线 5｜重大 ICT 安全事件“无防护/无通报/无复盘”

• DORA 逻辑下，事件管理、演练、补丁、日志、第三方风险会被强穿透。
  控制：SIEM/日志、权限审计、渗透测试与整改闭环、事件分级与通报流程、BCP/DR 演练。

红线 6｜重大外包失控（无审计权/无退出/监管不可访问）

• 云、托管、KYC、链上分析、Travel Rule 通道等一旦失控，监管通常视同你失控。
  控制：外包分级、合同条款包（审计权/访问权/分包限制/退出迁移/数据权属）、年度评估与替代方案。

25.3 中高频“执法型”风险（建议设定 KRI 阈值）

A. 报告与记录保存缺陷

• 报表字段不一致、数据治理薄弱、日志无法检索导出、客户确认记录缺失。
  KRI 示例：报表差错率、日志缺口率、工单关闭超时率。

B. 投诉与争议处理失控

• 投诉积压、回复超时、重复投诉高发、根因不整改。
  KRI 示例：投诉 SLA 达成率、重复投诉率、重大投诉数量与趋势。

C. 利益冲突与关联交易未披露

• 做市商/项目方/关联方影响上币与风控；员工交易管理缺失。
  KRI 示例：关联方交易占比、员工交易违规次数、上币例外审批次数。

25.4 “被拒批/被卡审”的常见原因（斯洛伐克实操口径）

结合 NBS 的公开口径（强调按 MiCA 时限完成完整性审查，并且不适用简化程序），最常见“卡点”通常是：

• 申请不完整导致反复进入 completeness check；

• Substance 不成立（关键岗位不在欧盟/无有效管理证据）；

• 外包合同缺核心条款（审计权/监管访问/退出）；

• AML/Travel Rule 只有“制度文字”，没有“系统证据链”；

• 财务模型不支持合规成本，持续经营解释不足。

---

二十六、仁港永胜交付方案（结论与行动清单）

26.1 仁港永胜建议（可执行清单）

1. 先做服务映射：把业务拆到 MiCA 服务类别，明确申请范围与制度边界。

2. 系统证据链优先：权限、日志、对账、监控、Travel Rule 做到可演示。

3. 资本与现金流前置：把合规成本写实并纳入压力测试，避免“纸面资本”。

4. 外包治理一次成型：合同条款包（审计权/退出/监管可访问/分包限制）缺一不可。

5. 护照通报当第二阶段工程：先确定目标国清单，再做语言披露、投诉机制与“本地一般良好规则”补丁。

26.2 选择仁港永胜的好处（核心优势）

• 监管导向写作 + 补件能力强：把技术/风控落成监管可读证据链与附件编号体系。

• 模板库可直接落地：Checklist（A–I）、BP、AML/TFR SOP、ICT/DORA、外包/退出条款包、面谈题库、护照通报包。

• 跨境结构与护照经验：集团穿透、SoF/SoW、数据治理与跨境展业合规一体化交付。

26.3 关于仁港永胜

仁港永胜（香港）有限公司（Rengangyongsheng (Hong Kong) Limited）长期为金融机构、支付机构、加密资产平台、基金与家办提供：

• 牌照申请与持续合规（MiCA CASP、EMI/PI、SFC、MSO、VARA 等）

• AML/CFT 体系搭建、制度与系统合规、监管面谈与检查应对

• 跨境展业合规结构设计（护照机制、集团治理、数据治理）

26.4 联系方式

唐上永（唐生，Tang Shangyong）｜业务经理

• 手机 / 微信（深圳）：15920002080

• 香港 / WhatsApp：+852 9298 4213

• 邮箱：Drew@cnjrp.com

• 办公地址：

  • 香港湾仔轩尼诗道 253-261 号依时商业大厦 18 楼

  • 深圳福田卓越世纪中心 1 号楼 11 楼

  • 香港环球贸易广场 86 楼

26.5 免责声明

本文由仁港永胜（香港）有限公司拟定，并由唐生（Tang Shangyong）提供专业讲解。本文依据欧盟及斯洛伐克公开法规与监管信息整理，旨在提供一般性合规筹备参考，不构成法律意见、监管承诺或牌照获批保证。具体申请策略、材料清单、审查要点与费用应以主管机关（NBS）及欧盟最新法规、技术标准与个案事实为准。仁港永胜保留对内容更新与修订的权利。

---

---

斯洛伐克 Slovakia（MiCA）加密资产服务提供商（CASP）牌照申请注册指南,斯洛伐克加密牌照,斯洛伐克加密交易所牌照,斯洛伐克加密资产服务提供商牌照,斯洛伐克CASP牌照,Crypto-Asset Service Provider牌照,斯洛伐克加密资产服务商牌照,斯洛伐克MiCA牌照,斯洛伐克MiCA CASP牌照,斯洛伐克MiCA加密资产服务商牌照,斯洛伐克MiCA CASP申请,斯洛伐克MiCA牌照申请指南,斯洛伐克MiCA牌照注册,斯洛伐克MiCA牌照转让,斯洛伐克MiCA牌照出售,斯洛伐克MiCAR牌照,斯洛伐克MiCAR CASP牌照,申请斯洛伐克MiCAR牌照,斯洛伐克MiCAR牌照指南,斯洛伐克MiCAR注册,斯洛伐克加密资产服务提供商申请,斯洛伐克虚拟资产服务提供商牌照,斯洛伐克VASP牌照,斯洛伐克MiCAR VASP牌照,申请斯洛伐克VASP牌照,斯洛伐克加密交易所MiCAR牌照,斯洛伐克MiCAR常见问题,斯洛伐克MiCAR FAQ,Slovakia crypto license,Slovakia crypto exchange license,Slovakia CASP license,Slovakia Crypto-Asset Service Provider license,Slovakia MiCA license,Slovakia MiCA CASP license,Slovakia MiCA crypto license,Apply for Slovakia MiCA license,Slovakia MiCA license guide,Slovakia MiCA license registration,Slovakia MiCA license transfer,Slovakia MiCAR license,Slovakia MiCAR CASP license,Apply for Slovakia MiCAR license,Slovakia MiCAR license guide,Slovakia VASP license,Slovakia virtual asset service provider license,Slovakia MiCAR VASP license,Apply for Slovakia VASP license,Slovakia crypto regulations,Markets in Crypto-Assets Regulation Slovakia,MiCAR Slovakia guide,Slovakia cryptocurrency license,Slovakia blockchain license