首页 >  加密货币牌照

LT 立陶宛MiCA牌照申请注册指南（详细介绍），Lithuania MiCA License Application and Registration Gui

时间：2025-06-20 02:23:03 阅读：223

以下是《立陶宛MiCA牌照申请注册指南（详细介绍）》，由仁港永胜唐生撰写讲解，适用于有意在立陶宛申请欧盟《加密资产市场条例（MiCA）》下的加密资产服务商（CASP）牌照的公司或个人。内容涵盖MiCA适用背景、牌照架构、申请条件、合规要求、常见问题等，确保结构清晰、内容完整、实操性强，我把《立陶宛MiCA牌照申请注册指南》逐节拆分为24个独立篇章，每篇都是深度解释、实操详解的专业内容。

LT 立陶宛MiCA牌照申请注册指南（详细介绍）

MiCA法规简介（背景解读）

MiCA（Markets in Crypto-Assets）条例是欧盟于2023年正式通过的加密资产统一监管框架，于2024年底至2025年陆续生效，覆盖以下三类主要加密资产：

  • ARTs：资产参考型代币（如稳定币）

  • EMTs：电子货币型代币（类同电子货币）

  • 其它加密资产：如效用型代币、交易代币等

MiCA法规将强制要求提供相关服务的企业获得加密资产服务商（CASP）牌照，确保其在欧盟境内合规经营。

监管机构及牌照发放机关

项目 内容
监管机构 立陶宛银行（Bank of Lithuania）
欧盟协调监管 欧洲证券及市场管理局（ESMA）+ 欧洲银行管理局（EBA）
发放MiCA牌照 Bank of Lithuania（作为CASP主管机构）
监管依据 Regulation (EU) 2023/1114（MiCA条例）+ AMLD6

持牌情况与市场意义

  • 立陶宛原已是欧盟VASP高密度国家，2024年起逐步替换为MiCA制度。

  • MiCA CASP牌照将在2025年中后期成为欧盟范围内唯一加密资产牌照通行证。

  • 持牌后可跨境护照通行至整个欧盟30国，适用于交易所、钱包、托管、ICO发行等多类业务。

第一篇章：MiCA法规简介（背景解读）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南

一、MiCA法规的出台背景

MiCA，即《加密资产市场条例》（Markets in Crypto-Assets Regulation, EU 2023/1114），是欧盟为统一监管加密资产市场而出台的一部跨境性法规，旨在：

  • 消除欧盟内部加密市场监管碎片化

  • 增强投资者保护与金融稳定

  • 建立统一市场准入门槛

  • 推动区块链创新与合规发展

MiCA法规是欧盟金融服务监管体系中首次对非证券型加密资产设立专门监管框架，是目前全球最具影响力和完整性的数字资产立法之一。

二、MiCA涵盖的加密资产分类

MiCA规定对以下三大类加密资产进行规范：

类型 英文缩写 描述 示例
1. 资产参考型代币 ARTs 与多个法币/商品等资产锚定 类似Libra、稳定币篮子
2. 电子货币代币 EMTs 单一货币锚定，类同电子货币 USDC, EURT
3. 其它加密资产 Crypto-assets 无明确锚定、具效用性或交易性 ETH、NFT、平台币、游戏币等
 

⚠️ 不包括证券型代币（STOs），该类仍受《欧盟证券法MiFID II》监管。

三、MiCA的适用主体

任何在欧盟境内提供以下加密资产服务的主体，必须获得MiCA下的加密资产服务商（CASP）牌照：

  • 钱包托管商（Wallet Custodian）

  • 加密资产交易所

  • 法币/加密兑换平台

  • 加密资产发行平台（ICO/IEO）

  • 提供加密资产投资建议的顾问公司

  • 提供订单执行/传递/撮合的中介

✅ 所有原持有VASP（虚拟资产服务提供商）许可的企业，需在2025年前向MiCA过渡注册。

四、MiCA的立法时间与实施节点

时间 内容
2023年6月 MiCA正式由欧盟理事会与欧洲议会通过
2023年6月30日 在欧盟官方公报公布（OJ L 150/40）
2024年6月30日 部分章节（EMT/ART）生效
2025年6月30日 所有章节生效，CASP牌照全面强制化
 

即：从2025年6月30日起，所有在欧盟提供加密资产服务的机构必须持有MiCA牌照。

五、MiCA的立法结构概要

MiCA法规共设有四个核心部分：

  1. 定义与适用范围

  2. 发行人义务（对ART/EMT发行方）

  3. CASP义务（对服务商）

  4. 监管制度与跨境通行安排（passporting）

六、MiCA与其他法规关系图解

flowchart LR
A[MiCA] --> B[EMT]
A --> C[ART]
A --> D[其它加密资产]
A --> E[CASP]
A --> F[跨境护照机制]

MiFIDII -.-> D
AMLD6 --> E
ESMA --> A
EBA --> A
 

MiCA连接了：

  • 《反洗钱第六指令》（AMLD6）

  • 欧盟金融市场指令（MiFID II）

  • 加密资产发行监管

  • 中央监管协调机构（如ESMA、EBA）

七、MiCA对市场的改变与重要意义

方面 变化前 MiCA实施后
监管碎片 国家各自监管，无一致标准 欧盟统一监管标准，提升透明度
牌照通行 各国VASP不可互认 一地CASP持牌，可全欧通行
投资者保护 投资风险隐患高 强制信息披露与合规运营
项目融资 发行不受控 ART/EMT/ICO全流程合规注册
监管协调 无监管沙盒协同机制 建立ESMA与国家监管局协同机制

八、为何选择立陶宛作为MiCA申请地？

  • 监管友好度高，已建立VASP制度基础

  • 英语沟通顺畅，法律支持完备

  • 银行开户相对灵活

  • 与ESMA、EBA沟通机制通畅

  • 市场已存在众多CASP申请成功案例

九、对中国/亚洲申请人的重要提示

  • 可通过设立立陶宛公司（UAB）作为CASP主体

  • 可远程任命管理层，但需有本地负责人

  • 提前准备系统架构与冷钱包机制

  • 过渡期结束后，无牌照将无法继续提供服务

十、结语：MiCA是时代转折点

MiCA的实施不仅仅是一次合规升级，它标志着数字资产行业全面进入金融主流监管体系。任何希望在欧盟市场长远发展的企业，都必须理解MiCA的底层逻辑并作出合规响应。

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

第二篇章：监管机构及MiCA牌照发放机制

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、立陶宛监管机构总览

1. 主监管机关：立陶宛银行（Bank of Lithuania，简称BoL）

项目 内容
名称 Lietuvos bankas（立陶宛银行）
网址 https://www.lb.lt/en
职能 国家央行 + 金融监管机构 + 欧盟MiCA牌照主管机构
权限 审查、发牌、监管、罚款、撤牌、审计通知等
国际协调 与ESMA、EBA、FIU（金融情报局）紧密合作
 

立陶宛银行的监管职责远超传统央行，兼具FSA与AML监管职能，是MiCA时代欧洲最积极的加密资产牌照主管机构之一。

2. 欧盟协调监管单位

MiCA制度下，除国家监管机关（如BoL）外，还包括两大欧盟层级协调监管单位：

机构 全称 监管职能
ESMA 欧洲证券及市场管理局 注册与信息发布、技术标准制定、跨境协调、数据备案
EBA 欧洲银行管理局 监管稳定币（EMT）、重大发行人、重大CASP、报告机制指导
 

监管架构示意图如下：

flowchart LR
A[CASP申请人（立陶宛公司）] --> B[Bank of Lithuania]
B --> C[ESMA]
B --> D[EBA]
C --> E[欧盟中央CASP数据库]

二、MiCA牌照发放流程机制（立陶宛版）

实际发牌由谁执行？

MiCA CASP牌照在立陶宛的发放工作由BoL负责，包含：

  • 审查全套申请文件

  • 向ESMA备案服务范围与公司信息

  • 组织面谈（如需要）

  • 与立陶宛金融情报部门协同尽调

BoL会视公司申请的服务类型与风险程度，决定是否开展“深入尽调”或“面谈核查”。

牌照发放的程序步骤

步骤 内容 说明
Step 1 建立立陶宛公司（UAB） 须具备法定注册地址、法人代表、本地董事等
Step 2 准备申请文件 包含章程、BP、AML政策、IT说明等完整资料
Step 3 向BoL递交申请 可线上通过Fintech申请平台递交
Step 4 BoL进行初步审查 格式完整性、资料基本合规
Step 5 BoL进行合规审查 涉及背景调查、MLRO访谈、IT架构审查等
Step 6 BoL反馈补件/修订 正常情况下有1–2轮补件要求
Step 7 BoL发出批准信 同时通知ESMA登记
Step 8 正式获得CASP授权 公司名称将出现在ESMA公共数据库中
Step 9 后续监管备案 每年监管报告、修改备案等持续义务

三、监管协调机制（立陶宛→ESMA）

MiCA牌照通过立陶宛BoL发放后：

  • BoL会将申请人资料登记至ESMA的中央CASP登记系统

  • 可选择开启“passporting机制”，进行欧盟范围通行备案

  • BoL负责监督经营合规，ESMA负责宏观审查与协调指引

重点：即使已在立陶宛持有MiCA牌照，在法国、德国、意大利等地提供服务，仍需通过BoL向ESMA发起跨境备案通知（passporting notification）。

四、立陶宛BoL对MiCA申请人的审查关注点

审查维度 核心关注点
法人结构 是否存在多层不透明结构、是否穿透到最终受益人
高管履历 管理经验、反洗钱经验、在其他司法管辖区是否有监管记录
MLRO配置 是否具备AML培训记录、经验是否真实、是否能有效报告STR
冷钱包机制 是否具备分层权限、多签/隔离机制、安全恢复流程
商业计划 是否可行、是否有误导性承诺、技术方案是否匹配计划
系统架构 是否足够支持交易记录留存、STR识别与报告
客户类型 是否面向高风险国家或高风险行业、是否有客户适当性制度
 

BoL的审查更偏向**“结构清晰 + 实质运营 + 风险可控”**三大原则，偏爱已建立系统、流程、AML制度较为成熟的团队。

五、监管沟通机制与时间预期

阶段 正常耗时 特别说明
初审确认受理 2–3周 格式无误、材料齐备即开始
初轮反馈时间 4–6周 常涉及补件要求
全流程总时间 4–8个月 依项目复杂度而定
 

实务建议：

  • 尽量使用立陶宛语或英语撰写文件

  • 选定常驻代表与BoL持续沟通（可为合规顾问）

  • 所有IT系统描述、AML制度必须文档化并可操作

六、未来趋势预测与BoL风向提示

  • 对“提供交易撮合平台”的申请人，系统安全性审查将日趋严格；

  • BoL近期倾向于支持“实际运营 + 本地就业”的MiCA结构；

  • 海外远程运营架构必须提交证明文件说明如何在立陶宛有效管控运营；

  • 将建立CASP处罚公开系统，严重违规者可能影响跨境通行；

  • 建议项目方预留审查窗口 + 补件窗口，合理编排上线计划；

七、结语：监管机制是MiCA成功的保障

MiCA并非简单的“许可发放制度”，而是一个涵盖发放、备案、审计、惩戒、协同通行在内的“合规生态系统”。立陶宛的BoL在其中扮演着欧盟东部地区重要的枢纽角色，适合作为MiCA申请首站。

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

第三篇章：MiCA牌照市场定位与持牌意义

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA牌照的战略定位

1. MiCA是全球首个区域级加密资产统一监管框架

MiCA（Markets in Crypto-Assets）不是传统意义上的“国家牌照”，而是欧盟层级立法，类似MiFID II、PSD2，为加密资产行业树立了以下三大核心标准：

  • 准入门槛明确化（Minimum Standardization）

  • 服务通行欧盟全境（Passporting Across EU）

  • 统一监管框架、统一备案路径（One EU Market）

因此，MiCA不仅是一个“合规通道”，更是企业战略进入欧洲市场的核心起点。

2. MiCA将替代所有国家级VASP制度

国家 原有牌照 是否将废除 MiCA替代时间
立陶宛 VASP登记（FNTT） ✅ 是 2025年6月起仅MiCA有效
法国 DASP登记 ✅ 是 2025年6月起统一MiCA
德国 需BaFin许可 ✅ 是 并行过渡至MiCA
爱沙尼亚 VASP许可 ✅ 是 强制过渡MiCA结构
 

重要提示：原VASP登记企业必须向MiCA过渡，否则到期后将被强制注销或限期整顿。

二、MiCA持牌后的战略价值与意义

✅ 1. 拥有欧盟护照（EU Passport）

MiCA牌照可激活加密资产服务护照机制，即：

一地持牌（如立陶宛） → 可合法向所有其他欧盟成员国提供同类服务 → 无需重复申请牌照。

项目 内容
涉及国家 全部27个欧盟成员国 + EEA地区（冰岛、列支敦士登、挪威）
通行权限 不需实体设立，仅需向BoL备案通知ESMA
市场规模 超过4.5亿人口 + 世界第二大经济体（按地区GDP）
 

例如：持有立陶宛MiCA牌照，可面向德国客户提供加密货币交易、钱包托管、ICO发行等服务。

✅ 2. 等同证券机构的监管地位

MiCA CASP持牌企业将被视为等同“金融中介机构”，其法律地位与以下持牌机构类似：

  • MiFID持牌证券经纪商

  • PSD2电子支付机构

  • AIFMD授权基金经理

  • CRD IV授权信贷机构（银行）

因此，其在银行开户、保险合作、交易对接、合作谈判中，将不再被视为“非主流灰色业务”，而成为被金融系统认可的正轨机构。

✅ 3. 项目融资与投资人信任背书

MiCA持牌企业更易获得：

  • VC与家族办公室青睐

  • 交易所/钱包/项目方合作机会

  • 托管服务商与审计公司支持

许多欧洲风投基金（如Outlier Ventures, Speedinvest等）已公开表明：

“对于Web3或加密项目，我们只看MiCA监管下的结构。”

✅ 4. 系统性合规安排便于全球扩展

持牌后结构具备良好“对外复制性”，可作为：

  • 申请香港SFC 1/4/7/9类牌照时的欧洲节点

  • 申请新加坡PSA、MAS相关结构的欧盟参照公司

  • 申请美国FinCEN登记、州MTL/SEC豁免时作为受监管对标

MiCA作为合规枢纽，在全球合规版图中意义巨大。

三、MiCA牌照的应用场景

投资交易平台（如DEX、中心化平台）

可用于持有客户资产、撮合交易、提供流动性、连接外部钱包

钱包服务商（如硬件钱包、托管商）

可作为自托管+托管服务机构，合规持牌服务欧盟用户

项目方/代币发行方

如拟进行ICO、STO或初期流通代币销售，MiCA牌照提供合规路径

Web3金融应用（DeFi Gateway）

作为“法币入口”（on-ramp）或链下支付结算服务合规节点

四、MiCA持牌后的运营优势总结表

项目 无MiCA持牌 MiCA持牌
提供服务 多国不可直接服务 一地持牌全欧通行
投资人信任 风险高、无审计 监管支持、可审计
银行账户 难开户、被冻结风险 容易开户、合规接受
客户争取 面临合规壁垒 可投标机构项目、与银行合作
风险处罚 无法上诉 有法律支持、行政复审机制
 

五、MiCA结构 VS 海外结构（对比表）

指标 MiCA立陶宛牌照 新加坡PSA 美国FinCEN + MTL
欧盟通行权 ✅ 全欧通行 ❌ 无 ❌ 无
系统合规 ✅ 强制审核IT系统 ✅ 中等要求 ❌ 不审核系统
冷钱包监管 ✅ 明确要求权限图解 ❌ 一般性说明 ❌ 自行声明即可
审计要求 ✅ 年审/STR报告 ✅ 年审 ❌ 无硬性要求
投资人认可度 ✅ 高 ✅ 高 ✅ 高
成本控制 中等（€100–200k/年） 中高 高
注册时间 4–8个月 3–6个月 ≥12个月（多州并行）
 

六、适合持MiCA牌照发展的企业画像

✅ 已在亚洲运营但希望拓展欧盟市场的加密项目
✅ 想在香港/新加坡之外布局第二个牌照基地的交易平台
✅ 有稳定技术架构但未取得主流监管背书的Web3金融应用
✅ 拟通过合规方式向机构投资者销售代币或基金产品的项目方
✅ 计划作为发行代理或跨境流通节点的中间服务商

七、结语：持牌不是终点，是全球征程的起点

MiCA牌照是一块欧盟市场的“入场券”，更是一块项目在法律和金融体系中的信任背书。拥有MiCA，是打开合规欧洲市场的唯一钥匙，更是在全球机构面前的一张信用证。

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

第四篇章：MiCA适用服务范围十大类型详解

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA定义的加密资产服务商（CASP）

MiCA条例将提供加密资产服务的企业正式定义为加密资产服务商（Crypto-Asset Service Providers, CASPs），并要求其就所提供的每一种具体服务类型申请许可并受监管。

MiCA共列明10种法定服务类型，每种服务均对应不同的监管责任、技术要求和资本金标准。

二、十大MiCA服务类型详解

编号 服务类型 官方定义 实际业务示例
1 托管和管理钱包 为客户保管加密资产的私钥或钱包 冷钱包托管、第三方代管服务
2 运营交易平台 撮合客户买卖加密资产的平台 CEX平台、限价单撮合系统
3 法币兑换服务 加密资产与法币之间的兑换服务 OTC交易、入金出金服务商
4 加密资产间兑换服务 不同加密资产间的兑换 Swap服务、DeFi聚合兑换
5 转账服务 客户委托的资产转移行为 加密资产跨钱包转账
6 接收与传递订单 将客户的交易指令转给其他平台 类券商服务、中间人模式
7 执行订单 代表客户在交易所执行订单 API下单服务、量化交易
8 自营交易服务 公司自身账户进行的交易行为 Market making、自营套利
9 发行与承销加密资产 代项目方承销、销售新发加密资产 ICO、IEO、STO顾问服务
10 提供建议或分析服务 提供投资建议、资产配置分析 研究报告、咨询顾问服务
 

三、服务类型举例与监管影响分析

类型1：托管和钱包管理（Custodian）

  • 要求最严格：需提供冷钱包权限分层、私钥存储机制、风控日志

  • 资本金要求：€125,000 起

  • 系统需接入STR识别与日志备份模块

  • 高度依赖IT合规与MLRO风控

类型2：交易平台运营（Exchange）

  • 包括撮合引擎、限价单簿、订单可视化界面

  • 强调交易透明度、报价一致性、订单追踪能力

  • 不得进行链上撮合（MiCA禁止此类机制）

  • 资本金要求：€150,000 起 + 技术团队强支撑

类型3：法币兑换（Fiat On/Off-ramp）

  • 涉及银行合作、支付渠道、KYC验证流程

  • 通常需与EMI或银行结构对接

  • 监管要求客户身份验证强度（例如AML KYC等级评估）

类型4：加密资产兑换（Swap / DEX）

  • 通常由聚合器或DEX界面提供

  • 若存在撮合、价格决定，则属交易平台监管级别

  • 使用者无法自主选择流动性路径，则需承担平台责任

类型5：资产转移（Transfer Service）

  • 类似区块链上的支付指令发送服务

  • 包括DeFi代转功能、第三方执行钱包接口

  • 涉及“旅行规则”（Travel Rule）数据附加机制

类型6：接收与传递订单（Order Reception）

  • 类似于券商委托机制（MiFID结构）

  • 不参与撮合，只中介传递客户意愿至交易平台

  • 要求向客户充分披露平台差异与费用结构

类型7：执行订单（Order Execution）

  • CASP需有系统主动下单能力

  • 包括API执行服务、自助下单终端对接CEX平台

  • 监管方关注交易偏差、滑点控制、交易延迟风险

类型8：自营交易（Proprietary Trading）

  • 企业用自有资金交易加密资产

  • 必须向监管披露策略模型与止损机制

  • 不得与客户账户共用流动性池

类型9：代币承销与销售（Offering & Placement）

  • 例如项目代币发售、IEO、IDO服务平台

  • 涉及信息披露、客户适当性评估、代币估值模型

  • 可能需提供《Whitepaper符合性声明》

类型10：加密投资建议与分析服务

  • 提供客户投资组合建议、市场策略、新闻分析

  • 与传统投顾接轨，需持有类似MiFID授权性质的审查机制

  • 附带报告、客户适当性匹配机制建议

四、服务组合的合规设计建议

MiCA支持“一次申请，多类授权”。企业可申请多个服务组合，但应确保：

  • 每项服务均有流程文件、系统描述、风控方案

  • 不同服务之间账户、记录、职责隔离清晰

  • 合并服务不得规避监管（如交易+顾问 → 必须各自披露责任）

✅ 推荐组合例子：

使用场景 推荐服务组合 适用对象
去中心化聚合平台 2+4+6+7 Swap平台、聚合订单网关
托管+交易平台 1+2+3+5+10 综合型虚拟资产服务平台
Web3支付平台 3+4+5 法币/链上支付场景应用
ICO项目顾问平台 9+10 代币发行顾问、项目融资服务
自营流动性做市商 7+8 MM团队、量化基金
 

五、不同服务类型的关键监管关注点（监管表）

服务类型 监管要点 是否需冷钱包 STR义务 客户适当性机制
钱包托管 权限分层、恢复机制、安全存储 ✅ 必须 ✅ 必须 ❌ 无需
交易平台 报价机制、撮合透明度 ✅ 推荐 ✅ 必须 ✅ 建议
法币兑换 AML流程完整、银行通道合规 ✅ 推荐 ✅ 必须 ✅ 建议
加密资产兑换 防价格操控机制、链上透明度 ❌ 可选 ✅ 必须 ❌ 无需
转账服务 Travel Rule机制、合规验证 ✅ 必须 ✅ 必须 ❌ 无需
执行与接收订单 委托流程合规、无利益冲突 ❌ 可选 ✅ 必须 ✅ 建议
自营交易 模型备案、流动性风险披露 ❌ 可选 ✅ 必须 ❌ 无需
承销发行 披露义务、估值模型合理性 ❌ 可选 ✅ 必须 ✅ 必须
提供建议 中立性、客户匹配逻辑合规 ❌ 可选 ✅ 必须 ✅ 强制
 

六、结语：申请前应精确界定服务边界

MiCA是一项服务导向型监管结构，你申请什么服务，就承担什么义务。因此，必须在申请前：

  • 明确服务定位

  • 拟定对应IT系统+操作流程

  • 准确估算资本要求和人力结构

第五篇章：MiCA牌照申请条件详解（公司、人员、资本、技术）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA牌照申请的合规前提

MiCA条例要求所有在欧盟范围内提供加密资产服务的企业，必须申请并获发加密资产服务商（CASP）牌照。申请人必须满足以下四大类实质条件：

✅ 公司设立与实质运营
✅ 人员配置与适当人选（Fit & Proper）
✅ 资本金与资金证明
✅ 技术系统与内控制度

二、公司设立与注册条件（以立陶宛为例）

1. 法人类型要求

  • 必须注册为立陶宛本地公司（UAB）

  • 不可为分公司、代表处、合伙企业

2. 公司注册基本条件

项目 要求
名称 可包含“Crypto”、“Digital”、“Wallet”等字样
注册资本 最低€2,500起（不等同实缴监管资本金）
办公地址 必须为可验证的商业地址（不可使用虚拟注册地）
登记官 需有注册代理人协助递交申请
经营范围 公司章程需包含CASP相关业务字样（英文+立陶宛文）
 

3. 实质运营要求（Substance）

MiCA强调“经济实质”原则，公司必须具备：

  • 实体办公地址

  • 在立陶宛的日常运营管理（可远程，但需有负责人）

  • 本地审计师、银行账户、合规顾问等支撑体系

⚠️若公司架构过于复杂、不透明，或实际控制人未申报，申请可能被驳回。

三、人员配置与“适当人选”要求（Fit & Proper）

1. 董事与高级管理人员要求

岗位 最少人数 要求
董事会成员 至少1人 有相关行业背景，不涉洗钱/欺诈前科
负责人（CEO或总经理） 至少1人 负责运营管理，需具备管理履历
合规官（MLRO） 1人 必须具备AML/CFT培训与从业经验
财务负责人 1人（可兼任） 具财务审计知识，提交年度报表责任人
 

✅ 所有核心岗位人员需提供：

  • 护照扫描件

  • 无犯罪记录证明（6个月内）

  • 专业履历（CV）

  • 推荐信（可选）

  • AML培训证书（MLRO专属）

2. “核心职能人员”可远程配置，但需说明如下：

  • 日常管理方式

  • 如何对员工/系统进行远程监管

  • 如何协调合规运营与数据留存

  • 提供本地联络人及常驻代表说明信函

四、资本金要求（实缴 + 证明）

MiCA明确规定了不同服务类型需缴纳最低监管资本金：

服务类型 最低实缴资本金（EUR）
钱包托管、交易平台、法币兑换等核心服务 €125,000–€150,000
中间服务（订单接收、传递、咨询等） €50,000–€75,000
 

资本金需满足以下三项要求：

  1. 实缴到公司银行账户，可用于运营周转

  2. 非来源不明资金（提供资金来源说明）

  3. 在申请阶段存入监管银行或附上银行证明信

⚠️不可使用债务性工具（如可赎回股本、贷款）作为资本金。

五、内控制度与合规政策框架要求

MiCA要求CASP申请人建立完整的制度框架，涵盖以下关键领域：

制度名称 内容关键点
AML/KYC制度手册 客户识别程序、持续尽职调查、STR报告机制
客户适当性政策 匹配服务与客户背景、禁止不合适销售行为
投诉处理政策 明确客户申诉路径、处理时效、记录归档
操作风险控制制度 日志管理、权限审查、系统灾备机制
内部稽核政策 例行审计计划、自我评估机制
反欺诈与黑名单机制 客户行为识别、封禁策略、信息共享方式
 

所有制度须可提供文档版本，且具备可执行性，并接受审计抽查。

六、信息系统与技术要求

MiCA规定，加密资产服务商所用的核心技术系统必须具备：

功能模块 实操内容
账户权限分层 管理员、操作员、审计人员等不同权限设置
客户资产独立记录 客户资金、公司资金分离存储
冷钱包机制 多签权限、安全备份、恢复程序文档
STR识别与日志留存 系统能自动识别可疑交易，保留最少5年记录
系统安全与恢复 加密传输、自动备份、本地或EU数据中心灾备
 

⚠️申请人须提交IT系统说明书，包括：

  • 技术架构图

  • 冷钱包权限控制说明

  • 系统开发者简介

  • IT外包或第三方协作说明（如使用Fireblocks等托管商）

七、推荐资料清单（可提前准备）

  • 《公司章程草案》

  • 《高管履历与KYC包》

  • 《AML政策手册》草案

  • 《商业计划书（含三年财务预测）》

  • 《系统说明书 + 权限流程图》

  • 《资金来源证明信》

  • 《银行账户证明文件》

  • 注：以上文档/附件原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]

八、结语：越早准备，越快获批

MiCA牌照申请不是单纯的文件拼装，而是一个系统性的实质运营能力证明。准备得越充分，越能缩短审核时间。特别是人员结构、资本金、系统说明等重点部分，务必提前筹备、一次交付清晰。

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

第六篇章：MiCA牌照申请流程图解与时序安排

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA牌照申请流程概览

MiCA牌照的申请流程围绕“公司注册 → 文件准备 → 递交申请 → 补件审查 → 发放许可 → 注册ESMA”六大步骤展开。根据立陶宛监管机构（Bank of Lithuania, BoL）及欧盟MiCA要求，流程具有阶段性与递进性特点。

流程图（标准版本）

graph TD
A[设立立陶宛公司UAB] --> B[准备申请文件包]
B --> C[提交申请至立陶宛银行（BoL）]
C --> D[BoL形式审查（2~3周）]
D --> E[实质审查（合规、人员、IT）]
E --> F{是否补件？}
F -- 是 --> G[补件答复 + 重新审阅]
F -- 否 --> H[初步批准]
G --> H
H --> I[ESMA信息注册]
I --> J[发出正式CASP牌照]
J --> K[开始欧盟范围运营]

二、全流程时序安排（标准预估）

阶段 描述 所需时间
✅ 公司注册 立陶宛UAB公司设立、银行开户 1–2周
✅ 文件准备 所有制度手册、高管履历、商业计划书等资料准备 4–6周（建议并行准备）
✅ 提交申请 向BoL线上提交全部材料 即时受理
✅ 初审反馈 检查文件完整性、注册信息一致性 2–3周
✅ 实质审查 审核人员背景、IT合规、AML制度等 4–8周
✅ 补件阶段 反馈问题、补交材料（通常1–2轮） 2–6周
✅ 批准发牌 发出正式批准函，同时提交至ESMA系统备案 1周
✅ 护照通行 可开始向其他欧盟国家备案服务范围 1–2周
 

总计时间预估：4–8个月（含补件与等待时间）

三、实操建议：流程各阶段重点说明

1. 公司注册阶段

  • 建议预设公司章程时即加入“虚拟资产服务”等字样

  • 可与秘书公司同步准备银行开户与审计安排

  • 公司名称、董事、控股结构必须一致于后续申请材料中

2. 文件准备阶段

  • 商业计划书应由熟悉金融术语人员撰写，包含3年现金流预测

  • AML/KYC制度需本地化立陶宛/欧盟法律框架（AML6）

  • 所有负责人需提供CV、AML证书、无犯罪记录（英文翻译）

3. BoL提交阶段

  • 建议使用专业合规顾问进行系统性打包递交

  • BoL目前接受电子方式递交（.pdf格式），签署须为法人或授权代表

四、补件环节的常见问题

补件类型 常见问题说明
人员类 高管履历不详、责任分配不清、MLRO无AML经验
制度类 AML政策未涵盖客户尽调频率、未提及STR识别
系统类 冷钱包权限说明不明、系统流程图不完整、日志机制缺失
商业类 商业计划过于简单、服务边界模糊、未说明收益模型
法律类 控股结构不透明、未提交最终受益人UBO证明
 

补件须于21–30个工作日内回复，逾期将视为主动放弃申请。

五、监管面谈（如适用）

BoL在审查过程中，可能要求部分企业进行在线面谈或实地访谈，尤其是在以下情况：

  • 公司高管不熟悉欧盟合规框架

  • 冷钱包或交易平台服务涉及技术细节复杂

  • 高度集中控股结构，存在外部政治或金融风险

  • 服务范围包含面向高风险国家（如朝鲜、伊朗等）

面谈内容包括：

  • 合规架构解释

  • 系统部署与交易追踪机制演示

  • MLRO职责具体执行流程

  • 资金来源与收益模型说明

⚠️ 建议提前准备“标准面谈问答清单”，并由RO或CEO进行现场答复。

六、牌照发放与ESMA注册

BoL确认企业合规后，将：

  1. 向申请人发出《CASP许可函》

  2. 将企业数据上传至ESMA CASP公开数据库

  3. 通知其可激活“跨境通行护照机制”

  4. 正式成为欧盟注册加密资产服务商（含牌照编号）

七、欧盟通行护照备案路径

企业获牌后，可向BoL提交Passport Notification Form，说明：

  • 希望进入的国家（如德国、法国、意大利等）

  • 所使用语言版本的客户协议/披露材料

  • 是否设立分支机构，或以远程方式运营

  • 服务类型与具体执行方式

BoL将代为通知ESMA与对方国家监管机关，无需二次申请。

八、结语：提前部署 = 加快获批

MiCA流程虽相较原VASP制度更严格，但其流程稳定、标准明确。申请人若在准备阶段即可：

  • 搭建好系统

  • 明确好服务边界

  • 完善好人员与制度配置

则有机会在4–6个月内快速获牌，实现抢占欧盟市场先机。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第七篇章：MiCA牌照申请文件清单与文档编制建议（附模板说明）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA申请文件的总体原则

MiCA牌照的申请文档分为三大核心维度：

✅ 公司及结构性资料（公司成立、股东结构、人员背景）
✅ 合规与制度性文件（AML/KYC、运营规则、客户指引）
✅ 技术与系统说明材料（钱包架构、权限流程、交易日志）

⚠️ 所有文件必须为英文或立陶宛语版本，并尽可能使用PDF+Apostille盖章文件或官方认证件。

二、立陶宛银行（BoL）官方文件清单（标准结构）

编号 文件名称 是否强制 内容说明
1 公司注册文件（Certificate of Incorporation） ✅ 包含公司名称、编号、注册日期
2 公司章程（Articles of Association） ✅ 须包括CASP服务经营范围
3 控股结构图（Shareholding Structure Chart） ✅ 标明股东、最终受益人、股份比例
4 最终受益人声明（UBO Declaration） ✅ 可使用标准模板，附签字页
5 董事及高管履历（CVs） ✅ 英文版本，包含教育与工作背景
6 无犯罪记录证明（Police Clearance） ✅ 不超过6个月，附英文翻译
7 护照扫描件 ✅ 高管、股东所有关键人员
8 AML/KYC政策手册（Anti-Money Laundering Manual） ✅ 详述尽调流程、STR机制、报告义务
9 合规官任命书（MLRO Appointment Letter） ✅ 指定MLRO及职责说明
10 商业计划书（Business Plan） ✅ 包含业务模式、服务范围、三年财务预测
11 IT系统说明书（IT System Description） ✅ 系统架构、权限管理、冷钱包机制等
12 客户适当性评估政策（Suitability & Risk Disclosure Policy） ⚠️ 推荐 特别适用于投资顾问类服务
13 投诉处理机制（Complaint Handling Policy） ✅ 客户投诉受理、处理流程、责任人设定
14 内部控制制度说明（Internal Control Policy） ✅ 涉及审计机制、合规稽核等
15 STR报告流程图（Suspicious Transaction Flowchart） ⚠️ 推荐 系统如何识别并处理可疑交易
16 技术团队简介（Tech Team Background） ⚠️ 推荐 如为外包或使用SaaS平台，需列明供应商信息
17 法律意见函（Legal Opinion on Structure） ⚠️ 可选 对结构、监管适用范围提供法律意见（可由律师事务所出具）
18 财务预测表（3年） ✅ 包括收入来源、成本支出、盈亏平衡点
19 审计师任命函 ✅ 指定注册会计师进行年度审计
 

三、文档编制实务建议

✅ 建议采用如下文档格式标准：

项目 要求
格式 PDF为主，部分可为Word（便于签署）
文件命名 使用英文 + 文件编号（如：07_MLRO_CV.pdf）
目录清单 提交前列明所有文档清单（Document Index）
提交方式 BoL接受电子方式（USB Drive / Secure Upload）
封面封底 商业计划书、制度手册建议封面设计专业、含公司LOGO
多语版本 所有关键文件建议提供英文+立陶宛语双语版（或官方翻译）
 

四、文件模板建议（关键文件包）

以下建议申请人使用预设模板编制，有助于通过审查：

文件 建议使用模板说明
AML/KYC手册 遵循AMLD6框架，分章叙述客户尽调、风险等级分类、STR判断标准、培训制度、记录保存期限
商业计划书 应包含：公司背景、市场定位、竞争分析、目标客户、产品描述、合规路径、财务预测
冷钱包权限图 权限分层（签名权1/2/3级）、每日限额、热/冷钱包切换机制、安全备份协议
STR流程图 客户行为识别 → 系统警报 → MLRO初审 → STR上报监管（BoL或FIU）
技术架构图 包含系统登录、API对接、KYC流程、日志存储、灾备节点、服务器部署国家（EU内）
财务预测表格 年度收入（按服务类型） + 成本项（人力、合规、IT） + 资本支出计划
 

五、审查时BoL特别关注的文件维度

类别 BoL特别关注要素
AML/KYC制度 是否包含可执行性条款、是否符合欧盟标准、是否有STR执行流程
UBO结构图 股东是否穿透、是否存在高风险国家路径、是否有境外信托或匿名公司
IT系统描述 冷钱包说明是否清晰、权限是否有分层、是否有灾备与恢复说明
商业计划 收益模型是否真实、服务是否含高风险国家、是否过度依赖关联交易
MLRO履历 是否具AML背景、是否具备实际经验、是否常驻立陶宛或能有效履职
 

六、文件准备阶段推荐时间安排表

周次 准备项目 输出物
第1–2周 公司注册完成 + 拟定章程 公司章程草案 + 股东结构图
第3周 人员筛选 + 背景材料收集 CV + 无犯罪证明 + 证件扫描
第4–5周 制度手册初稿编写 AML/KYC政策草稿 + 客诉机制
第6周 IT架构图 + 系统说明书 架构图、钱包权限说明书
第7–8周 商业计划书撰写 市场分析 + 财务预测表
第9周 审核+润色 + 法律意见稿 全套申请包形成
 

七、结语：文件清晰 = 审查快速

MiCA的本质是一套制度型监管系统，所有监管判断均来源于文档中呈现的信息。申请人应避免“文件形式化”，应通过专业顾问梳理逻辑清晰、具实操性的文件结构，以缩短审查时间。

建议预制完整文档包，并附清单及文件交叉引用索引表，以专业形象应对BoL审核。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第八篇章：MiCA系统合规要求与冷钱包权限架构（含分层权限图示）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA对系统合规的基本要求

MiCA 明确要求 CASP（加密资产服务商）必须建立可验证、可审计、具备操作控制的技术系统，以保障客户资产安全、防止数据泄露与滥用。其核心原则包括：

✅ 安全性（Security）
✅ 可追溯性（Auditability）
✅ 权限控制（Access Control）
✅ 数据本地化（EU Hosting）
✅ 容灾与恢复机制（Disaster Recovery）

二、冷钱包与IT系统适配：监管强关注点

MiCA下，“钱包托管服务（Custody）”需满足如下技术性监管要求：

模块 监管要求 补充说明
钱包类型 强烈建议使用冷钱包 热钱包如无法证明安全性则不可批准
签名机制 建议多签（Multi-Sig）或MPC签名控制 包括角色分层、私钥碎片、联合授权等
权限控制 必须分设不同签名权限等级 见下文图解
存取日志 每一次钱包操作需记录操作者、时间、操作对象 5年以上保留
钱包恢复机制 需文档化说明“主密钥丢失后如何恢复” 含应急预案
钱包与交易系统隔离 前端交易系统不得直接调用签名操作 需中间层接口管理

三、冷钱包权限架构：MiCA推荐模型（图解）

以下为MiCA合规推荐的钱包权限分层结构：

flowchart TB
A[系统管理员（Security Admin）]
B[运营人员（Operator）]
C[合规负责人（Compliance Officer）]
D[审计专员（Audit Viewer）]
E[冷钱包]

A -->|多签1/3权| E
B -->|多签1/3权| E
C -->|多签1/3权 + 交易批准| E
D -->|查看权限| E

note right of A
系统管理员：配置钱包权限、设定签名规则  
不能单独发起交易
end

note right of C
合规负责人：负责交易审查与手动批准
拥有关键签名权
end
 

关键说明：

  • 所有出金交易必须至少由3人中任意2人联签（2-of-3 MultiSig）

  • 审计专员仅具查看权，不参与签名

  • 所有签名操作应留痕（含IP、时间戳、设备ID）

四、技术系统的其他合规模块

1. 日志记录与审计接口

  • 所有用户操作、登录行为、异常访问等应自动生成日志

  • 审计日志不可修改、必须加密存储

  • 建议接入审计系统（如SIEM）

2. 客户资产与公司资产分离

  • 不得混合账户

  • 系统数据库需标识客户ID + 对应钱包地址映射

  • 会计系统应同步显示资产归属（客户/公司/手续费）

3. 交易指令与自动化限制

  • 用户发起交易 → 系统初审 → 冷钱包层面授权

  • 禁止用户直接触发私钥签名

  • 建议设置每日限额、地址白名单机制

4. 数据存储要求

  • 客户敏感数据（KYC资料、交易记录等）须加密存储

  • 数据中心建议位于欧盟地区（AWS Frankfurt、Hetzner等）

  • 设置至少每日备份 + 每周冷备份，异地冗余存储

五、灾备与应急响应制度要求

MiCA要求所有系统必须具备：

模块 要求
灾备服务器 至少1台异地部署（EU内）
应急演练记录 每半年一次冷钱包模拟恢复演练
系统停摆预案 应对系统被攻击/故障后，客户如何取回资产
联络机制 合规负责人、技术负责人24小时应急联络清单
 

应急方案须编写为正式文档（Disaster Recovery Manual），递交BoL审查备案。

六、冷钱包系统架构与供应商选择建议

✅ 可选工具或服务商

名称 类型 是否符合MiCA推荐架构
Fireblocks MPC钱包托管平台 ✅ 可，建议附合规说明书
Ledger Vault 冷钱包硬件方案 ✅ 建议多签架构+用户隔离
Gnosis Safe 多签Web3钱包 ⚠️ 需自部署与审计
BitGo 托管+多签服务 ✅，需补充监管报告接口说明
 

七、系统说明书建议内容结构（Template）

1. 系统架构图（Architecture Overview）

  • 描述客户端、服务端、API接口、中控节点结构

2. 钱包权限架构（Key Management Policy）

  • 谁持有私钥？如何备份？如何授权？如何冻结权限？

3. 权限角色定义（Access Control Matrix）

  • 管理员、操作员、审计员、客服等具体权限分工

4. 安全机制说明

  • 登录验证机制（MFA）、IP访问控制、日志审计机制

5. 日志与数据保留说明

  • 保存方式、留存年限、加密方式、审计人员访问路径

6. 应急机制与灾备方案

  • 冷钱包重建路径、应急联系、替代服务说明

八、监管机构常见技术审查问题（模拟问答）

问题 答案示例
钱包签名权限是否有分层？ 是，我们采用3层权限：Admin / Operator / Compliance，需2-of-3联合签名
是否可追踪每一笔资产转移？ 是，日志系统保留每次操作、签名人、IP、设备信息
数据中心是否设在欧盟？ 是，托管于AWS Frankfurt，附有证明文件
发生系统崩溃后客户资产如何保障？ 已部署灾备节点 + 密钥恢复路径，附操作文档与演练记录
 

九、结语：MiCA系统要求不仅是技术问题，更是合规证明

在MiCA架构下，系统本身就是合规主体的一部分。监管者审查的不是代码，而是系统架构是否有足够的防控机制、权限分层、操作记录与恢复能力。

企业应提前准备《IT系统说明书》《权限流程图》《冷钱包操作规范》，并视情况使用外部托管商辅助降低风险。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第九篇章：MiCA牌照维护义务与年审机制（合规报告 + 事件通报 + 审计）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA持牌后不是终点，而是监管持续起点

MiCA条例在第6章、第7章和第8章中，对持牌后企业的持续义务作出了详细规定。获得CASP（Crypto-Asset Service Provider）牌照的公司，必须履行一系列合规运营与信息通报责任。

其核心原则为：

✅ 主动报告（Report）
✅ 及时通知（Notify）
✅ 可审计（Audit）
✅ 稳定运营（Sustain）

二、年度监管义务总览表

项目 说明 提交频率
年度财务审计报告 经注册审计师出具的年度财报 每年1次
年度合规报告（Compliance Review） MLRO与合规官联合提交的合规执行总结 每年1次
客户投诉报告（Complaint Summary） 包括投诉内容、处理结果、改进措施 每年1次
可疑交易报告汇总（STR） 上年度提交STR数量与摘要 每年1次
内部培训记录（AML Training Log） 员工AML培训内容、出勤记录 每年1次
冷钱包演练记录 模拟恢复过程与系统演练流程记录 每年1次
客户适当性机制报告 投资建议类服务需提交评估标准执行情况 每年1次

所有报告建议使用ESMA统一格式模板 + 立陶宛BoL本地报告格式双版本。

三、重大事件即时通报机制（Trigger Reporting）

MiCA要求一旦发生以下情况，必须在5个工作日内通报BoL（立陶宛银行）并备案至ESMA：

1. 高级管理层变动（如CEO、RO、MLRO辞任）

  • 通报内容包括：变动原因、新任人选资料、过渡安排说明

  • 附件包括：辞任信 + 新任简历 + 任命书

2. 控股股东变更 / 股权结构变动 ≥10%

  • 附提交新UBO结构图、KYC信息、资金来源说明

3. 新增服务类型（如增加ICO承销、交易平台）

  • 需补充系统流程图 + 客户协议更新 + 合规机制文件

4. 发生数据泄露 / 钱包被攻击事件

  • 附安全事件报告、影响评估、补救计划与客户通知方案

5. 客户资金出现无法兑付或冻结风险

  • 启动临时运营通报机制 + 说明保障客户资产措施

所有通报应通过 BoL CASP监管平台 提交，并同步邮件与PDF备案。

四、审计机制与监管抽查制度

MiCA要求所有CASP持牌企业每年指定注册审计师出具审计报告，内容包括：

审计领域 审查内容
财务审计 资产负债表、收入成本、资本金是否达标
客户资产独立性审计 客户资产是否与公司账户隔离管理
冷钱包流程审计 是否符合文档操作机制、权限是否有迹可循
交易日志审计 是否存在篡改、缺失、无记录情况
STR执行审计 是否每笔可疑交易均有识别、上报与记录
AML制度合规性审计 政策是否更新、是否符合欧盟AMLD6要求
 

⚠️ 审计师需具备欧盟成员国会计师协会认可资格，且不得与公司存在股权或雇佣关系。

五、合规官（Compliance Officer）与MLRO的年内职责

MLRO职责维度（每月/季度/年）

频率 内容
每月 检查交易异常情况、更新黑名单
每季度 员工AML再培训、系统STR接口测试
每年 完成AML年度报告、提交政策更新摘要至董事会

合规官职责维度

频率 内容
每月 跟踪MiCA更新、内部自评制度落实情况
每季度 召开合规会议，评估政策执行力度
每年 编制《MiCA年度合规责任履行报告》，供董事会与监管查阅

六、通报义务不履行的法律后果

情况 后果
未提交年报 首次警告，逾期2次将处以罚款或暂停经营
隐瞒重大事件 可直接吊销CASP牌照，并列入ESMA风险企业名单
冷钱包失控未报告 视为严重失职，可能追究MLRO个人法律责任
拒绝配合审计 BoL将发出30天限期整改通知，逾期可能撤销牌照

七、合规维护建议与日常运营模板

建议持牌企业建立以下维护机制：

✅ 年度计划表：标明审计、合规报告、客户回访节点
✅ 合规事项登记簿：记录每次制度更新、培训安排、客户投诉等
✅ STR识别与响应流程表：自动标记 + 手工确认 + MLRO提交登记
✅ 合规培训日志模板：记录每位员工培训课程与签收
✅ 客户资产归属月度对账表：客户资产余额 + 匹配托管地址
✅ 年报生成日程安排模板：审计师、合规官、财务协调进度表

我可为您生成以上模板文档（Word/Excel/PDF），用于快速搭建合规运营框架。

八、结语：MiCA合规是一场持续“马拉松”

MiCA不是一次性项目，而是一个持续合规、长期监督、周期审查的系统化制度。持牌企业必须有意识地从“牌照申请思维”切换到“合规经营思维”。

建议指派专职人员持续追踪 ESMA 公告、BoL更新、AMLD修订，并与合规顾问定期核查。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第十篇章：MiCA牌照申请常见问题FAQ大全（官方角度 + 实操问答）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本章节收录监管机构、实操团队及申请人最常见的MiCA牌照申请相关问题与解答，按不同主题分组，涵盖法规适用、流程实务、合规细节、技术系统、人员配置等方面，供拟申请人参考。

一、基础法规与适用范围类

Q1：MiCA适用于哪些类型的加密资产服务？

答：MiCA适用于以下10种加密资产服务（CASP）类型，包括托管钱包、交易撮合、法币兑换、加密资产兑换、ICO代币发行、自营交易、建议服务等。详情见第四篇章。

Q2：MiCA适用于稳定币吗？

答：MiCA对稳定币分为两类监管：

  • EMT（电子货币型代币）：锚定单一法币，类似USDC、EURe等；

  • ART（资产参考型代币）：锚定一篮子资产，如Libra模式。
    ⚠️ 若企业是发行方而非服务商，应遵循MiCA第2章、3章关于白皮书、储备金管理、担保机制等规定。

Q3：MiCA对NFT或DeFi是否适用？

答：

  • NFT：若确实为唯一性、不可分割、无金融属性（如游戏道具、收藏卡），可豁免。否则可能被监管认定为加密资产。

  • DeFi：MiCA目前未全面纳入DeFi协议监管，但若由中心化平台提供DeFi网关服务（如提供流动性聚合），仍适用MiCA许可要求。

二、公司注册与申请流程类

Q4：MiCA牌照必须设立本地公司吗？

答：是，申请MiCA必须在欧盟境内设立实体法人。以立陶宛为例，需设立UAB公司，拥有本地注册号、法定地址、银行账户等。

Q5：MiCA牌照可否远程申请？

答：可以。公司注册、文件准备、资料提交均可远程完成。但须指定一名本地负责人，并具备合规顾问或代表地址。

Q6：MiCA牌照审查周期多长？

答：标准流程为4–8个月不等，包含：

  • 初审受理：2–3周

  • 材料审查：6–10周

  • 补件环节：1–2轮

  • ESMA注册与通知：约1周
    ⚠️ 审查时间受材料完整度、项目复杂度影响较大。

三、人员配置与适当人选类

Q7：谁必须被列为MiCA牌照关键人员？

答：至少包括：

  • 董事（Director/CEO）

  • 合规负责人（Compliance Officer）

  • 反洗钱负责人（MLRO）

  • 财务主管（可由其他高管兼任）

Q8：MLRO可以是外部顾问吗？

答：理论上可外包，但必须具备以下前提：

  • 明确的聘用关系和责任分配协议；

  • 有足够时间和技术权限履行报告责任；

  • 可接受BoL约谈与系统演示。
    建议优先由内部高管或立陶宛常驻顾问担任。

Q9：人员可否不在立陶宛境内？

答：可远程，但需提供有效控制和参与运营的说明，如：

  • 每周工作时长与管理内容；

  • 远程权限机制与决策参与结构；

  • 本地联系人或协作顾问说明信。

四、系统与冷钱包技术类

Q10：MiCA是否强制使用冷钱包？

答：托管服务商必须提供冷钱包架构，采用多签/MPC签名机制，并具备权限分层、恢复机制、日志记录等合规控制。

Q11：是否必须自行开发钱包系统？

答：不强制。可使用第三方托管商（如Fireblocks、BitGo等），但需提交：

  • 权限流程说明；

  • 访问与签名策略；

  • 第三方合规声明与服务协议。

Q12：是否必须部署系统服务器于欧盟？

答：是。所有客户信息、合规日志、KYC数据必须存储于欧盟或等效GDPR数据保护区域。
⚠️ 建议使用 AWS Frankfurt、Hetzner、OVH France 等合规节点。

五、财务与资本金类

Q13：MiCA对注册资本要求是多少？

答：视服务类型而定，常见如下：

  • 钱包托管、交易平台：€125,000–150,000

  • 一般中介服务（传递指令、执行交易）：€50,000–€75,000
    ⚠️ 资金须为实缴资金，并提供银行资金来源说明。

Q14：资本金可以做营运资金吗？

答：可以，但需维持最低监管资本余额，避免侵蚀后影响审计报告。建议设立运营账户+合规资本账户分离。

六、牌照使用与维护类

Q15：MiCA牌照可以在哪些国家使用？

答：可在所有欧盟成员国 + EEA国家（挪威、冰岛、列支敦士登）跨境通行。需通过立陶宛BoL向ESMA提交通行备案（passporting notification）。

Q16：牌照有效期是多久？

答：MiCA牌照长期有效，但须满足持续经营条件，包括：

  • 按时提交年审材料；

  • 未违反监管义务；

  • 未发生重大经营风险或股东异常。

Q17：若停止业务或撤出欧洲怎么办？

答：必须提前30天通知监管机构，制定客户资产结算与退出计划，注销ESMA备案并关闭在运营服务。

七、实际操作建议类

Q18：我已持有VASP，是否需重新申请MiCA？

答：是。MiCA将取代所有现有国家VASP制度。2025年6月30日前，必须完成转牌或重新申请，逾期视为无证经营。

Q19：申请时建议申请几类服务？

答：建议根据企业现阶段能力，选择3–5类服务组合。例如：

  • 托管 + 法币兑换 + 撮合交易；

  • 自营交易 + 分析建议 + 客户指令执行。
    ⚠️ 若服务类型过多，系统文档需分别覆盖每一项合规职责。

Q20：能否一次申请多个EU国家运营？

答：MiCA结构下，不需要分别申请。只需在立陶宛获批后，通过BoL向ESMA备案目标国家，即可跨境运营。

申请合规牌照 l 合规审查维护 l 合规监管服务-仁港永胜

Q21：MiCA牌照申请是否要求设立董事会？是否必须设立监事？

答：MiCA并未强制要求设立董事会或监事会结构，但立陶宛作为实施地，其公司法要求UAB（私营有限公司）最基本需有董事（General Manager）。
如公司拟设立多名高管，建议设立“决策委员会”（Decision Committee）并制定相应职权架构图，在提交组织结构时向BoL呈报，有助于展示内部控制清晰。

Q22：MiCA下提供“加密资产托管服务”是否必须100%冷钱包？

答：不强制100%，但需说明热/冷钱包分层结构与风险控制措施。监管更关心：

  • 客户资产是否与自营资产隔离

  • 是否存在客户损失先行赔付机制

  • 冷钱包的权限是否分级、可审计

常见合规结构：95%冷钱包 + 5%热钱包，热钱包每日限额+日志保留。

Q23：若申请MiCA牌照失败，会影响以后重新提交吗？

答：如因材料不充分而“撤回”申请，一般不影响后续重新递交。
但如被正式“拒绝”（rejection），则：

  • BoL会保留备案；

  • 需说明前次失败原因；

  • 需修改实质内容后方可重申。

建议如材料准备不充分，可在“反馈阶段”主动撤回，以保留信誉。

Q24：MiCA牌照是否必须披露最终受益人（UBO）？

答：是的。
UBO（Ultimate Beneficial Owner）披露是AML第6号指令（AMLD6）+ MiCA共同规定内容。必须：

  • 披露控制25%以上股份/表决权的自然人；

  • 如为法人穿透结构，需逐层穿透图解；

  • 所有UBO需提供KYC、无犯罪记录证明（如NBI、Police Check等）。

Q25：MiCA是否适用于DeFi？如DAO项目是否也要申请？

答：MiCA法规明确不适用于“完全去中心化”服务，但只要存在中心化接口或人员控制，就落入MiCA适用范围。
DAO如设有平台运维团队/前端/代币发行/钱包管理/上线交易等，仍须注册为CASP。

监管思路是：“功能中心化”大于“名义去中心化”。

Q26：是否必须任命MLRO？可以由外部顾问担任吗？

答：MiCA未强制使用“MLRO”术语，但在立陶宛本地合规标准中，CASP公司若涉及客户资产管理、交易撮合、托管服务等，必须指定AML负责人，且：

  • 须具有立陶宛或欧盟相关经验

  • 具备AML专业认证（如CAMS/CICA等）更佳

  • 不建议外包，应为公司董事或中高层雇员

⚠️ 外部顾问可辅助编制AML政策、培训、审计，但不宜充当MLRO角色。

Q27：MiCA牌照获批后，可否“转让”或出售公司？

答：不可直接“转让牌照”，但可通过股权变更的方式转让持牌公司。但须注意：

  • BoL必须事前批准控股权变更；

  • 买方股东、董事需重新KYC审查；

  • 需提交《新股东尽调材料》《变更说明函》《商业合理性说明》。

建议提前咨询BoL是否接受该结构，不建议短期内“倒壳操作”。

Q28：MiCA监管是否适用于NFT平台？是否需要申请牌照？

答：MiCA原则上不监管“唯一性、不可分割”的NFT资产，但：

  • 若平台出售大量可交易化、具有金融属性的NFT（如：Fractional NFT、收益绑定NFT），可能被视为“加密资产”；

  • 平台如提供NFT交易、钱包托管、客户资产管理，亦需申请MiCA牌照。

监管判定关键点在于：是否具金融属性 / 是否可流通 / 是否客户资产

Q29：申请MiCA时是否建议提交法律意见函？是否必须？

答：非强制性，但强烈建议提供。合格法律意见函应包括：

  • 是否属于MiCA下的“加密资产服务”

  • 申报服务类型与法律框架对应说明

  • 公司结构是否符合MiCA要求

  • 由持牌律师出具、加盖律所章

若有复杂业务、跨境结构或委托模式，BoL常要求提供专业法律说明。

Q30：MiCA合规审查时是否会进行现场面谈？如会，面谈内容主要有哪些？

答：部分案例中，BoL会要求对负责人/RO/MLRO进行远程或现场面谈，内容包括：

  • 对申请服务内容的理解（交易、托管、执行）

  • AML制度落实细节

  • IT系统如何支持风控与合规记录

  • 公司日常合规管理是否能有效运行

  • 谁负责做出客户准入判断

建议事前准备模拟面谈资料，可由专业顾问辅助。

Q31：MiCA是否要求设立独立的风险管理部门？

答：MiCA并未明确强制设立“独立的风控部门”，但若公司开展如以下服务：

  • 客户资产托管

  • 加密交易撮合

  • 客户资产转移（如：Swap、DEX挂单撮合）

则在申请阶段需提交内部风险管理机制描述，内容应覆盖：

  • 市场风险 / 操作风险 / IT系统故障 / 黑客攻击的应对机制

  • 如何识别可疑交易与欺诈行为

  • 谁对风险限额负责，是否有风控报告机制

⚠️ 中小型CASP企业可由合规官兼任风险识别岗，但必须制度化记录流程。

Q32：MiCA牌照是否要求定期做IT系统审计？可否由第三方完成？

答：MiCA并未硬性规定“IT系统审计”频次，但：

  • 若运营交易平台、托管客户资产，建议每年至少一次系统渗透测试或外部审计

  • 审计报告应说明权限分层、冷钱包安全、多签机制、日志记录可追溯性

建议使用第三方技术公司执行，并向BoL备案审计报告摘要（非强制，但提升透明度）。

Q33：MiCA牌照持牌人是否需缴税？立陶宛有哪些税种适用？

答：是的，MiCA牌照公司为立陶宛UAB公司，需按以下税种缴纳：

税种 税率 说明
公司所得税（CIT） 15%（小型企业可享5%） 年利润纳税
增值税（VAT） 21% 若服务对象为欧盟个人，视为应税服务
工资税（含社保） 雇主约30.98% 支付员工工资时
 

⚠️ 若业务为B2B对欧盟外客户，部分收入可享“VAT豁免”。建议配合本地税务顾问报税。

Q34：MiCA公司是否可同时提供虚拟资产与法币服务（如：兑换欧元）？

答：可行，但若涉及“法币收付、转账”，需考虑是否触发EMI/PI（电子货币机构/支付机构）牌照要求。

典型合规结构为：

  • MiCA CASP提供加密资产相关服务

  • 法币部分通过第三方支付机构或EMI合作（白标、API集成等）

如公司希望自建欧元支付系统，建议同步申请EMI牌照，或与立陶宛EMI公司合作挂载账户。

Q35：MiCA申请是否允许多个自然人联合持股？股东是否需证明资金来源？

答：允许联合持股，但：

  • 所有持股比例超25%的自然人/法人，需提交KYC、无犯罪证明

  • 所有实缴出资方，需提供资金来源声明（Source of Funds）

  • 若资金来源复杂，BoL可能要求银行流水或资产证明文件

股东资金路径必须清晰、合法，禁止使用匿名加密资产作为实缴出资。

Q36：MiCA申请中如何向BoL解释“业务合理性”？必须提交哪些商业计划细节？

答：BoL非常关注“商业合理性”，建议商业计划包含：

  • 明确服务范围对应MiCA条文

  • 盈利模式说明（如何收费）

  • 客户群体定位（欧盟 vs 非欧盟）

  • 系统建设规划（含合规与风控）

  • 合作方/托管安排说明

  • 资金预计流向、三年盈利预测

商业计划书需专业、清晰，避免套模板，最好附行业对标案例。

Q37：MiCA申请过程中是否可以更换董事或负责人员？

答：在BoL审批过程中不建议更换核心人员，尤其是：

  • MLRO（反洗钱负责人）

  • RO（主要负责人）

  • 高管或法人代表

如必须变更，需提交：

  • 新任人员的简历、KYC、专业履历

  • 变更说明函及过渡安排

建议提前沟通BoL，说明合理性，避免审查中断或驳回。

Q38：MiCA牌照能否用于Token发行？是否能合法进行ICO？

答：MiCA允许加密资产服务商进行“发行承销”，但需满足：

  • 项目代币符合MiCA定义的“crypto-asset”

  • 提交白皮书（Whitepaper）至监管备案

  • 不得宣传保本、收益承诺等内容

  • 若为EMT/ART类代币（即稳定币类），则需单独注册为发行机构（Issuer）

ICO/IEO项目建议嵌入MiCA持牌公司作为平台背书并合规进行技术对接与披露。

Q39：MiCA公司是否需设置客户投诉机制？必须写入内部制度吗？

答：是的，MiCA规定客户保护机制是审查重点之一，需：

  • 明示客户可投诉通道（邮件、电话、平台入口）

  • 客户投诉受理流程、时限、责任人

  • 设立投诉记录表、处理决定备案

⚠️ 建议制度手册中单列《投诉处理机制》章节，并每年总结报告。

Q40：MiCA牌照申请可否借用已有VASP架构？是否可过渡？

答：可行。立陶宛BoL允许已有VASP持牌公司“升级”为MiCA CASP，步骤包括：

  • 提交新申请（不能自动转化）

  • 附上过往合规历史、运营报告

  • 声明VASP期间无违规、客户赔付记录

  • 调整AML/KYC/IT制度以符合MiCA框架

过渡申请会获得更高通过率，审查时间亦可能更快。

Q41：MiCA牌照可以服务哪些国家？英国/瑞士/香港客户是否允许？

答：MiCA牌照本质是欧盟内部统一通行牌照，主要适用于服务欧盟境内自然人和法人。

  • 可服务：所有**欧盟+欧洲经济区（EEA）**国家的客户（30国）

  • 非强制限制：服务欧盟以外客户（如：英国、瑞士、香港）目前未被禁止，但应：

✅ 披露该客户非欧盟辖区，服务对象属自愿性质
✅ 明确“非推介 / Not Solicited”声明，避免视为非法招揽
✅ 建议建立“海外客户KYC适当性模型”，管理风险国籍与高风险地区

⚠️ 若在香港或英国做主动营销，可能需触发该地牌照要求。

Q42：冷钱包如果遭遇意外损毁或被盗，监管会如何处理？

答：MiCA框架强调客户资产隔离与冷钱包保障机制，若发生损毁或盗窃事件：

  1. 立即通报BoL（Bank of Lithuania）与ESMA

    • 属“重大事件报告”范畴，需于事件发生后24小时内通报初步情况

  2. 启动灾备/恢复机制

    • 所有MiCA持牌公司需建立冷热备份 + 多重签名体系

    • 若冷钱包受损，需展示替代冷钱包资产保全方案

  3. 客户赔付机制启动（如适用）

    • 若客户资产受影响，必须执行公司赔付或保险兜底计划

建议投保专业加密资产冷钱包保险，如Lloyd's、Coincover等承保产品。

Q43：MiCA是否限制代币类型？某些DeFi Token是否不被承认？

答：MiCA将加密资产分为三类：

  1. EMT（电子货币型代币）

  2. ART（资产参考型代币）

  3. 一般Crypto-assets（如效用型代币、平台币等）

⚠️ 若DeFi项目Token符合下列任一特征，可能不纳入MiCA监管：

  • 完全去中心化、无发行人、不涉平台撮合

  • 无实际控制权方，代码运行即自治（如纯DAO治理Token）

但一旦平台存在：

✅ 发币者
✅ 可提供交易/托管/咨询服务
✅ 代币具备“投资、承诺回报、投票权”等属性

即被视为受MiCA监管资产，需纳入CASP框架。

Q44：MiCA牌照公司可否为其他交易所提供白标服务？

答：可行。MiCA法规允许牌照公司为他人提供API / 白标平台支持，前提是：

  • 最终客户关系明确（是否属MiCA持牌方）

  • 客户数据是否隔离、托管安全说明是否完整

  • 第三方业务方是否接受MiCA合规监控/配合反洗钱措施

建议签署《白标技术与合规协议》（White-Label Agreement），约定：

  • 数据归属

  • 责任划分

  • AML协作机制

  • 客户投诉处理与STR责任分担

Q45：MiCA持牌公司能否自营Token、上市自家币种？

答：可以，但必须明确角色区分：

  1. 若MiCA公司为代币发行人（Issuer），需：

    • 提交白皮书并备案

    • 明确代币性质、流通机制、底层逻辑

    • 避免误导投资者或承诺保本

  2. 若MiCA公司运营平台 + 发行Token，需向BoL提交冲突管理策略（Conflict of Interest Policy）

⚠️ 不得同时担任Token承销商、交易平台撮合者、咨询顾问与自营做市者。

Q46：RO（主要负责人）与MLRO（反洗钱官）可以是同一个人吗？

答：理论允许，但需满足以下条件：

  • 该人员必须具备两个职能的独立履职能力

  • 公司规模较小（≤10人）、无复杂交易结构时可合并

  • 合规制度中需清楚列出两角色职责，并设交叉监督机制

BoL更倾向于两名独立人员，分别担任RO与MLRO，防止内部监督失效。

Q47：MiCA持牌公司是否必须每年进行员工合规培训？如何证明？

答：是的，MiCA要求：

  • 每年至少1次面向员工的AML/KYC培训

  • 新员工上岗前必须完成合规学习

  • 培训记录应归档，包括：

    • 培训内容（教材、录制视频）

    • 参与人员名单

    • 培训签到与考试记录

    • 培训总结评估报告

BoL或ESMA有权在现场稽核时抽查培训记录。

Q48：MiCA公司账户必须在立陶宛银行开设吗？虚拟IBAN可否接受？

答：不强制必须是立陶宛银行账户，但应满足：

✅ 公司运营资金账户设于欧盟受监管银行或EMI机构
✅ 客户资金托管账户需与自有账户分离，并具备可追溯性
✅ 接受虚拟IBAN（如Bankera、Revolut、Paysera等）前提是该机构合规受监管

⚠️ 强烈建议开设立陶宛本地银行或EMI账户，便于审计、KYC及监管协调。

Q49：MiCA实施后，欧洲其他国家会废除自己的VASP制度吗？

答：是的。MiCA作为欧盟统一框架，将：

  • 自2025年6月起，全面替代各成员国原有VASP制度

  • 各国监管机构需逐步清理旧VASP列表，并迁移至ESMA统一CASP名录

  • VASP与MiCA并存将不再允许（最多有18个月过渡期）

建议所有拟申请者优先迈入MiCA结构，避免重复注册。

Q50：MiCA框架下，如何处理客户的"Token被盗索赔"？平台需负何种责任？

答：MiCA框架鼓励平台建立：

  • 明确客户资产托管边界与责任说明书

  • 对冷钱包事故/黑客入侵/权限泄露等建立赔付机制或保险兜底

  • 如因平台过失导致客户Token被盗，MiCA牌照公司需承担法律与经济责任

建议设立以下机制：

✅ 客户资金与平台资产隔离
✅ 全面日志记录
✅ 黑客攻击应急处理预案
✅ 赔偿流程书面载明 + 投保专业险种

Q51：MiCA持牌公司若员工离职，权限如何回收？是否需报监管？

答：MiCA强调信息安全与权限可控。员工离职后，平台必须：

  1. 立即注销系统访问权限（包括冷钱包权限、多签授权、交易后台等）

  2. 更新系统权限分配记录，保留审计轨迹

  3. 对于涉及MLRO、RO、高管等关键岗位人员：

    • 应提前向监管（BoL）通报其离职计划；

    • 若属于核心人员变更，需向BoL正式报备并提交替代人员材料。

建议制定《员工离职权限注销与数据交接政策》，并每半年内部审查。

Q52：MiCA牌照公司可否服务非洲、南美客户？

答：技术上允许，但须谨慎处理：

✅ MiCA并不限制服务非欧盟国家用户
✅ 但需：

  • 对客户地区风险进行评估（根据FATF名单）

  • 特定高风险国家（如伊朗、朝鲜、缅甸等）应自动拒绝接入

  • 对非欧盟用户需执行强化KYC与适当性审查，保留完整审计日志

提示：部分银行或支付通道可能对非欧盟客户较为敏感，建议提前协调。

Q53：MiCA CASP牌照可否采用SaaS平台提供服务？

答：可以，但需满足下列合规要求：

  • SaaS系统提供方必须通过合规评估

  • MiCA持牌公司必须拥有平台运维控制权与监管可视性

  • 所有客户数据、交易日志、STR模块等应能被BoL审查

⚠️ SaaS白标模式风险较高，监管可能要求本地部署版本或加密通讯协议说明。

Q54：平台Token被多个DEX自动交易时，是否需要额外监管申报？

答：若平台Token被DEX自动添加流动性，MiCA不会强制申报，但：

  • 若该DEX系MiCA公司所控，仍需承担市场秩序维护责任

  • 如Token被用于投资性用途，MiCA可能要求补充说明用途、价格机制等

建议平台在白皮书中声明：是否参与二级市场流动性管理，以厘清法律责任边界。

Q55：MiCA是否允许提供跨境Token发行服务（如帮客户在EU进行ICO）？

答：允许。MiCA允许持牌公司以承销商、顾问、发行技术支持方身份协助第三方在EU发行代币，但需：

  1. 对客户（发币方）做KYC+商业合理性审查

  2. 若代理发行，需协助客户提交MiCA版白皮书备案

  3. 签署合法的代币承销/服务协议，说明角色、费用、风险

建议配套《MiCA版ICO承销服务合同模板》进行操作。

Q56：MiCA持牌公司在开拓业务时是否允许雇佣兼职员工？

答：允许雇佣兼职员工，但需遵守下列原则：

  • 不可让兼职人员担任RO、MLRO、财务负责人等核心岗位

  • 所有人员必须签署保密协议与数据安全协议

  • 即使为兼职，也需完成KYC/AML培训与背景核查

BoL可能在合规稽查中抽查员工角色与职责说明，建议建档留痕。

Q57：MiCA框架下，子公司/分支机构是否允许设在欧盟外？

答：MiCA不禁止在欧盟外设立子公司或分支，但需满足：

  • 所有涉及MiCA服务（托管、交易等）应由持牌主体执行

  • 欧盟外公司不得面向EU客户提供服务（否则视为规避MiCA）

  • 持牌公司需保留对分支的运营与合规管理控制权

建议在法律结构上清晰划分运营主体与辅助服务机构。

Q58：如果平台突然被黑客攻击并下线，多久内要通知监管？

答：根据MiCA + AMLD6，黑客攻击属重大运营事件，必须：

✅ 在事件发生后24小时内向BoL及ESMA报告初步情况
✅ 报告内容需包含：

  • 攻击时间、方式、影响范围

  • 受影响账户/资金初步估算

  • 应急响应步骤与预计恢复时间

  • 后续客户赔付机制与公示计划

⚠️ 延迟报备将被视为重大违规，或影响牌照维持。

Q59：MiCA是否强制设立客户资金隔离账户？如何操作？

答：
强制要求。MiCA明确：

  • 客户资金与公司自有资金必须分离管理

  • 客户资产需设在独立专户或信托账户中

  • 建议设立：

    • 客户托管账户（Client Safeguard Account）

    • 系统应记录每笔客户资金进出并可追踪对账

建议与Paysera、Bankera、Revolut或立陶宛本地EMI合作设置专属隔离账户。

Q60：MiCA CASP牌照的有效期是多久？如何续牌？

答：MiCA CASP牌照为长期有效制，无明确到期时间，但须满足：

  1. 每年通过监管年审（年度报告、审计报告、合规报告）

  2. 未发生严重违规、失职事件

  3. 持续保持实质性运营（如无业务或空壳状态将被吊销）

如需变更公司结构、高管、股权或增加新服务范围，需提前报批。

Q61：如何应对立陶宛央行（BoL）突击现场审查？

答：BoL突击审查通常发生于以下情况：

  • 可疑交易报告过少或异常集中

  • 投诉频发或媒体披露风险事件

  • 注册资料或年报内容存疑

应对建议：

  • 保持文件齐全、结构清晰（建议设立“审查应对资料柜”）

  • 定期模拟突击稽查演练，涵盖系统权限/客户资料/STR报送流程等

  • MLRO应熟悉所有政策细节，能够即时解答监管问题

  • 对外发言统一口径，由指定合规官发言

Q62：如何建立冷钱包权限交接制度，确保监管认可？

答：MiCA对冷钱包的权限控制与交接极为重视：

✅ 实务建议如下：

  • 权限设置应最少三层控制人：技术管理员 + 法务/合规人员 + 审计人员

  • 制定《冷钱包授权变更流程手册》，包括：

    • 申请理由说明模板

    • 原权限注销确认表

    • 新权限审批流（含董事会或RO签署）

  • 所有权限修改应保留“加密日志”与“物理记录”（如硬件更换、交接录像）

Q63：平台上线自发代币（Utility Token）是否可能被视为价格操控？

答：MiCA虽未禁止平台发行自有Token，但若存在如下行为，将被视为操控价格风险：

❌ 利用平台资源刻意引导价格或流动性
❌ 发布未披露风险的宣传材料（误导用户）
❌ 多地址操纵买卖以制造虚假交易量

建议：

  • 建立代币价格机制披露文档（含做市商角色说明）

  • 所有代币上线前应通过适当性评估+合规报告

Q64：MiCA对NFT是否监管？平台是否能开展NFT交易？

答：截至目前（2025年），MiCA对**唯一性NFT（Non-Fungible Token）**未强制纳入监管。

✅ 但以下类型可能被MiCA纳入CASP监管范围：

  • Fractional NFT（可分割NFT）

  • NFT作为支付凭证或权益通证（例如：会员制NFT）

  • NFT嵌入金融收益或承诺（如可赎回收益、返利等）

建议平台清晰分类NFT功能属性，合规备案非传统NFT产品。

Q65：如何合法搭建OTC场外交易服务通道？

答：MiCA允许提供OTC交易服务，但必须满足：

  • 建立客户适当性评估机制（非适合客户不得交易高风险代币）

  • 建立订单匹配与执行记录机制

  • 所有OTC交易需纳入反洗钱监控系统（含大额交易标记）

技术建议：

  • 设立独立的OTC操作后台

  • 每笔OTC交易需有：订单截图 + 双方确认文件 + STR筛查结果

Q66：平台是否必须每年对员工进行反洗钱培训？

答：必须。MiCA联合AMLD6规定：

  • 所有从事客户接触、交易处理、数据分析等岗位的人员需每年最少一次合规培训

  • 内容需涵盖：AML、KYC、STR、客户适当性评估等

  • 需保留培训签到表、培训PPT与测试成绩记录，供监管审查

✅ 建议由MLRO编写《年度合规培训手册》，并保存归档 ≥ 5 年。

Q67：MiCA牌照是否可以转让给其他公司？

答：不可直接转让。MiCA牌照与具体的公司实体、人员结构、系统架构绑定，无法“卖牌”或“转牌”。

如拟被收购或更换股东：

  • 须提前向BoL提交变更申请

  • BoL将重新审查股东背景、资金来源、管理团队适当性

⚠️ 未经批准的控制权变更可能导致牌照吊销。

Q68：平台Token上线前需向监管申报吗？

答：是否需要取决于Token的属性：

✅ 若为投资型代币或具有集资属性，则必须：

  • 提交MiCA版白皮书

  • 向BoL报备及获准上市流程

✅ 若为纯效用型Token（如交易抵扣、内容解锁），可豁免，但建议提交自愿披露说明以供存档，降低未来争议。

Q69：MiCA合规中，哪些行为会导致牌照被吊销？

答：以下行为将触发BoL吊销CASP牌照：

  • 公司长时间无实质性运营（如无客户、无系统、无交易）

  • 高管频繁更换未报备

  • 多次被发现反洗钱制度执行不到位

  • 故意瞒报系统安全事件、资金风险事件

  • 被其他欧盟成员国举报或拒绝Passport接入

建议设立内部合规稽核制度，每季度审查一次关键要素。

Q70：MiCA牌照申请失败后，多久可以重新申请？

答：MiCA条例并未禁止再次申请，但：

  • 一般建议在被拒绝6个月后再重新递交申请

  • 需提交“整改说明信”或“结构优化声明”

如属形式性退件（如文件缺失、翻译问题），则可短期内补件并再次提交。

Q71：客户投诉机制如何合规设置？是否有强制时限？

答：根据MiCA及消费者保护法规，所有CASP必须设立独立的客户投诉处理机制，要求如下：

  • 回应时限：必须在收到投诉后15个工作日内予以正式书面回复；

  • 流程制度：

    • 设立专责人员或团队（通常由合规部承担）；

    • 客户可通过电子邮件、网页表单、实体信件等方式提交；

    • 每一宗投诉需建立编号系统、处理时效记录与结案总结；

  • 记录保存：所有投诉记录应保留至少5年，供监管或审计参考。

⚠️ 建议每年向监管提交投诉统计报表及改进措施。

Q72：可否使用第三方KYC系统（如Sumsub、Jumio）？是否合规？

答：可以，但需符合以下前提：

  • 第三方KYC系统需通过GDPR与欧盟合规技术审查；

  • 合同中明确由CASP对KYC结果最终负责，不得将法定责任外包；

  • 第三方系统提供的所有资料，必须能导出为可审计格式，并存储在欧盟境内或MiCA认可数据区域；

  • 系统应支持与STR报送模块对接，确保可疑交易被识别与及时上报。

建议与KYC供应商签订《监管合规配合协议》（Regulatory Cooperation Clause），附备份存储条款。

Q73：平台内是否可以设置杠杆交易或衍生品？

答：MiCA本身不监管衍生品或杠杆合约（如期货、期权），但一旦提供此类服务：

  • 必须额外取得《欧盟金融工具市场指令（MiFID II）》项下相应牌照；

  • 或在受MiFID许可的交易平台下挂牌该类合约。

⚠️ 若在MiCA CASP架构下私自提供杠杆代币交易，将被视为无照经营金融衍生品，可能构成严重违规。

Q74：公司是否可以通过代理机构（如律师事务所）递交申请？

答：
可以，且属于正常合规流程之一。

条件如下：

  • 须出具授权书（Power of Attorney），注明代理权限范围；

  • 律师代理人必须为在欧盟/立陶宛注册的执业机构；

  • 最终审批过程中，BoL通常仍会要求与申请主体（公司高管）进行面谈或视频会议。

建议由熟悉MiCA法规与监管流程的专业顾问团队（如仁港永胜）全程协助。

Q75：MiCA申请的白皮书是否必须公开披露？披露范围和格式是什么？

答：MiCA对以下两种情况要求披露白皮书（Crypto-Asset Whitepaper）：

  1. 公开募资（ICO/IEO）

  2. 面向零售客户提供代币购买渠道

披露格式要求包括：

  • 代币功能、发行目的、风险因素

  • 投资者权利与责任、管理团队信息

  • 加密资产技术结构、安全机制

披露渠道：官方网站 + MiCA监管信息披露平台 + 提交BoL备案系统

Q76：系统开发外包给海外公司，是否被允许？

答：允许外包开发，但必须满足以下条件：

  • 最终系统部署必须在欧盟境内（立陶宛为佳）；

  • 所有客户敏感数据不得外传至非欧盟国家（符合GDPR要求）；

  • 合同中应含有紧急接管条款（Business Continuity Clause）；

  • 技术文档、权限控制、源代码等关键模块应定期提交备份至公司本地审计组/监管接口。

实务建议：可保留海外开发团队，但关键系统上线后应转移至欧盟团队维护。

Q77：是否可以一次性申请多种CASP服务类型？是否影响审批时间？

答：可以。MiCA允许企业同时申请多项服务类型（如交易平台 + 托管 + 法币兑换等）。

但需要注意：

  • 申请材料需针对每一项服务提交单独合规说明书、系统架构与内控制度；

  • 审批周期相应延长，通常需6–9个月；

  • 初始资本金需满足最高门槛，如150,000欧元（交易所类）。

⚠️ 实操建议：如团队经验有限，可先申请1–2项基础服务，获批后再逐步扩展。

Q78：平台是否可同时开展加密支付网关业务？如何合规？

答：可以，但MiCA要求以下条件：

  • 平台须注册“法币兑换服务”与“传输加密资产服务”两项CASP类别；

  • 若提供与第三方商户对接服务，需建立反洗钱合作机制；

  • 合同中须规定客户资金流向、结算路径、安全机制；

  • 必须支持用户身份核实（非匿名支付网关）。

建议参考Stripe、Checkout.com等合规结构，建立“钱包对钱包”清结算路径。

Q79：公司实际控制人发生变化，是否必须提前通知？

答：是的，MiCA强制要求：

  • 若股权变化导致控制权变动（通常指持股25%以上的UBO），必须提前30天向BoL递交变更申请；

  • 新UBO需提供完整KYC、资金来源、合法背景证明；

  • 审查通过前不得实际交接控制权。

⚠️ 未申报即更换UBO或控制股东，属于重大合规违规事项，可能被吊销牌照。

Q80：是否可以在申请阶段预上线平台Beta版本进行测试？

答：可以，但应注意：

  • 不得向公众开放或实际收取客户资金；

  • 应标明“测试版本”“不代表正式上线”“不提供服务”等字样；

  • 所有测试账户、模拟交易数据应有隔离机制；

  • 建议在申请材料中列明测试系统逻辑、数据范围及测试结束时间。

若测试平台牵涉冷钱包或真实客户数据，应向BoL说明技术控制与脱敏机制。

Q81：MiCA合规稽核的频率与内容有哪些？

答：MiCA合规监管稽核（Supervisory Review）由立陶宛央行（BoL）主导，一般分为以下几类：

类型 频率 内容
定期年审 每年1次 审查合规报告、财务报表、客户投诉记录、IT系统更新等
突击稽核 随机或基于举报 检查实际运营、资金流向、冷钱包权限、安全策略等
专项核查 新业务上线或客户增长激增时 审查新服务流程、KYC流程、客户适当性评估等
 

建议公司设立合规年度计划，并配备内部审计职能或外部合规顾问。

Q82：平台若停止某一类CASP服务，是否需通报BoL？

答：是的。根据MiCA规定：

  • CASP如停止提供原申请的任何一种服务，须提前30日书面通知BoL；

  • 同时提供服务终止原因、客户善后安排与数据保存机制；

  • 若为永久性退出，须注销该项牌照许可并在官网公告。

⚠️ 未通报停止服务或造成客户资产遗失，监管将视为重大违规。

Q83：是否允许在平台嵌入NFT交易功能？NFT是否受MiCA监管？

答：

  • MiCA对NFT本身不做强制监管（若具唯一性、不可替代性）；

  • 但若NFT具有金融功能（如收益分红、证券属性、二级流通市场交易），可能会被认定为“加密资产”而落入MiCA管辖；

  • 嵌入NFT交易功能须评估是否构成MiCA项下服务，并保留法律解释说明文件。

实务建议：在平台使用“非金融NFT”时应明示“此项不受MiCA监管”，并避免营销词汇中带“收益”“托管”等术语。

Q84：平台用户来自非欧盟国家，是否仍需遵守MiCA？

答：MiCA适用于以下场景：

  • 平台主体注册于欧盟（如立陶宛）；

  • 无论客户来自何地，平台必须对所有用户一视同仁适用MiCA制度；

  • 若服务大量来自非欧盟国家客户，应视为“跨境输出”，需考虑本地国合规要求。

⚠️ 建议为不同国家设置访问控制或合规说明，避免触犯境外法规（如美国SEC、新加坡MAS）。

Q85：冷钱包可以采用多方托管结构吗？（如双重签名，第三方监管人）

答：可以。MiCA允许以下冷钱包权限控制架构：

  • 自托管+多签机制（公司董事 + 合规官多签）

  • 第三方合规托管 + 技术控制（如Fireblocks、Ledger Enterprise）

  • 合资监管结构（不同实体共管）

关键在于：

  • 钱包地址、签名路径必须提交监管备案；

  • 冷钱包操作须支持审计日志、权限分层与操作追踪机制；

  • 应急机制必须设计：包括冷备份、热转冷操作规范等。

Q86：如果合规官或MLRO离职，应如何应对？是否暂停服务？

答：MiCA规定：合规官或MLRO为“核心监管岗位”，变动必须合规处理：

  • 应于5个工作日内通知BoL；

  • 同时提交临时代理人任命函、永久接替人选的履历、责任说明；

  • 若未能及时安排接替，将被要求暂停高风险业务（如开户、转账）；

  • 建议在合同中设立离职提前通知机制（如30–60日）以确保过渡。

多数CASP配备双角色结构：一人负责AML，一人负责综合合规；建议同时安排替补人选。

Q87：MiCA对“虚拟办公室”或“共享办公地址”是否接受？

答：BoL对“实质性运营”有强要求：

  • 不接受纯虚拟地址（仅作通信用途）；

  • 若为共享办公地址，需具备：

    • 专属独立空间（含门牌、门禁）

    • 实地访问能力（监管稽核可到访）

    • 员工日常办公照片、租赁合同、地址挂牌证明

实操建议：在立陶宛租用合规办公空间（可联合其他金融科技企业），同时布置基础场景以应对监管查验。

Q88：公司能否由基金或信托作为最终股东？

答：可以，但必须穿透至最终受益人（UBO）：

  • 若为基金，应披露基金章程、投资人结构、GP/LP身份；

  • 若为信托，应披露受托人、受益人、控制权关系；

  • 所有UBO均需提交KYC、资金来源与无犯罪证明；

⚠️ 不披露UBO、使用匿名结构或信托屏障将被拒绝审查。

Q89：若公司计划出售业务或被收购，MiCA如何处理股权变动？

答：

  • 收购涉及50%以上股权变动或控制权转移，须事前向BoL提交“结构变更申请”；

  • 监管将重新审查新股东的适当性（包括合规历史、资金来源、监管背景）；

  • 未获批准前不得完成实际交割或更改董事会架构；

  • 建议在SPA协议中设立“监管批准先决条件”。

建议收购MiCA牌照公司时，提前进行法律与合规尽职调查。

Q90：MiCA是否接受代币发行与服务分离结构？例如母公司负责技术，子公司持牌？

答：可行，但需结构清晰，且满足以下要求：

  • 持牌公司（CASP）必须对最终服务用户负责；

  • 技术提供方可为母公司或关联公司，但必须有合约责任；

  • 所有关键数据与客户资金，最终仍由持牌实体控制与报告；

  • 不可出现“功能外包但无监管责任”的空壳结构。

实操结构建议采用“多公司集团 + 合约责任 +共用KYC系统”架构，同时向BoL披露控制关系与功能分布图。

Q91：若平台经营不善计划退出MiCA业务，如何合法注销？

答：MiCA对CASP牌照退出机制有明确规定，必须：

  1. 提前至少60日书面通知BoL，说明计划终止时间、原因；

  2. 制定客户资产清算与退还机制，包括冷钱包托管的解除与转账证明；

  3. 公告平台停运时间、资产提取最后期限；

  4. 保留所有客户与交易记录至少5年，以备审计与监管抽查；

  5. 向BoL申请正式注销CASP许可证，待审批完毕前不得关闭系统。

实务建议：安排退出合规顾问与法务团队同步操作，确保不触发客户投诉与监管责任追溯。

Q92：MiCA平台是否可以接受法人客户（公司/基金）？需要额外手续吗？

答：可以接受法人客户，但须额外履行以下义务：

  • 穿透最终受益人（UBO）结构；

  • 提供法人营业执照、章程、董事身份证明；

  • 确认法人客户不位列高风险名单（如FATF高风险国家）；

  • 提交法人客户账户的资金用途声明、来源路径文件。

⚠️ 若法人为信托或基金结构，需额外提供受益人清单与受托人责任书。

Q93：平台是否可以发行并挂牌自家代币？（Utility Token或Payment Token）

答：MiCA允许CASP经营主体进行代币发行（ITO），但须满足以下条件：

  • 代币必须符合MiCA关于“非金融工具”定义；

  • 发行文件需符合披露义务（Token Whitepaper）；

  • 交易平台挂牌本公司代币时，需履行利益冲突申报；

  • 不得将自家代币作为唯一支付方式或抵押品，防止客户资产绑死。

若代币属性接近证券或收益工具，应同步评估是否触发欧盟《MiFID II》或《Prospectus Regulation》。

Q94：MiCA是否允许混合业务结构，例如钱包+支付+发行？

答：允许。MiCA支持“一照多服”模式，即一个CASP可提供多个服务类别：

  • 需在申请阶段清晰勾选所有拟开展的业务类型；

  • 各类型需准备独立制度手册、流程图、人员配置证明；

  • 不同业务之间的资金、数据、权限必须物理隔离，尤其是涉及客户资产存放的服务；

  • 若未来增加新业务类型，需事前向BoL补充申请。

Q95：立陶宛MiCA牌照与其他欧盟国家（如法国、德国）的CASP牌照有何差异？

答：MiCA正式实施后，各国CASP牌照将趋于统一，但过渡阶段仍有以下差异：

项目 立陶宛 法国（AMF） 德国（BaFin）
审批周期 4–6个月 6–9个月 8–12个月
审查宽容度 较高，灵活沟通 保守，流程繁琐 极严，重审批资质
是否支持外资 是 是 是，但限制多
推荐适用 初创公司/亚洲团队 欧盟本地团队 拟德国扩张平台
 

建议将立陶宛MiCA牌照作为欧盟CASP护照的起点，之后通行至其他国家市场。

Q96：MiCA实施后，原立陶宛VASP牌照是否作废？

答：MiCA强制生效（2025年6月）后，原VASP制度将被替代。过渡规定如下：

  • VASP牌照持有人需于2025年前升级为MiCA CASP牌照；

  • 若未提交升级申请，将于2025年后被视为无效牌照；

  • 升级申请可适当简化部分审查环节，但仍须补交符合MiCA的系统、安全、AML材料。

Q97：MiCA是否要求牌照申请人提供客户适当性评估机制？

答：是的，MiCA要求：

  • 对拟投资者或使用者的KYC背景、风险承受力、交易经验进行评分；

  • 匹配不同产品风险等级进行适当性判断；

  • 若客户拒绝提供评估，应进行交易限制或客户教育声明确认；

  • 平台需保存适当性评估记录至少5年，可随时接受审计抽查。

Q98：能否在平台设计Token Launchpad（启动板）功能？是否受限？

答：可行，但有以下合规限制：

  • 若Launchpad仅用于展示项目介绍，不收资金、不收费用，视为市场营销；

  • 若平台代为募集、打币、分发，视为“承销服务”（MiCA 9类）；

  • 须披露项目方信息、Token Whitepaper、审计报告；

  • 且不得对客户作出任何“固定收益、兑付承诺”类陈述。

Launchpad结构建议参考IEO标准结构，采用独立页面、分离KYC、托管账户控制等方式。

Q99：MiCA是否允许平台上线杠杆产品（如衍生品、期货）？

答：
MiCA本身不覆盖加密资产衍生品，该类产品属《MiFID II》与《EMIR》监管范畴。

  • 若提供杠杆、期货、永续合约等功能，应申请投资服务类牌照；

  • MiCA CASP不可直接开展衍生品交易服务；

  • 建议通过合规的交易所接入或由合作持牌方托管执行。

Q100：MiCA是否设置最低收入门槛或业务启动期限？

答：

  • MiCA不设置明确“营业收入”要求；

  • 但申请牌照后，BoL将于6个月内检查是否“实际运营”；

  • 若发现公司无业务开展、无客户开户、无团队进驻，将被认定为“空壳申请”并吊销牌照；

  • 建议在获牌后90日内完成上线测试、用户开户与首批交易记录提交。

Q101：平台是否可以预设白名单客户以简化KYC流程？

答：可以，但需遵守以下MiCA合规框架：

  • 所谓“白名单客户”仅能作为风险评级与审核优先排序依据，不可跳过KYC流程；

  • 白名单资格应基于：

    • 过往合规合作记录；

    • 具牌照或机构背景（如受监管交易所、基金等）；

    • 与CASP签署的长期合作备忘录（MOU）；

  • 平台仍需保留完整KYC/AML数据与验证记录，不得豁免。

实务建议：将白名单制度纳入《客户接纳政策》中，并报BoL备查。

Q102：如何评估上线新加密资产是否符合MiCA监管分类？

答：MiCA要求CASP建立一套加密资产分类与适当性判断机制。主要包括：

  • 判断该资产是否为：

    • EMT（电子货币代币）

    • ART（资产参考代币）

    • 其他Crypto Asset

  • 确认是否触发其他欧盟金融法规（如是否为证券型代币）；

  • 是否存在跨境衍生性或与传统资产挂钩（如Real World Assets）；

  • 要求发行方提供：

    • 代币白皮书

    • 技术文档

    • 审计报告

    • 法律意见函

⚠️ 若无法明确分类，平台不得上线交易，建议设立Token Listing委员会负责审查。

Q103：MiCA是否允许平台参与DAO项目运营？

答：允许，但需满足以下前提：

  • 若平台对DAO拥有控制权（如金库签名、核心治理权），需承担运营合规责任；

  • 若仅作为服务提供方（如提供钱包托管、前端页面、API接口），责任可减轻；

  • 所有与DAO有关的代币、功能、资金流转需具备可追踪路径和申报机制；

  • 不得以“去中心化”为借口规避责任。

BoL和ESMA对于平台背后存在控制权的DAO项目，倾向要求其纳入MiCA监管视野。

Q104：MiCA平台是否可对客户资产进行托管再投资？

答：不可以。MiCA明令：

  • 客户资产为隔离托管状态，不得用于平台自营交易或再投资；

  • 禁止设立与客户资产池相关的“收益增强”机制；

  • 平台如提供Staking功能，必须说明其非平台控制的链上协议，并提供透明风险披露；

  • 若平台设立收益型产品，将被认定为投资产品，需另持MiFID牌照。

Q105：是否可以对加密资产服务设置交易限制或时间段限制？

答：可以，MiCA鼓励平台根据风险政策设计以下控制机制：

  • 单日交易限额（适用于新开户、未完成KYC客户）；

  • 夜间风控熔断机制；

  • 异常交易行为触发冷钱包隔离；

  • 针对某些币种或钱包地址（如受制裁地址）设置禁入。

上述控制策略应写入《交易合规制度》并向BoL备案。

Q106：平台是否需要向BoL实时申报大额交易或可疑活动？

答：需要，依据MiCA和《反洗钱第六号指令》（AMLD6）：

  • 大额交易申报门槛通常为€10,000或等值加密资产（单笔或累计）；

  • 可疑交易（STR）应在发现后3日内向FIU（金融情报单位）提交报告；

  • CASP须设立内部STR识别系统+MLRO初审机制；

  • 所有提交记录必须存档 ≥5年，以备查验。

Q107：平台上线后的年度合规审核是否可由第三方进行？

答：必须由外部独立合规审计人完成，MiCA要求：

  • 年度合规报告应由与CASP无直接利益关系的审计机构出具；

  • 审核内容包括：

    • 客户资金隔离机制

    • AML流程执行情况

    • IT系统合规测试记录

    • 内部报告与董事会沟通机制

  • 报告必须在会计年度结束后3个月内提交至BoL。

Q108：MiCA是否接受API开放平台结构？是否对接口调用有安全要求？

答：MiCA接受平台提供API服务，但对开放接口有严格规范：

  • 所有API必须使用加密通讯协议（如TLS 1.3）；

  • 外部接入API必须设置权限分层与限流机制；

  • 日志需保存每一次调用记录，并与KYC账户绑定；

  • 平台需对API连接的三方进行合规尽职调查（KYC +技术审计）。

对于提供高频交易接口的，应标注“专业客户专用”，不得向散户无差别开放。

Q109：MiCA监管是否关注ESG与可持续发展因素？

答：MiCA本身对ESG无强制规定，但若服务商：

  • 发行绿色代币（Green Token）；

  • 宣称节能挖矿、碳中和等环保属性；

  • 向公众承诺ESG相关投资或报告披露

则必须：

  • 提供第三方认证（如碳排放审计报告）；

  • 定期发布ESG透明度披露；

  • 禁止虚假营销，违反将触发《市场滥用条例》（MAR）调查。

Q110：MiCA持牌公司如何设置“双重合规体系”，应对欧盟外客户？

答：若平台服务非欧盟客户（如东亚、中东地区），建议建立：

  1. MiCA本地合规体系：服务欧盟用户，受BoL与ESMA监管；

  2. 国际客户接入体系：根据客户属地法规（如香港、迪拜、开曼）评估是否需设当地合规牌照；

可选方式包括：

  • 设立子平台或域名分离；

  • 设定用户识别机制（IP/GPS+KYC属地）；

  • 为非欧盟客户准备**“受限使用条款”与风险提示文件**。

推荐设置“分域使用+分账户合规策略”，并明确披露不同区域政策适用差异。

Q111：平台如何处理来自家族办公室（Family Office）的大额资金客户？

答：
MiCA法规本身不区分家族办公室客户，但平台可在“客户分类政策”中纳入以下规则：

  • 家族办公室属于“专业客户”类别；

  • 须提供以下KYC/KYB材料：

    • FO注册文件、受益人结构图、控制人声明；

    • 投资政策备忘录（如有）、授权交易人资料；

  • 交易权限和风控限额可适度提升，但需：

    • 强化反洗钱尽职调查；

    • 报告任何与信托结构相关的复杂资金流动；

  • 可引入FO专属顾问账户或白名单接口。

建议设立“高净值与FO服务部”，提升客户满意度及监管合规性。

Q112：MiCA平台如何应对客户投诉？是否有强制机制？

答：有强制机制，平台必须建立书面的客户投诉处理制度，要求包括：

  • 设立“客户投诉登记册”；

  • 每一笔投诉须在15个工作日内做出初步回复；

  • 若处理周期较长，应在1个月内提供进展更新；

  • 投诉记录须保存5年；

  • 明确指引客户如何向BoL/消费者保护局二次申诉。

建议设置客户专用邮箱、在线申诉入口，确保可追溯性。

Q113：MiCA下如何冻结可疑客户账户或交易？

答：CASP平台有权冻结账户，前提为：

  • 基于AML可疑交易行为；

  • 基于法院、监管机构（如BoL、FIU）指令；

  • 客户违反平台条款并影响其他用户。

冻结机制需包括：

  • 冻结通知（向客户发送说明）；

  • 冻结流程记录（冻结人、冻结时间、冻结原因）；

  • 协同MLRO或合规官审批；

  • 解冻流程必须经再次审核或监管指示。

推荐引入“冻结风险分级模型”，以避免滥用冻结权限。

Q114：如果平台遭遇黑客攻击，是否有强制报告机制？

答：是的，MiCA明确将网络攻击事件列为“重大事件（Major Incident）”，平台义务包括：

  • 在24小时内初步向BoL申报，说明事件影响范围；

  • 提交事件溯源分析报告；

  • 启动客户通知流程（若涉及客户数据泄露）；

  • 若与客户资产有关，需冻结相关账户并进行赔偿评估。

建议设立《网络安全应急预案》，定期进行演练。

Q115：MiCA平台是否可以收取上币费（Listing Fee）？

答：允许收取，但须满足以下合规前提：

  • 不能附带平台承诺投资回报或价格保证；

  • 上币需基于公开的Token Listing评估制度；

  • 所有费用收入应如实入账；

  • 建议出具正规发票，说明服务内容（如合规评估、技术对接、测试支持等）。

强烈建议避免“Pay-to-List”暗箱操作，防止监管认定为操纵市场行为。

Q116：MiCA是否允许平台发放推广奖励（如推荐返现）？

答：允许，但需：

  • 设置返现上限（防止洗钱风险）；

  • 所有奖励需实名账户接收并计入账册；

  • 不得通过多级返佣机制引导客户“裂变营销”，此类行为可能触发MiFID法规限制；

  • 建议向BoL申报奖励机制，并纳入《市场行为政策》。

透明公示与限制杠杆滥用，是保证合规推广的核心。

Q117：MiCA平台是否可以嵌入DeFi协议？监管怎么认定？

答：可嵌入，但MiCA监管视角如下：

  • 若平台“主动控制DeFi合约入口或资金流向”，则被认定为平台责任主体；

  • 建议：

    • 不直接托管DeFi协议私钥；

    • 不承诺任何固定收益；

    • 设置跳转免责声明；

    • 记录用户自发行为轨迹，避免“伪DeFi”风险；

  • 所有嵌入合约应经过代码审计，且可追溯流向。

当前BoL对“平台包装DeFi”行为持谨慎态度，须极度小心。

Q118：MiCA下能否发行“带投票权”的治理型代币？如何披露？

答：若代币持有人拥有投票权、决策权或股息权：

  • 则该代币可能被认定为金融工具（MiFID II）；

  • 平台如提供流通/交易服务，可能需额外持牌；

  • 推荐在白皮书中充分披露治理结构、投票权重机制、限制条款；

  • 所有治理类资产发行方，需单独履行披露责任（类似上市公司）。

建议聘请律师提供《是否为证券型代币法律意见函》。

Q119：MiCA是否要求董事会定期审议合规报告？

答：是的，MiCA要求平台设立清晰的**“合规向上汇报机制”**：

  • 至少每季度，合规官须向董事会提交书面合规报告；

  • 报告内容应包括：

    • AML/KYC执行情况；

    • STR统计；

    • 合规培训记录；

    • 客户投诉处理情况；

    • 系统安全与技术审计摘要；

  • 所有董事会议纪要须记录相关审议意见。

无“董事会合规问责制度”的平台，会被BoL认为治理结构不完整。

Q120：MiCA平台如何回应媒体负面报道或舆情？是否需通报BoL？

答：建议设立“危机响应机制”，分为两种情况：

  1. 涉及事实失实报道或一般舆情：

    • 可不报BoL；

    • 建议发布公告澄清，并保存应对记录。

  2. 涉及平台安全、监管调查、客户资金安全的报道：

    • 必须通报BoL；

    • 启动内部核查与合规备案；

    • 若确有风险，应同步客户并配合FIU进行申报。

建议设立“媒体联系人/合规负责人”统一对外发言，避免信息混乱。

Q121：MiCA平台是否可支持多个法币钱包？例如 EUR、USD、HKD 同时提供？

答：可以，但需要满足以下合规条件：

  • 必须明确区分资金归属（自有 vs 客户）；

  • 每种法币钱包对应清晰的开户银行及IBAN账户；

  • 钱包内资金处理应与EMT（电子货币代币）服务隔离；

  • 所有币种钱包均需在《财务处理政策》中声明资金流动路径；

  • 建议设立“主钱包+客户子钱包”结构，提升监管透明度。

立陶宛BoL特别关注非欧元资产的储备与处理路径，平台应预留对应会计核算与风险敞口说明。

Q122：如果平台结构中存在境外控股信托（如新加坡VCC、开曼信托），是否可行？

答：可行，但需提供：

  • 信托契约副本（中英文）；

  • 最终受益人（UBO）穿透结构图；

  • 每位UBO之KYC、无犯罪证明、税务居民声明；

  • 受托人/保护人身份与职责说明；

  • 信托不涉税规避或洗钱嫌疑的法律意见函。

强烈建议在提交MiCA申请前，聘请欧洲律师就该结构合法性出具《合规性意见函》。

Q123：MiCA下如何处理客户取现争议或提现异常？

答：应设立《客户资产赎回政策》，明确：

  • 客户申请提款后，一般处理时间（如：T+1、T+2）；

  • 提现失败的自动退回机制及理由通知；

  • 若因风险控制冻结提款，应提供异议申请机制；

  • 超过 €15,000 的单笔提款应触发人工审核；

  • 保留客户异议申请、客服对话记录等以备查。

建议配合建立“客户资金出入记录日志表”，作为后续审计与STR申报辅助材料。

Q124：新增RO（负责人员）或MLRO（洗钱报告官），是否需重新递交申请？

答：是的。根据BoL指南：

  • 新任RO/MLRO 需提前提交以下材料：

    • 简历（CV）

    • 无犯罪记录证明（6个月内）

    • 专业经验说明（2年相关经验为佳）

    • 任职确认信（由董事会签发）

  • BoL 审批时间约 30–60 天；

  • 新任不得立即履职，需取得核准后方可上任。

如属应急替代（如前任离职），可指定“临时RO”，但必须获得BoL书面同意。

Q125：MiCA是否允许外部承包部分服务？例如KYC系统外包、客服外包？

答：允许，但必须：

  • 签订合规的外包协议（包含保密义务、数据访问权限、责任划分）；

  • 平台仍承担全部合规及客户责任，不可推卸；

  • 所有外包方需提供：

    • GDPR合规声明；

    • ISO27001（或等效）安全认证；

    • 备份机制与访问控制文档；

  • 外包名册需纳入年审报告中提交BoL。

如外包商位于欧盟以外，建议额外提供《跨境数据传输说明函》。

Q126：平台是否可以开设面向特定国家的独立子品牌？（如：MiCA立陶宛主品牌 + 德国子品牌）

答：可以通过“商业子品牌”方式运营，但应注意：

  • 所有子品牌均须在官网/披露材料中注明其实际营运主体为持牌CASP；

  • 不得出现“假独立”运营；

  • 子品牌相关员工、流程、产品仍由总部统一监管；

  • 建议提交《品牌使用政策》及授权协议备查；

  • BoL 可要求子品牌单独接受抽查或审计。

如针对特定国家开展市场活动，建议同步向该国金融监管备案（虽非强制）。

Q127：客户是否可以用公司账户开立MiCA平台账户？KYB要求有哪些？

答：允许公司客户开户，必须满足 KYB（Know Your Business）流程：

  • 公司注册证书、章程、董事名单；

  • UBO声明 + 控股结构图；

  • 公司银行账户证明；

  • 控制人护照、无犯罪记录；

  • 公司用途声明（如交易、投资、自托管等）；

  • 若为基金或信托结构，还需附上相关契约。

建议配置专职KYB审查员，并保存完整客户资料 ≥5年。

Q128：平台是否必须在立陶宛境内设置客户服务热线或办公地址？

答：必须有真实、可验证的办公地址（不接受虚拟地址或挂靠地址），并需满足：

  • 客户服务热线工作时间符合立陶宛工作日；

  • 至少有一名本地雇员可现场处理监管/稽核需求；

  • 若使用共享办公空间，必须拥有独立门牌及接待能力；

  • 建议配置立陶宛语、英语双语客服。

实质性运营是BoL重点查验项，平台不可仅挂名存在。

Q129：客户是否可通过API方式连接MiCA平台？如何保证合规？

答：可以提供API服务，必须：

  • 实施“API接入KYC”，仅允许实名用户连接；

  • 设置调用限额、频率限制，防止DoS或刷单；

  • 明确API服务条款（包括免责声明）；

  • 接口日志需存储 ≥ 5年，可供稽核；

  • 涉及交易、提款等敏感权限，必须设双重验证机制。

建议定期进行API渗透测试与接口更新。

Q130：MiCA平台是否可发行预付卡、充值卡等辅助支付产品？

答：此类服务如涉及“储值、支付”功能，可能构成电子货币服务（EMT）或支付机构服务，需额外获得：

  • EMI（Electronic Money Institution）牌照；

  • 或立陶宛央行支付机构授权。

MiCA CASP牌照本身不覆盖电子支付工具发行，如提供此类产品，建议分拆业务结构或合作外部持牌方。

若非持牌EMI机构，不得使用“充值卡”“消费卡”等误导性宣传。

Q131：MiCA平台如何制定代币上架（Token Listing）标准？是否需要预先报批？

答：MiCA法规要求平台必须制定公开透明的代币评估及上架机制，但不要求逐一报批。应包括：

  • 《Token 评估政策》（Token Evaluation Policy）；

  • 项目团队背景及法律合规性审核；

  • 白皮书真实性验证；

  • 技术安全审核（审计报告、智能合约逻辑）；

  • 市场风险披露与用户适当性匹配机制。

若所上架代币构成 ART 或 EMT，必须额外遵守对应披露与注册程序，并向 ESMA/EBA 备案。

Q132：海外SPV控股公司（如BVI、开曼）是否可作为股东持有MiCA平台？

答：可以，但需满足下列穿透与合规性说明：

  • 提供完整结构图与 UBO 身份（包括护照、税务居所、KYC）；

  • 提交每一层控股公司章程、注册证书；

  • 不得为匿名信托、保密公司；

  • 出具法律意见书说明结构不用于规避监管或税务义务；

  • 所有文件需有经认证翻译。

建议提前对接立陶宛当地法律顾问，规避潜在结构问题。

Q133：平台如何应对立陶宛央行突击审计或例行检查？

答：
需建立如下应急与应对机制：

  • 每季度自查报告制度（内部稽核记录）；

  • 设立《监管检查应对政策》；

  • 整理备查文件包（客户资料、STR记录、系统日志等）；

  • 合规官/MLRO需保持随时可召回状态；

  • 可预演“模拟稽核演练”，强化团队应对流程。

通常稽核需 5–10 个工作日完成，BoL 会预先发出检查通知函。

Q134：MiCA牌照是否允许为客户提供保证金交易或杠杆产品？

答：MiCA本身并不直接禁止杠杆产品，但需满足以下条件：

  • 产品设计不得导致客户承担超过其资产的亏损；

  • 必须设止损、强平机制；

  • 需明确披露杠杆风险与计算公式；

  • 平台必须对客户执行“适当性评估”（Suitability Test）并保留记录；

  • 不得面向零售客户推广高风险产品（如≥10倍杠杆）。

若杠杆产品实质为金融衍生品，可能触发 MiFID II 额外要求。

Q135：客户是否可以申请查看自身 KYC 与交易记录副本？

答：必须允许客户申请获取以下资料（符合 GDPR 要求）：

  • 自身KYC资料副本；

  • 所有交易记录明细（带时间戳、订单号）；

  • 钱包地址与资金流向记录；

  • 投诉处理过程记录副本。

平台应：

  • 在收到申请后30天内回复；

  • 采用安全方式传输资料；

  • 保留申请与交付过程完整日志。

不得对客户施加不合理门槛或收费，除非超出合理工作量。

Q136：如果MiCA平台发生客户资金损失事故，是否强制设立赔偿机制？

答：MiCA并未强制设立赔偿基金，但平台应：

  • 设立客户资产隔离账户；

  • 配置商业责任险或托管保险；

  • 对应《客户资产赔付流程指引》（Client Compensation Policy）；

  • 提供事故应急响应机制说明；

  • 若为平台操作失误造成损失，应全额赔付或仲裁解决。

不得以免责声明规避平台对操作失误或系统故障的法律责任。

Q137：MiCA牌照企业是否可以变更注册地址？流程如何？

答：可以，但须向 BoL 提交变更申请，流程如下：

  1. 填写注册地址变更表格（附新地址租赁证明）；

  2. 提交新办公场地照片与布局说明；

  3. 通知客户并更新隐私政策与服务条款；

  4. 更新相关内部文档与监管备案信息；

  5. 获批前不得启用新地址开展业务。

若同时变更人员/运营模式，可能需连带审查。

Q138：MiCA是否支持平台持牌后设立子公司在欧盟其他国家运营？

答：支持。MiCA授予“欧盟护照权”，平台可：

  • 在其他欧盟成员国以子公司、分支或代表处方式开展业务；

  • 但仍需提前向 BoL 和当地监管机构备案；

  • 若属设立独立法人，则建议再申请“Host CASP”登记；

  • 子公司服务范围不能超出母公司牌照范围；

  • 必须同步履行跨境审计、报告义务。

推荐统一 IT 系统与风险管理政策，保持集团一致性。

Q139：如何向BoL提交 STR（可疑交易报告）？是否有专门接口或模板？

答：BoL STR 机制对接立陶宛 FIU（金融情报单位），需：

  • 使用官方 STR 表格（.doc 或 XML 格式）；

  • STR必须包含以下要素：

    • 客户身份信息；

    • 涉嫌交易明细（时间、金额、链上地址等）；

    • 可疑理由分析；

  • 必须通过 FIU 官方平台上传或加密电邮发送；

  • 必须保存 STR 报告记录 ≥ 5 年。

MLRO 应接受年度反洗钱培训，确保具备独立判断与报告能力。

Q140：MiCA平台如何处理被列入黑名单客户？是否需通知其？

答：处理黑名单客户应遵循以下合规步骤：

  1. 立即冻结其账户及相关交易；

  2. 出具内部《风险账户处理通知书》，记录冻结理由；

  3. 通知客户账户限制情况（除非FIU要求保密）；

  4. 决定是否提交STR；

  5. 定期审查黑名单状态，更新与释放机制。

建议设置《拒绝客户政策》（Rejection & Termination Policy），统一处理流程，并保留所有沟通及操作记录。

Q141：MiCA平台能否外包核心IT功能给第三方技术服务商？如何合规？

答：可外包部分非核心模块，但以下核心系统不得完全外包或必须受控于持牌实体：

  • 客户KYC数据系统；

  • 冷/热钱包控制系统；

  • 交易撮合与资金清算系统；

  • 反洗钱监控与STR生成引擎；

  • 权限管理系统。

若确需委托第三方（如AWS、合规科技厂商等），则需：

  • 签订《IT外包合规协议》（含数据保护、合规责任）；

  • 明确平台拥有控制权及审计权；

  • 提供技术架构说明书 + 数据访问权限图；

  • 外包方接受BoL或FIU的审计权；

强烈建议保留源代码/控制接口于本地或受MiCA/EU监管国家，以防突发风险无法接管。

Q142：MiCA平台如何处理客户提出的纠纷或投诉？

答：必须设立正式的《客户投诉处理机制》，包括：

  • 投诉渠道（电话、电邮、线上表单）；

  • 标准回复时限（如：7个工作日内初步反馈，30日内处理）；

  • 投诉登记簿（含处理人员、过程、结果）；

  • 指定合规官或专员负责处理；

  • 客户不满意可升级至BoL投诉通道。

平台应定期报告投诉数量与处理状态，并进行根因分析（Root Cause Analysis）。

Q143：MiCA平台是否可以向客户提供代币分红或收益分享机制？

答：如设计合理并非“金融工具”，可提供“收益型代币”或“平台分红”，但须确保：

  • 明确披露非固定回报、无担保；

  • 不构成“证券”性质，否则触发MiFID II要求；

  • 收益分配模型需在白皮书中阐明，并接受审计或智能合约代码检查；

  • 不可对客户构成误导或担保本金安全。

推荐平台设计“平台积分机制”代替直接利润分享，降低监管争议。

Q144：MiCA对员工的合规培训频率和内容有何最低要求？

答：MiCA框架鼓励企业建立《员工合规培训制度》，通常建议：

  • 新员工入职前必须完成反洗钱与数据保护培训；

  • 每年进行不少于一次全员培训（可含网络课、讲座、测试）；

  • 特定岗位（如MLRO、客户经理）需单独强化培训；

  • 建立培训档案，记录时间、内容、参与者、测试分数等；

培训内容建议涵盖：MiCA法规、AML、KYC、GDPR、IT安全、STR识别等。

Q145：MiCA持牌平台能否对客户提供金融衍生品、期权、杠杆ETF等？

答：若相关产品属于《金融工具》，MiCA平台必须另外取得MiFID牌照。否则：

  • 不可提供与加密资产挂钩的衍生品；

  • 不可设计“保证收益”或“对赌结构”产品；

  • 所有杠杆设计必须说明风险，且面向专业投资者。

MiCA仅适用于“非金融工具类”加密资产，涉及证券化的结构需合规嵌套MiFID体系。

Q146：MiCA是否要求平台必须拥有灾备系统？必须设在立陶宛吗？

答：是的，MiCA要求平台具备IT灾备恢复机制（Disaster Recovery Plan），包括：

  • 定期备份（推荐日备 + 周全备）；

  • 异地灾备站点（至少异地机房，优先在立陶宛/EU境内）；

  • 恢复时间目标（RTO）与数据恢复点目标（RPO）策略；

  • 灾难演练机制；

  • 应急联系人及流程说明。

必须形成完整文档并提供BoL抽查验证。

Q147：MiCA平台是否可以使用“数字身份验证系统”（eID）简化KYC？

答：可以，平台可采纳以下MiCA/EU认可的KYC方式：

  • eIDAS认证数字身份系统；

  • 远程视频认证（需记录存档）；

  • AML/KYC服务提供商（如Sumsub、Onfido）对接；

  • 多因素验证（MFA）+ 数据比对逻辑引擎。

所有身份验证过程必须保留 5 年以上，并可配合监管复查。

Q148：MiCA平台是否可以接受加密资产作为客户出入金方式？

答：MiCA并不禁止加密资产入金，但必须：

  • 在合规政策中说明其接受规则与风险披露；

  • 设置“链上来源识别”机制（如链上分析工具）；

  • 严禁来自于匿名钱包或Mixers（如Tornado Cash）；

  • 出金地址需绑定且经过KYC验证；

  • 不可使用黑名单地址、洗钱可疑地址等。

推荐对接主流AML链上监控服务（如Chainalysis、Elliptic）自动识别交易可疑性。

Q149：平台如何处理“客户长期不活跃账户”或“资金闲置账户”？

答：建议建立《Dormant Account Policy》：

  • 定义：如连续12个月无交易或登录行为；

  • 处理方式：

    • 通知客户拟冻结；

    • 强制重启KYC验证；

    • 若长期无回应可提交STR；

    • 闲置资金不得挪作他用；

  • 必须记录解冻流程与客户互动历史。

年度审计中须报告所有Dormant账户状态及处理措施。

Q150：MiCA是否对平台与客户之间的“协议模板”有格式要求？

答：MiCA无固定模板，但客户协议必须具备以下要素：

  • 双方身份明示（含客户身份证明或企业注册信息）；

  • 所提供服务类型与风险披露；

  • 手续费、佣金、汇率、返佣等说明；

  • 投诉、仲裁与终止机制；

  • 数据隐私与反洗钱合规条款；

  • 客户签名或确认方式（电子或纸本）。

强烈建议由法律顾问审阅后生效，并支持多语言版本（英文 + 客户语言）。

Q151：MiCA是否允许平台设有Token锁仓机制？是否需备案？

答：允许，但必须符合以下规范：

  • 锁仓机制必须写入代币白皮书（Whitepaper）；

  • 锁仓条款应包括锁定期限、解锁条件、相关地址控制权说明；

  • 若锁仓与团队分润、投资回报挂钩，需特别说明非担保、非证券性质；

  • 若使用智能合约自动执行锁仓，应提供代码审计报告；

  • 监管机构可要求解释该机制对客户风险的影响及信息披露程度。

建议在申请CASP时就锁仓机制一并提交《代币经济模型说明书》。

Q152：MiCA是否允许Token销毁（Token Burn）机制？是否需申报？

答：允许，但要：

  • 在白皮书及披露材料中说明销毁机制（时间点、数量、执行方式）；

  • 若销毁将影响市值、价格或与业务激励有关，需注明是否影响客户权益；

  • 若通过智能合约销毁，建议进行第三方审计并公开逻辑代码；

  • 监管机构（BoL）可能要求企业就该行为影响提供经济合理性说明。

销毁动作若影响资本结构或客户权益，有可能被视为重大事件，建议事前沟通监管。

Q153：MiCA是否对代币的再发行（Reissuance）有限制？

答：有。若平台原白皮书中声明代币总量封顶（Capped Supply），则：

  • 再发行视同重大变更；

  • 需提前更新白皮书、官网、投资者通知；

  • 需提交代币发行结构图、经济模型调整说明、法律意见书给监管审查；

  • 未经备案再发行可能构成欺诈、误导或合规违规。

建议所有与代币供应机制有关的操作，事前纳入《商业计划书》与IT结构中进行备案规划。

Q154：MiCA平台是否可以允许客户“子账户”或“托管子钱包”操作？

答：可以，但需要：

  • 清晰划分客户间资产（不可混用）；

  • 子账户或子钱包应与客户实名绑定；

  • 权限必须明确区分前台/中台/后台访问控制；

  • 客户必须能随时查阅其资产明细、历史记录；

  • 若提供子账户内“子用户”操作权限（如企业账户中多个操作员），必须有操作审计轨迹。

推荐通过权限矩阵与日志系统完成子钱包管理，配合KYC/KYT（Know Your Transaction）机制。

Q155：平台如何界定“加密资产不是金融工具”？需要法律意见书吗？

答：MiCA明示：平台若所经营的资产未构成MiFID II下定义的“金融工具”，可由MiCA监管。

但为避免监管争议，建议提交下列材料：

  • 加密资产的技术说明（Utility、Access、Governance功能）；

  • 不构成权益、债务、可转证券的法律认定依据；

  • 法律意见函（Legal Opinion），建议由欧盟认可律师事务所出具。

若平台将Token用于融资、承诺回报或代表权益，强烈建议咨询法律顾问重新界定监管归属。

Q156：平台客户若提出“全部出金”，MiCA是否有流动性保障机制要求？

答：是的。平台需：

  • 保持客户资金流动性充足，严禁挪用或再质押；

  • 建立“流动性管理策略文件”，说明高峰期资金调用计划；

  • 若客户资产位于第三方托管平台，需说明出金最长期限；

  • 出金周期必须事前说明，通常建议T+1或T+2日处理；

客户出金限制（如每日限额、提币审核）应在客户协议中明确披露。

Q157：平台是否可以为特定客户群（如企业或高净值）提供定制服务？

答：可以，但应：

  • 完成客户适当性评估（Suitability Assessment）；

  • 说明服务差异化标准（如门槛、服务内容、费用等）；

  • 保留定制服务审查流程与客户签名文件；

  • 不得对普通客户造成歧视性限制或信息不对称风险。

可设立“专业客户服务白名单”，提交监管备案（附分层标准说明）。

Q158：MiCA是否要求平台设置客户退出机制？应如何合规设计？

答：是的，MiCA强调客户自主权与退出机制。平台需具备：

  • 客户可随时注销账户的通道（在线或书面）；

  • 所有资产提取路径清晰，剩余资产说明方式透明；

  • 若存在未结清费用、合约、托管关系，应明示解决方式；

  • 出具《退出流程说明书》+《风险说明信》，客户签字确认。

不得强制客户锁定或使用不公平条款限制其退出。

Q159：MiCA是否允许平台对客户进行返佣、推广奖励等激励？

答：可以，但必须：

  • 在客户协议中明示奖励结构；

  • 避免误导性宣传（如“稳赚”、“推荐稳赚”）；

  • 对推荐人和被推荐人进行KYC并记录关联关系；

  • 不得触发“非法集资”或“传销结构”嫌疑；

  • 建议设置奖励上限和清退机制。

推荐设置《客户激励政策》文档，并接受合规官审批备案。

Q160：若平台发生安全事故（如资产丢失、黑客攻击），MiCA要求如何通报？

答：必须遵循以下流程：

  1. 内部报告机制启动（24小时内）；

  2. 向BoL及客户通报事件初步信息；

  3. 提交《重大事件报告书》（包括受影响资产、客户数量、补救措施等）；

  4. 启动应急预案（如资产冻结、客户限制操作等）；

  5. 若事件涉及数据泄露，须同时通报GDPR主管部门。

建议事前编制《信息安全事故应对手册》，并与审计、IT、法律顾问联合演练。

Q161：MiCA是否适用于 ESG（环境、社会与治理）类加密项目？是否需额外披露？

答：是的，MiCA本身并未强制所有项目进行ESG披露，但若：

  • 项目对外主张其ESG属性（如碳中和Token、绿色链）；

  • 或使用ESG为销售亮点或融资工具；

则监管机构（如BoL或ESMA）可能视情况要求补充说明，包括：

  • 项目对环境影响的评估方法；

  • 绿色能源来源与验证机制；

  • ESG评级或第三方认证情况；

  • 是否存在误导性营销行为。

建议此类项目主动编制《ESG披露文件》，提交作为白皮书补充材料。

Q162：MiCA是否涵盖元宇宙平台内的虚拟货币？如游戏Token是否需申请CASP？

答：分情形：

  • 单纯用于游戏、不可交易、无法兑换法币者，通常不受MiCA约束；

  • 可公开交易、可兑换为其他资产或法币者，将被视为加密资产，平台若提供交易、托管、转移等服务，必须申请CASP牌照；

  • 若元宇宙平台本身为交易场所，运营商也可能被认定为MiCA下的交易平台提供者。

判定标准为：“是否具备货币属性 + 是否对第三方开放流通 + 是否涉及客户资产操作”。

Q163：项目同时持有多实体结构（如爱沙尼亚运营公司 + 立陶宛合规公司），MiCA责任如何分配？

答：根据MiCA条例，只有在欧盟经营CASP业务的实体才需申请MiCA牌照。

  • 若立陶宛公司承担CASP服务，则必须持牌并承担全部合规义务；

  • 若其他国家实体仅作为技术或品牌授权平台，可通过协议明确职能分离；

  • 不可通过非持牌实体实际提供受规管服务，否则构成“影子服务商”风险。

建议所有关联公司签订《服务划分协议》并由法律顾问背书，避免监管穿透混淆。

Q164：DAO（去中心化自治组织）如何申请MiCA牌照？是否有豁免？

答：MiCA目前不对DAO做专门豁免，若DAO提供以下任一服务：

  • 托管客户资产；

  • 运营可交易的资产平台；

  • 发行并销售代币给公众；

则需通过设立法律实体（如UAB公司）作为责任承担主体，由该实体申请CASP牌照。

DAO项目应明确核心治理成员与法定代表，便于BoL进行尽职调查与责任追溯。

Q165：NFT是否全部豁免MiCA？哪些NFT项目仍需MiCA合规？

答：MiCA规定：

“非同质化代币（NFT）若代表独一无二的资产（如艺术、游戏道具），且不可交易为支付用途，通常不适用MiCA监管。”

但以下类型将不被视为“真正的NFT”，仍需MiCA合规：

  • 批量铸造的“类NFT”（如系列化头像、游戏资产批量销售）；

  • 具有支付、质押、回购、分红等功能；

  • 可进入交易市场自由买卖、价格由市场决定；

  • 用于融资或承诺回报的NFT项目。

建议所有NFT项目附带《法律分类意见函》，说明为何不构成受规管的加密资产。

Q166：MiCA对代币白皮书的内容要求有哪些关键点？

答：代币发行方应编制完整白皮书（Whitepaper），必须包含：

  1. 代币功能与使用场景说明；

  2. 发行数量、分配机制、解锁时间表；

  3. 投资者风险声明；

  4. 发行方及其管理人员信息；

  5. 技术架构与安全机制；

  6. 会计与托管安排；

  7. 若适用，法律意见函与合规说明。

所有白皮书需上传至监管数据库或公司官网，接受客户下载和监管查阅。

Q167：MiCA平台是否可以向非欧盟客户提供服务？

答：可以，但要注意：

  • 平台必须仍然受立陶宛BoL监管；

  • 必须对非欧盟客户执行KYC/KYT与反洗钱（AML）要求；

  • 若涉及高风险地区客户，需额外备案或加强审核（如PEP）；

  • 客户协议中应明确MiCA适用与客户所在地区监管冲突时的处理原则。

对非欧盟客户提供服务并不豁免MiCA责任，反而可能强化监管关注。

Q168：MiCA平台是否可采用算法稳定币（Algorithmic Stablecoins）？监管如何认定？

答：MiCA禁止不受控、不具备稳定性验证机制的算法稳定币进行广泛流通。若平台拟使用算法稳定币，必须满足：

  • 具备可验证的供需调节机制；

  • 设置“可变回收机制”或储备金抵押配套机制；

  • 有完整技术文件、经济模型说明与法律意见函；

  • 取得EMT（电子货币型代币）或ARTs（资产支持型代币）的特别审批。

建议采用混合模型（部分储备 + 稳定算法）并接受BoL审查，确保其不构成系统性风险。

Q169：MiCA是否要求平台员工接受合规培训？频次与内容要求如何？

答：必须。平台须设立年度合规培训计划：

  • 所有员工每年必须完成至少一次MiCA及AML/KYC制度培训；

  • 培训记录应书面化并保留至少5年；

  • 高管、RO、MLRO需参加专题培训，如市场滥用、制裁机制等；

  • 可外聘合规顾问机构开展培训，并由合规官归档记录。

建议编制《年度合规培训计划表》并作为年审材料一并提交。

Q170：MiCA是否要求平台执行“客户适当性评估”？具体怎么做？

答：是的，平台在客户下单、投资前必须进行适当性评估（Suitability Assessment），内容包括：

  • 客户的金融知识水平；

  • 加密资产投资经验；

  • 财务状况与风险承受能力；

  • 投资目标（投机/保值/支付等）；

评估结果决定是否允许其接触高风险产品（如杠杆、ICO、DeFi等）。

可设置在线评估问卷 + 签名确认机制，平台应保留记录，以备审计与纠纷查证使用。

Q171：如果CASP系统宕机或遭遇黑客攻击，MiCA对应急机制有什么强制性要求？

答：MiCA要求持牌CASP建立完整的业务连续性计划（BCP）与灾难恢复机制（DRP）。具体包括：

  • 制定《事故应对计划》；

  • 设立24小时技术应急联系人；

  • 在遭遇数据泄露、系统瘫痪时24小时内通报立陶宛银行（BoL）；

  • 向用户及时披露受影响范围与恢复措施；

  • 设置备份节点，存于欧盟境内，并可在1小时内恢复基本功能。

建议平台每季度进行灾备演练，并保留演练报告，供BoL审计使用。

Q172：MiCA下是否允许Token与股票、债券等证券类资产挂钩？如何监管？

答：MiCA对证券化代币（Security Token）不适用，由《MiFID II》与各国证券法监管；但若代币形式本身可被归类为资产参考型（ART）或电子货币型（EMT），则仍受MiCA部分约束。

场景示例：

  • ✅ 若为以法币或黄金等资产挂钩的稳定币 → 适用MiCA ART条款；

  • ❌ 若为股权型代币（如tokenized equity） → 适用MiFID II，不归MiCA监管；

  • ⚠️ 混合结构 → 可能双重监管（需事前取得法律意见书说明）

建议拟发行证券属性代币时，与金融法律顾问合作进行MiCA与MiFID划界分析。

Q173：客户进行Token staking时，平台是否会被认定为“提供利息”而需取得EMT许可？

答：视结构而定：

  • 若staking无固定回报、不承诺本金保障 → 通常不视为EMT；

  • 若staking方案承诺固定利率、回本机制，或实际构成存款替代品 → 可能触发MiCA EMT规则或银行监管规定；

  • 若staking收益来自平台利润分配，还可能构成集体投资计划（UCITS/MiFID义务）。

建议所有staking计划应出具《收益模型披露说明书》，并说明其非金融工具、非存款的法律定位。

Q174：MiCA平台是否可进行杠杆交易（如永续合约、杠杆Token）？需要额外许可吗？

答：MiCA并未明文禁止杠杆交易，但：

  • 如涉及保证金、强平机制、对赌撮合等，可能构成衍生品交易；

  • 需额外取得MiFID II投资公司牌照或通过合作方式转介执行；

  • 直接向散户提供杠杆产品可能面临投资者保护限制（如风险披露、适当性测试等）。

若MiCA持牌平台计划引入杠杆，应事先向BoL报备，并建议分实体操作。

Q175：客户购买Token失败，平台是否承担资金退款责任？MiCA是否对此有规则？

答：是的。MiCA要求：

  • 若客户购买过程失败（系统中断、对手方问题），平台应及时全额退款；

  • 若资金被冻结或等待区块确认，应向客户说明预计到账时间；

  • 平台必须在客户协议中说明资金留存、退款、争议处理机制。

若客户遭遇财产损失，平台需承担相应法律责任，除非能证明其无过失。

Q176：MiCA是否支持以Token形式发放员工股权激励？是否需要申报？

答：MiCA原则上不禁止此类行为，但有两项强制要求：

  1. 不得对外流通或交易，否则构成公开发行；

  2. 须申报为“员工福利计划下的非公众流通代币”并向BoL报备。

若员工持股Token可转售给第三方或绑定公司市值浮动，仍可能触发MiFID或MiCA发行义务。

建议出具《员工代币激励披露说明》+《限制转让声明》。

Q177：平台是否可以发行稳定币用于自身生态系统支付？是否需EMT牌照？

答：可以，但需满足以下要求：

  • 稳定币若锚定法币（如USD、EUR），即构成EMT代币；

  • 平台需向BoL申请EMT代币发行许可；

  • 并满足《电子货币指令》+《MiCA》联合适用，包括资本金不少于35万欧元、流动性准备金等；

  • EMT不得用于投资用途，仅限支付。

若仅限于特定内部平台使用、不可出圈、不可兑付 → 可豁免EMT适用。

Q178：MiCA对冷钱包服务商（Custody Provider）有哪些核心义务？

答：冷钱包服务商若受MiCA约束（如持有客户资产）必须承担以下职责：

  1. 明确客户资产与平台资产隔离；

  2. 定期提供资产对账报告；

  3. 设置权限管理机制（多签、审批流程）；

  4. 建立灾备、宕机应急制度；

  5. 对黑客攻击、资产异常变动，必须24小时内向BoL通报；

  6. 对每笔客户交易保存日志 ≥ 5年。

建议冷钱包服务商获取BoL认可或与CASP平台签订标准化托管协议。

Q179：平台是否可以设定最低入金门槛或限制客户某些操作？MiCA是否有禁止？

答：允许。平台可根据以下维度设定限制：

  • 客户身份（散户 / 专业投资者）；

  • 客户风险等级（根据适当性评估）；

  • Token波动性与合规等级（高风险Token禁止交易）；

  • 日限额、交易频次等（出于风控目的）。

但必须提前说明于用户协议中，且需确保此类限制非歧视性，并支持客户投诉申诉机制。

Q180：MiCA平台是否需要缴纳平台交易税或金融活动附加税？

答：MiCA本身不征税，但立陶宛税务机关（VMI）会根据平台交易与利润征收：

  • 增值税（VAT）：若提供付费服务如咨询、API订阅等，须缴VAT；

  • 公司所得税：平台年度利润须申报缴税（当前税率15%）；

  • 非居民客户交易如构成“源地所得”，或与立陶宛雇员相关，也可能被征税。

建议平台设立《税务合规政策》，并定期与会计师确认交易的税务影响，防范潜在追溯责任。

Q181：MiCA是否禁止或限制DeFi业务？去中心化协议是否能持牌？

答：MiCA当前主要适用于中心化服务提供者（CeFi），不直接约束真正“无管理人”的完全DeFi协议。但在以下情况下，DeFi也可能落入MiCA监管范围：

  • 若存在前端运营方或平台方（如DEX前端网页），该方需注册为CASP；

  • 若提供Token发行、撮合、托管等服务并向欧盟用户开放，也需MiCA合规；

  • MiCA强调“实际控制人即责任人”，即便代码开源，也无法规避运营责任。

建议DeFi项目设立“合规代理实体”负责前端、营销与合规对接，保持协议本体中立性。

Q182：自动化做市商（AMM）是否属于MiCA“交易平台”？是否需要牌照？

答：取决于是否涉及撮合功能与代币管理职能：

  • 若AMM运行在中心化平台上（如Binance Pool），平台需作为交易平台持牌；

  • 若AMM本身仅作为协议逻辑（如Uniswap）且无实际控制方，可能不属MiCA监管对象；

  • 若AMM涉及固定流动性提供、利润返还等机制，或由法人结构托管，则应作为CASP监管。

建议平台使用AMM模块时需明确其运行主体，并结合MiCA第76条“资产撮合义务”进行事前评估。

Q183：客户死亡或破产后，其加密资产如何处理？MiCA有无指引？

答：MiCA未详列此类民事问题，但要求平台：

  1. 建立《客户死亡或丧失行为能力处理机制》；

  2. 保留法定继承/授权路径，例如：

    • 死亡证明+继承授权；

    • 授权书+公证身份验证；

  3. 禁止平台私自转移资金或长期冻结不处置；

  4. 若无合法继承人或无人申领，最终向监管登记为**“无主资产”**。

建议用户在开户时设置“应急联系人”，平台可配合客户设立“冷钱包遗产保障机制”。

Q184：MiCA平台是否必须为每位客户开立独立钱包？可否使用归集钱包？

答：MiCA允许平台使用归集钱包（omnibus wallet），但前提为：

  • 平台应清晰记录每笔资金归属客户；

  • 具备每日对账与交易日志审计机制；

  • 若平台破产或冻结，客户资产应优先排除于破产财产之外；

  • 系统应具备随时生成“客户资产余额明细”的能力。

推荐使用归集主钱包+内部子账户模型，并定期审计资产归属完整性。

Q185：平台是否可要求客户绑定银行卡/欧盟账户？MiCA有无强制？

答：MiCA未强制绑定，但在以下场景中强烈建议：

  • 客户身份验证（KYC）过程可通过银行账户辅助验证；

  • 可防止洗钱或“跳转洗白”资金来源；

  • 平台提款至绑定账户可避免第三方转账风险。

但平台必须提供可替代机制（如SEPA转账、电子钱包），确保不构成歧视性服务障碍。

Q186：MiCA是否允许向非欧盟客户提供服务？是否需要跨境备案？

答：MiCA监管范围为“向欧盟客户提供加密资产服务”，并不管辖非欧盟外客户服务，但：

  • 若平台总部设于立陶宛或欧盟境内，其服务原则上不得违反他国法律；

  • 对美国、新加坡、中国等地区的客户，应遵循属地监管规定；

  • 可设置“Geo-fencing机制”限制服务范围。

建议平台在合规政策中加入《非欧盟客户使用声明》，并设置IP地理屏蔽/限制注册机制。

Q187：是否可以发行结构化代币产品，如VA-ETF、VA-ETN等？是否MiCA牌照覆盖？

答：若结构化产品以加密资产为底层（如BTC ETF、ETH ETN），可能涉及以下监管：

  • 产品发行者：如不直接面向零售，则可能仅需MiCA通报；

  • 若产品具证券性质（收益权、利率等） → 落入MiFID II；

  • 若平台分销、撮合该类产品 → 须持MiCA的“投资建议/执行订单”许可。

建议结构化产品发行前出具法律定位意见书，并设立产品披露说明 + 风险警告机制。

Q188：平台是否可提供“交易挖矿”或“积分奖励”计划？是否构成回报诱导？

答：可以，但MiCA要求：

  • 所有奖励机制应在客户协议中明确披露规则与分发逻辑；

  • 若奖励具币值或可交易，应视为“平台发行代币”并需登记说明书；

  • 不得诱导误导性交易、强制参与、伪装成利润返还。

建议将奖励机制纳入商业计划书中，并设《平台激励机制合规文件》。

Q189：MiCA是否强制平台展示风险提示和适当性评估？如何设置？

答：强制要求。MiCA规定：

  • 平台必须对所有客户进行风险测评（例如问卷）；

  • 客户下单前需再次确认适当性评估结果；

  • 高风险资产或复杂产品需展示额外警告；

  • 若客户被评为“不适合”但坚持交易，平台应保留其风险确认声明记录。

推荐设置电子签署流程 + 每年重新评估机制，记录用户签署结果备查。

Q190：平台计划向第三方开发者开放API服务，是否MiCA允许？是否需申报？

答：允许，但需遵守以下条件：

  • 必须确保第三方不构成CASP业务本体代理（否则需合规披露）；

  • 对接方需完成KYC/KYB（若获取用户数据）；

  • 应与第三方签订《数据保密协议》《使用边界协议》；

  • 所有API调用日志应可追踪，且合规团队可审核；

  • 若API接入方向客户提供投资建议、交易指令等服务，视同委托服务商，平台需承担监管责任。

建议开放前提交《API服务合规结构图》与说明书向BoL备案。

Q191：NFT是否纳入MiCA监管？是否需要注册为CASP？

答：MiCA 对 NFT（Non-Fungible Token）采取功能导向而非形式导向原则：

  • 若 NFT真正独一无二（如数字艺术品、门票），则不纳入MiCA监管范围；

  • 若所谓NFT可批量发行、分拆流通、可交易且类似证券/投资工具（如1万个头像项目），则可能被认定为“加密资产”而纳入MiCA；

建议项目方就NFT是否属于MiCA下的“可交易资产”出具法律意见书。如疑似证券型NFT，应考虑申请CASP牌照或MiFID II监管。

Q192：算法稳定币是否允许？是否受MiCA禁止？

答：MiCA明确禁止“无资产支撑”的算法稳定币用于支付或公众推广。以下为关键规定：

  • 所有ART（资产参考型代币）与EMT（电子货币代币）必须有清晰可核查的储备资产支持；

  • 算法机制不能作为唯一支撑机制；

  • 若项目存在储备资产 + 调节机制并通过监管评估，可能构成“混合型稳定币”；

  • 若无资产支撑、靠价格反馈自平衡（如早期UST）→ 明确禁止。

建议稳定币项目需将储备机制、清算优先级、波动风险应对机制纳入白皮书与商业计划书。

Q193：平台是否必须设置“客户保护基金”或“风险储备金”？MiCA有无强制？

答：MiCA对大多数服务商未强制设立“保护基金”，但要求：

  • 客户资产应与平台自有资产完全隔离；

  • 若提供托管或交易平台服务，必须设立客户资产保障机制；

  • 若平台发行代币（EMT/ART），则需设立1:1资产储备账户；

  • 可选机制：客户赔偿保险、平台自愿建立风险储备金等。

推荐设置独立托管账户（Escrow）、与保险公司合作、披露赔付政策。

Q194：MiCA是否要求平台必须配备法律顾问？是否需聘请第三方合规顾问？

答：MiCA不强制平台聘请法律顾问，但若涉及以下情形，强烈建议聘用专业团队：

  • 平台涉及跨境服务、复杂金融产品；

  • 同时具备MiFID或EMI等牌照结构；

  • 面临监管通报、客户争议或STR报告处理；

多数平台实际操作中，将合规顾问纳入公司治理结构，配合董事会与MLRO进行合规沟通。

Q195：平台是否必须设置“合规委员会”？MiCA有明确结构要求吗？

答：MiCA对平台治理结构保持弹性，但对以下角色有强制要求：

  • 至少两名独立高级管理人员，不能由单人控制所有运营；

  • 配置独立的MLRO（反洗钱官），可兼职但不得缺失；

  • 若平台规模大或服务类型多，建议设置“合规委员会”，负责：

    • 监督AML/KYC执行情况；

    • 审查合规报告；

    • 参与董事会重大合规决策。

合规委员会并非强制，但为通过BoL审批及年审建议主动建立。

Q196：客户资金可否存在第三方银行账户？是否可设Omnibus账户？

答：允许使用第三方银行（如SEB、Luminor）设立Omnibus账户（归集账户），但需满足以下条件：

  • 每笔客户资金应有内部台账记录其归属；

  • 账户余额每日对账，并可审计；

  • 平台破产时该账户下资金优先退还客户，不纳入清算资产；

  • 推荐开设独立币种账户（EUR、BTC、ETH等）并定期审计。

可搭配“信托声明函”或“客户资产保障政策”予以说明。

Q197：MiCA对“非公开募集Token”的要求有哪些？是否仍需提交说明书？

答：若满足以下条件，可豁免说明书提交：

  • 向不超过150名“非专业投资人”募集；

  • 总募集金额低于100万欧元；

  • 非透过公开平台发布；

  • 持有期满12个月后才可流通；

否则，需向监管机构提交简易说明书，内容包括：

  • 项目介绍；

  • 投资风险说明；

  • 技术结构与治理机制；

  • 投资人权利义务声明。

即使豁免说明书，平台亦应进行内部合规评估及KYC流程留档。

Q198：MiCA是否接受跨国控股公司申请？如母公司为新加坡/香港公司？

答：可以，但需满足以下前提：

  • 控股结构图需穿透至最终实益拥有人（UBO）；

  • 所有海外股东提供无犯罪记录、资质说明、尽职调查；

  • 母公司需出具资金合法来源声明与商业合理性说明；

  • 若实际运营/技术团队设于境外，需说明跨境合规机制与监管配合机制。

推荐设立立陶宛本地实体为申请主体，控股公司作为战略投资方。

Q199：MiCA是否接受“远程办公”团队或分布式开发团队？是否影响实质性经营判断？

答：可以，但必须证明以下几点：

  • 公司核心决策权与合规制度执行权位于立陶宛或欧盟境内；

  • 本地负责人常驻办公并具实质签署权；

  • 保留所有关键职能的执行记录，包括远程会议、文件审批等；

  • 若系统部署、数据库或技术团队位于境外，应设置灾备同步与数据访问控制机制。

建议设立本地运营子公司 + 远程技术外包框架，并由立陶宛总部持牌、管理。

Q200：MiCA牌照获得后，是否需要单独注册为欧盟跨境金融机构？如何实现passporting？

答：MiCA牌照本身具备欧盟统一通行权（passporting），但需履行以下程序：

  1. 向所在国家（如立陶宛BoL）提交跨境通行申请，列明目标国家；

  2. BoL向目标成员国的监管机构进行通知与备案；

  3. 一般5~20个工作日内完成备案；

  4. 获得批准后可在目标国家开展对应服务，无需再次申请当地牌照。

通行范围包括欧盟27国 + 欧洲经济区3国（冰岛、列支敦士登、挪威）共30国。

Q201：项目若设置Token销毁机制（burn），是否符合MiCA合规规定？

答：Token销毁机制（burn）并不被MiCA直接禁止，但需满足以下条件：

  • 必须在白皮书中明示销毁机制的触发条件与数量；

  • 销毁行为不得构成市场操纵或误导性炒作；

  • 若代币为EMT/ART型，销毁机制必须保持储备资产与发行量的比例匹配；

  • 销毁后代币数量与持有人权益变化必须记录在账并可审计；

建议搭配“Token经济白皮书附表”说明销毁逻辑，并记录每次销毁事件的公示公告。

Q202：平台是否允许设置“代币回购”机制？是否构成市场干预？

答：MiCA未全面禁止平台回购机制，但以下类型属高风险行为：

  • 平台以回购承诺吸引投资者 → 可能构成类证券发行；

  • 回购价格远高于市价，可能被监管视为价格操纵；

  • 回购行为不透明，可能构成内幕交易；

合法做法包括：

  • 在白皮书中清晰定义回购触发条件；

  • 设定合理的流动性池控制策略；

  • 所有回购记录应保留并披露于年报或官网；

强烈建议附带法律合规意见书，并避免高频“价格托底”宣传。

Q203：锁仓期（lock-up）是否需申报？是否需写入白皮书？

答：是的。MiCA对任何锁仓安排都要求透明披露：

  • 包括创始人/团队锁仓、投资人锁仓、空投锁仓等；

  • 必须披露锁仓起止时间、释放比例、解锁机制；

  • 若未如实披露，可能构成虚假或误导性陈述；

建议在“Token Allocation”章节以图表说明，并定期更新官网释放进度。

Q204：平台是否可委托第三方提供虚拟资产托管服务？是否影响合规责任？

答：可以委托第三方托管服务（如BitGo、Fireblocks），但：

  • CASP平台本身仍对客户资产负最终合规与赔偿责任；

  • 第三方需是欧盟内注册的合规托管机构，具相关执照；

  • 须签署详细的托管协议 + 提供托管安全架构说明；

  • 客户需在开户流程中确认托管安排并签署确认同意书；

推荐附带《托管安全白皮书》或技术架构图向BoL提交。

Q205：若Token有“再发行”机制（Reissuance），是否需重新备案？

答：需视情况而定：

  • 若再发行额度不超过原计划总量，且机制已在说明书中披露 → 无需另行备案；

  • 若追加发行突破原设计上限，或更改再发行逻辑 →需重新提交白皮书变更申请；

  • 若新发行涉及新投资人、新用途，则可能构成**新一次“公开发行”**行为。

建议将发行上限、再发行策略写入商业计划书，并由董事会决议记录。

Q206：平台是否可以同时提供资产管理与交易服务？有何监管边界？

答：可并行提供，但须符合以下原则：

  • 业务隔离：资产管理业务（如代客理财）不得与交易平台撮合功能混合使用；

  • 利益冲突管理：平台自营不得优先执行自身订单；

  • 客户授权明确：资产管理类需有明确委托授权文件，避免非法集资嫌疑；

  • 不同服务须申请不同CASP许可类别；

实操建议：资产管理业务可通过子公司进行，或持MiFID类许可并接入MiCA监管。

Q207：是否允许平台同时提供加密资产与证券/基金产品的销售？是否涉及MiFID或UCITS监管？

答：MiCA仅覆盖非证券型加密资产。若平台提供：

  • 证券型代币（STO）、基金类产品 → 必须额外申请MiFID、UCITS或AIFMD监管牌照；

  • MiCA不适用于代币化证券或合规债券→ 属传统金融监管范畴；

MiCA服务商可作为技术平台与STO发行方合作，但不能主动销售证券型资产。

Q208：平台数据是否可使用“云存储”系统？是否需备案或特定云供应商？

答：允许使用云服务，但须满足以下条件：

  • 数据存储必须在欧盟境内或受欧盟GDPR认可的国家；

  • 云供应商需提供数据加密、防篡改、灾备机制；

  • 合同中必须注明数据所有权归平台所有，并设有监管应急接口；

  • 对于关键数据（交易记录、身份信息）建议保留本地镜像备份。

常见合规云：AWS欧洲区、Google Cloud EU、Microsoft Azure EU。

Q209：项目是否必须每年更新白皮书与商业计划？MiCA有频率要求吗？

答：MiCA未明确要求“每年”更新白皮书，但以下情形必须更新：

  • 服务范围、代币结构、资本情况等发生重大变化；

  • 技术架构发生实质调整（如迁移链、权限修改等）；

  • 客户适当性政策、托管机制有变化；

  • 法规要求定期更新说明文件（如ESMA指导变化）；

建议每年年审时同步更新白皮书、商业计划及披露文件。

Q210：MiCA是否允许平台设置推荐返佣（Referral Rewards）？是否构成证券行为？

答：可以设置，但必须合法透明：

  • 推荐机制不能与代币价格直接挂钩；

  • 不得误导为“投资回报保证”；

  • 建议设为“积分”或“优惠券”形式，而非支付实物Token；

  • 推荐人应履行客户合规身份传递职责（如收集KYC基础信息）；

实务中建议用“客户引荐政策”并附责任边界说明，避免监管误解为非法募资。

Q211：MiCA下是否允许平台提供“杠杆交易”或“保证金功能”？

答：MiCA本身未涵盖杠杆类交易的完整监管框架，以下情况应注意：

  • 若平台提供衍生品、杠杆交易，将可能被划入《MiFID II》监管体系；

  • 任何保证金机制需明确风险披露，并防止用户资产遭平台挪用；

  • 必须具备清晰的风险限额系统、强平机制与用户教育材料；

若平台主营业务涉及杠杆或合约产品，建议同步申请投资类金融服务牌照（MiFID）或分拆业务结构。

Q212：CASP申请企业的母公司如为加密基金或交易所，会否影响MiCA审批？

答：不会直接影响审批，但需满足以下合规要求：

  • 母公司结构透明、无监管负面记录；

  • 披露最终控股人（UBO）并进行KYC/AML尽调；

  • 提供集团图示及集团间业务隔离说明；

  • 若存在潜在利益冲突（如集团内交易），必须具备冲突管理政策（Conflict of Interest Policy）；

推荐附加《集团结构穿透图》及母公司近两年合规审计报告。

Q213：MiCA是否允许项目代币在多个交易所同时上线（Multi-listing）？是否须备案？

答：可以多平台上线，但须符合以下规定：

  • 所有上线交易所必须为合规注册交易平台（含第三国平台）；

  • 必须在白皮书中说明上线计划与流动性策略；

  • 若上线造成代币结构变动（如锁仓打破），必须向BoL通报；

建议保留每次交易所谈判/签约记录，并披露上线平台的监管状态。

Q214：平台是否可以向非欧盟国家客户提供服务？有哪些条件？

答：原则上可以，但应满足以下要求：

  • 须在非欧盟客户国无**“主动营销”行为**（不得进行投放或拉客）；

  • 仅限“被动接受”非欧盟客户注册；

  • 若客户数超过特定比例，建议申请当地监管备案或报告；

  • 保证客户KYC/AML标准不低于欧盟要求；

实操建议设定「地理限制机制」，如限制某些国家IP注册、语言识别机制等。

Q215：MiCA CASP牌照是否可以“转让”或“收购”？是否需要监管批准？

答：不可以直接转让，但可以通过股权收购变更形式实现间接控股，条件如下：

  • 任何股东持股**超过20%、33%、50%、75%**等重要阈值，必须事前获BoL批准；

  • 新股东需提交完整KYC、资金来源、无犯罪记录等；

  • BoL将对受让方进行适当人选审查（Fit & Proper）；

收购建议在合同前先获得非正式意见书（pre-clearance），降低交易风险。

Q216：MiCA是否要求平台拥有“专职合规官”？合规官是否必须在立陶宛本地？

答：必须有专职MLRO合规官，其职责包括：

  • 定期提交STR（可疑交易报告）；

  • 保证客户身份识别（KYC）流程到位；

  • 接收监管指令、进行年报汇总；

  • 实施培训与稽核制度；

合规官不强制在立陶宛办公，但需确保：

  • 有清晰汇报路径；

  • 可应对监管沟通与实地稽核；

  • 留存工作日志、培训记录、客户监测情况等文件 ≥ 5年。

Q217：MiCA是否禁止平台发行“可变利率”或“浮动收益”型Token？

答：不完全禁止，但须判断是否变相证券产品：

  • 若平台承诺“保本+浮动收益”或“本金+激励”模式，易被视为投资合约 → 涉及MiFID监管；

  • 若收益挂钩某种资产指数、利率或Token回购机制，必须披露风险并进行备案；

  • 建议避免使用“收益率”“固定利息”等表述，防止误导投资者；

实操中此类Token建议通过AIFMD或MiFID结构发行，而非MiCA。

Q218：MiCA监管是否延伸至NFT（非同质化代币）？

答：MiCA原则上不涵盖NFT，前提是：

  • NFT为独一无二，不可替代，如数字艺术、会员证书；

  • 不用于投资或支付工具；

  • 不构成代币化证券或基金权益；

⚠️ 若NFT具备流动性、分割权、保底收益等特性 → 可能被监管重分类为“加密资产”。

若项目涉及大量NFT+Token互动，建议提交法律意见书确认其属性。

Q219：CASP项目若在链上执行交易撮合，是否仍需向监管说明撮合机制？

答：是的。即使使用DeFi协议或链上自动撮合，仍需说明：

  • 区块链合约执行逻辑（附代码审计报告）；

  • 撮合逻辑是否公平、可回溯；

  • 平台是否能“干预”或“撤销”撮合流程；

  • 有无KYC把关机制，是否存洗钱风险；

建议附《撮合机制说明书》+《DeFi系统风险评估报告》。

Q220：MiCA监管是否涵盖平台内“点对点交易（P2P Exchange）”？

答：是的，若平台：

  • 提供撮合服务（不论是中心化还是撮合市场）；

  • 或设置买卖看板/报价信息；

  • 或协助资产转移、担保托管等功能；

则即使是P2P撮合，也被视为加密资产交易服务提供者，须申请CASP牌照。

仅提供工具型钱包（不经手资金）或单纯广告平台则可豁免，但边界较模糊，建议保留合规意见函。

Q221：CASP是否必须为每种加密资产分别设置KYC和适当性评估等级？

答：是，MiCA要求CASP对不同加密资产风险特性进行适当性分类，至少区分：

  • 高波动资产（如小市值代币、未上市资产）；

  • 稳定币类（ART/EMT）；

  • 高复杂产品（如结构化代币、合约型Token）；

每类客户须完成对应的适当性评估问卷，并依据评估结果赋予不同权限。

建议制定《客户分类政策》和《适当性模型评分矩阵》，作为合规文件保存。

Q222：平台是否可对客户交易行为设置“风险限额”或“冷静期”？

答：可以，且是良好的合规实践。建议设置如下机制：

  • 客户首次交易设定限额（如€5,000以内）；

  • 高频交易者需通过二次适当性评估；

  • 若客户连续亏损或异常操作，建议触发交易冷静期机制（如24小时提示）；

上述功能应在平台系统中预设，记录日志供合规审计使用。

Q223：平台是否需为客户提供“风险揭示文件”？内容应包含哪些要素？

答：是。平台必须在开户前提供标准化的《风险披露书》，内容应包括：

  • 加密资产价格波动性；

  • 系统性风险（黑天鹅事件）；

  • 技术风险（系统故障、钱包被盗）；

  • 法律合规风险（监管政策变动）；

  • 税务风险（客户自行申报义务）等；

文件建议提供多语言版本，并保留客户签署或点击确认记录 ≥ 5年。

Q224：MiCA是否允许设立“独立托管子公司”以运营客户资产管理？

答：可以。平台可设立单独的托管公司（Custody Entity）作为合规隔离机制，但需符合：

  • 明确法律主体分离；

  • 资产与平台自营账户完全隔离；

  • 向监管申报托管服务计划书与流程图；

  • 客户授权协议明确交由托管方保管资产；

实操建议参考《银行级别账户隔离》要求，同时增加托管审计机制。

Q225：MiCA是否允许CASP平台自营代币（Platform Token）？有何条件？

答：可以，但有严格限制：

  • 必须在申请白皮书备案时声明该代币为“自营发行”；

  • 若该代币用于支付、激励、治理，不能具有保本或回购承诺；

  • 平台不得通过“操控市值”或“内幕交易”影响其价格；

  • 所有相关交易必须建立内控流程与利益冲突披露机制；

建议附《平台自营Token内部控制政策》和《价格稳定风险报告》。

Q226：如果平台希望同时提供法币兑换、卡支付等服务，是否需额外申请EMI？

答：视业务而定：

  • 若平台仅提供第三方支付接口接入（如通过银行API），无需额外EMI；

  • 若平台自己发行电子货币、提供预付账户或提供卡服务，则须同时申请电子货币机构（EMI）牌照；

  • 多数合规策略为“MiCA + EMI 双牌照”架构运营；

建议使用统一合规架构文档打通两类牌照（如共享KYC系统、AML政策等）。

Q227：平台是否可以对不同国家客户采取“差异化限制策略”？

答：可以，MiCA鼓励风险导向的合规策略。差异化策略包括：

  • 高风险国家客户需加强KYC及Liveness Check；

  • 禁止或限制来自受制裁国家IP的注册（如朝鲜、叙利亚、伊朗等）；

  • 为低风险地区客户设定简化适当性测试通道；

实操建议建立一套《国家风险评估等级清单》，并定期更新。

Q228：是否必须向客户提供完整“交易对账单”？如客户要求删除历史数据如何处理？

答：必须提供对账单。MiCA与GDPR结合的合规逻辑为：

  • 所有交易日志、资金变动、KYC行为等数据需保留≥5年；

  • 客户有权查看历史数据，但不能请求删除“合规留存资料”；

  • 对账单应支持PDF导出，建议提供月度/年度对账记录功能；

可在隐私政策中声明哪些资料不予删除，以符合监管与数据权利的平衡。

Q229：是否强制开展员工合规培训？频率和内容如何规定？

答：是，MiCA明确要求：

  • 所有关键岗位人员（客服、交易支持、技术、运营）每年至少1次合规培训；

  • 培训应涵盖KYC、AML、数据保护、客户投诉处理流程等；

  • 需保留签到表、培训材料、评估反馈报告等记录 ≥ 5年；

可采用内训 + 外部专业培训结合形式，记录将作为年审合规材料一部分。

Q230：是否必须设置“客户投诉处理机制”？有何具体流程建议？

答：是。MiCA要求CASP设置可追溯的客户申诉机制：

  • 建立专属投诉邮箱或在线系统；

  • 投诉应在7日内响应、30日内答复；

  • 投诉记录须分类存档（已解决/未解决/待调查）；

  • 每年统计投诉类别与数量，提交年报；

推荐使用《客户投诉管理登记表》+《处理流程图》，规范内部响应流程与追踪机制。

Q231：平台若采用双Token模型（如治理币 + 实用币），在MiCA下如何申报？

答：MiCA下必须分别申报并分类备案：

  • 治理Token若带有增值权益或持有者表决权，可能被视为证券型代币或需进行完整白皮书申报；

  • 实用Token需说明用途范围、非金融属性、不可承诺固定收益；

建议平台提供《双Token白皮书披露说明书》，清晰划分功能、流通机制、风险点。

Q232：CASP公司是否可以同时为加密基金提供资产管理服务？

答：可以，但需明确业务边界：

  • 若服务客户为机构客户或专业投资人，MiCA框架内允许提供资产管理服务；

  • 若涉及公募、投资建议、代客理财，可能需申请额外资产管理牌照（如AIFM或MiFID许可）；

建议采用“附加服务授权”方式，与当地监管机构沟通是否需额外许可或登记。

Q233：如果公司采取DAO治理结构，是否可作为MiCA持牌主体？

答：不建议直接以DAO为持牌主体：

  • MiCA要求明确法人实体（如UAB公司）；

  • DAO可作为社区/治理参与架构存在，但合规责任主体必须清晰；

  • 建议将DAO转化为“治理层”或“Token持有者委员会”，并由公司执行日常运营与监管对接；

可提交《DAO参与结构图》与《实体治理责任说明函》，满足ESMA的信息要求。

Q234：CASP是否可以通过API对接多家交易所、钱包服务商进行撮合？

答：可以，但须注意以下合规要点：

  • 所有第三方系统对接需提供安全审核报告或API接入说明；

  • 如接入非欧盟受监管服务商，平台需自行承担KYC责任；

  • 应保留所有对接日志、接口调用记录 ≥ 5年；

推荐建立《第三方系统接入清单》与《定期审查机制表》。

Q235：平台使用AI进行KYC审核是否合规？是否仍需人工复核？

答：可以使用AI辅助KYC审核，但不能完全替代人工：

  • 适用于识别身份证件、Liveness检测、行为分析等；

  • 人工审核应对高风险客户、文件模糊、交易异常情况进行补充确认；

  • 必须记录AI使用的算法、审核参数、拒绝原因等；

应配套《AI KYC使用政策》+《人工复核流程图》，提交监管审核时提供。

Q236：冷钱包托管是否可分布式设置于多个国家？

答：技术上允许，但需满足以下条件：

  • 钱包权限管理系统需明确节点地理位置；

  • 若托管节点在欧盟境外，需提供等效数据保护说明；

  • 多签机制建议配置 ≥3个签名人，至少2个节点设于欧盟境内；

提交《冷钱包托管说明书》时应列明各节点所在司法辖区与合规控制链条。

Q237：客户资产是否必须每日对账？如何实现？

答：MiCA鼓励每日自动对账机制，尤其是客户托管资产：

  • 建议设置每日自动化对账流程（总账 – 区块链 – 内部子账户）；

  • 发现差异 >0.1% 应立即调查并汇报合规官；

  • 建议提供客户每日资产变动提示（短信/邮件/APP推送）；

可使用《每日对账检查表》+《自动对账系统审核报告》。

Q238：如何证明CASP公司具备“持续经营能力”？监管如何判断？

答：持续经营能力可通过以下方面体现：

  • 完整的三年财务预测（收入、成本、利润）；

  • 明确的融资来源或储备金说明；

  • 实缴资本金证明文件及银行存款单；

  • 技术系统稳定运行的证据（Uptime报告、冗余设计等）；

推荐提交《持续经营能力说明书》作为补充材料。

Q239：若平台设立“推荐返佣机制”，是否违反MiCA规定？

答：MiCA并不禁止推荐返佣，但需合规披露：

  • 所有推荐人应实名登记，KYC审查；

  • 返佣模式需公开披露，包含计算逻辑与返佣比例；

  • 若推荐行为触及投资建议范畴，推荐人可能需持MiFID许可；

建议平台制定《推荐人计划政策书》并附合规声明。

Q240：是否可以设立“欧盟以外客户专区”进行分隔管理？

答：可以。为防范跨境监管冲突，可：

  • 将非欧盟客户数据、交易流程单独模块化管理；

  • 实行不同KYC标准（如适用FATF高风险区域额外措施）；

  • 披露该区块不受MiCA全面保护，客户自负风险；

建议提交《国际客户分区管理政策》和《风险告知书（多语种）》。

Q241：MiCA持牌CASP是否需要履行CRS或FATCA申报义务？

答：MiCA本身不直接规定CRS/FATCA，但如果CASP提供托管服务或客户账户具有金融账户属性，则可能：

  • 被纳入金融机构定义（FI），需执行CRS/FATCA申报；

  • 所在国（如立陶宛）规定已明确部分CASP需履行自动信息交换义务；

  • 建议在开户环节加入FATCA问卷、W-8/W-9收集机制；

应编制《FATCA/CRS分类说明书》+《税务居民识别流程图》。

Q242：监管是否要求平台建立可疑交易模式（STR）自动识别机制？

答：强烈建议设立。根据AMLD6与MiCA协同监管：

  • 平台应具备自动识别异常交易行为的系统（如：快速大额转账、频繁地址变更）；

  • STR生成逻辑必须可审计，输出日志需保留≥5年；

  • 不要求100%自动触发，但必须“辅助人工判断”；

推荐建立《STR触发逻辑模板》+《疑似行为预设清单》。

Q243：MiCA CASP是否需要委任外部IT审计师？审计频率是多少？

答：需要。BoL（立陶宛银行）建议：

  • 至少每年一次外部IT系统审计；

  • 如涉及冷钱包、多签机制，建议每半年一次；

  • 选择具备欧盟合格审计资质（如ISO 27001审计员）；

建议提交《IT审计计划书》+《审计机构资质声明》。

Q244：数据备份与灾难恢复（Disaster Recovery）有哪些强制要求？

答：MiCA对数据保全非常重视：

  • 所有客户数据应至少每日备份一次；

  • 灾难恢复方案（DRP）必须定期演练，记录演练结果；

  • 备份数据需存放于欧盟境内合规数据中心；

提供《灾备计划》+《演练记录表》，供监管审阅。

Q245：CASP平台是否可以设立多品牌、多网站运营？如何监管认定？

答：可以，但必须：

  • 明确主牌照覆盖的品牌/域名清单；

  • 各品牌之间必须信息同步、共享KYC记录；

  • 禁止出现“未备案业务”或“虚假子品牌误导客户”；

应编制《品牌/域名使用说明书》并登记在监管平台。

Q246：当RO（负责人员）离职时，是否需要重新申请MiCA牌照？

答：不需重新申请牌照，但必须：

  • 在5个工作日内向BoL提交《高管变更通报》；

  • 提交新RO的尽职调查资料、任命决议、无犯罪记录等；

  • 若无合适替代者，可委任临时RO，时限不得超过3个月；

建议准备《RO替换标准流程包》+《过渡期间运营授权书》。

Q247：是否可以将部分CASP职能（如IT开发）外包？是否需要报备？

答：可以外包，但须符合法定程序：

  • 所有外包活动（含IT、客服、清算）需签署合规外包协议；

  • 平台需承担全部最终责任，并确保服务商配合审计；

  • 外包至非欧盟国家需提交数据传输合规报告；

可用《外包服务清单》+《合规外包框架协议》作为证明材料。

Q248：虚拟资产是否可用于支付牌照年费、保证金或审计服务费用？

答：否。所有监管相关费用：

  • 需以欧元（EUR）或立陶宛央行认可法定货币支付；

  • 不得以BTC、ETH等代币缴纳；

  • 不符合此规定将导致年审无效或申请中断；

财务账户需设有独立的“监管开支账户”。

Q249：MiCA对客户“适当性评估”要求有哪些？是否适用于所有服务？

答：MiCA要求CASP根据客户类型进行差异化评估：

  • 普通客户需了解风险、用途、流动性；

  • 专业客户可简化流程，但仍需保留足够证明；

  • 所有交易前应进行适当性匹配，如限额、产品过滤等；

建议实施《适当性评估模型》+《交易提示机制设计方案》。

Q250：如MiCA牌照被吊销，平台是否必须立即关闭业务？

答：需按以下流程迅速处置：

  • 在吊销通知后5个工作日内，停止所有对外服务；

  • 启动客户资金清退机制，完成通知与退款；

  • 报送最终审计、清算报告及客户列表至BoL；

建议设立《牌照吊销应急响应预案》。

Q251：是否可以在平台内设置“加密资产利息”功能（即：存币生息）？

答：MiCA对加密资产利息类产品管控严格：

  • 非EMI类CASP不得吸收公众存款或发息；

  • 若设置生息类功能，可能被界定为“准银行业务”，需额外获得授权（如EMI）；

  • 建议仅限专业投资人，且附加《高风险披露说明》；

提供《客户生息风险告知书》+《业务非存款承诺声明》。

Q252：MiCA是否允许进行Token Buy-back（项目方回购）机制？

答：允许，但需合规设定：

  • 回购安排必须在发行前明示（含比例、频率、操作方式）；

  • 禁止用于操纵市场或误导价格；

  • 建议保留回购资金托管账户，并记录所有回购行为；

可附《回购机制设计说明》+《交易记录存证方案》。

Q253：平台Token若赋予“利润分成”性质是否构成证券型代币？

答：可能构成证券型代币，超出MiCA范围：

  • 若Token具有收益分红、投票、治理权利等属性，需根据MiFID II或Prospectus Regulation重新评估；

  • 可委托律所出具《不构成证券法律意见书》；

建议所有Token发行前进行《Token Classification Matrix》分析。

Q254：在多个欧盟国家设立客服/运营团队是否影响MiCA监管？

答：不会影响牌照本身，但需备案：

  • 需报备各个国家的运营活动类型与人员规模；

  • 各地数据处理活动需符合GDPR；

  • 主牌照公司仍需承担统一监管责任；

建议附《多地运营说明文件》+《数据传输合规图》。

Q255：MiCA平台是否能开放API供第三方开发者使用？

答：可以，但前提条件是：

  • 第三方须完成身份核实（KYC/开发资质）；

  • 所有调用行为需具备访问权限日志和撤销机制；

  • 建议设置安全网关与授权管理模块；

提交《开放API接口使用说明书》+《第三方合规接入流程图》。

Q256：MiCA是否要求平台设立“黑名单机制”以拒绝高风险客户？

答：是。MiCA结合AMLD6要求平台：

  • 维护实时黑名单系统（含制裁国家、恐怖组织、已知欺诈行为者）；

  • 设定自动拒绝/冻结交易指令规则；

  • 与欧盟制裁数据库（如：EU Sanctions Map）保持同步；

提供《客户拒绝机制策略》+《黑名单匹配引擎说明》。

Q257：平台是否必须支持立陶宛语作为服务语言？

答：建议支持但非强制：

  • 立陶宛监管文件（申请材料、通报信函）须使用立陶宛语或英文；

  • 客户界面语言推荐支持英文+目标市场官方语言；

  • 若面向立陶宛本地零售客户，应具备LT语言版本并含法定提示语；

可提供《平台语言合规配置声明》。

Q258：客户资产与公司自有资产是否可以使用同一钱包？

答：绝对禁止混用：

  • 客户资产必须独立保管于专用钱包地址（带标签标识）；

  • 公司热钱包与冷钱包需物理隔离；

  • 需提供地址映射关系及第三方审计报告；

提交《资产隔离控制制度》+《钱包结构分层图》。

Q259：平台被盗或被攻击后，是否必须第一时间通知监管？

答：是，MiCA配合DORA法案（数字营运弹性条例）要求：

  • 所有数据泄露、安全入侵、客户资产风险事件需在24小时内上报BoL；

  • 同时发出客户通知与冻结高风险交易；

  • 事件处理流程需备案并接受审计；

建议制定《重大事件通报机制》+《应急通讯模板》。

Q260：是否可以采用多国牌照结构运营多个平台？（如A国发币、B国托管）

答：可以，但需明确主监管关系：

  • 多国结构中，应设立一国为“主运营+主监管”所在地（如：立陶宛）；

  • 其他国家如无MiCA主牌照，仅可作为子结构存在；

  • 需提交《集团结构图》+《功能划分声明》+《监管协调信函》；

建议整合为《集团级MiCA牌照运营说明书》。

Q261：MiCA对NFT（非同质化代币）是否适用？是否需要CASP牌照？

答：MiCA对NFT的监管采用“功能性判定”而非“形式豁免”，若满足以下情形，仍需申请CASP牌照：

  • NFT带有金融投资属性（如：分红、收益回购、市场炒作）；

  • NFT批量发行、具有互换性或部分可分割性；

  • 项目运营者提供NFT交易、托管或二级市场撮合服务；

建议提前出具《NFT非金融属性法律意见书》以规避监管风险。

Q262：MiCA平台能否允许用户以“匿名地址”进行充值或提现？

答：否。MiCA搭配《反洗钱第六指令（AMLD6）》要求：

  • 禁止使用无法溯源的“匿名钱包地址”（如：未注册托管钱包）；

  • 必须记录每笔交易的KYC身份及钱包所有权（包括地址标签化）；

  • 建议集成“链上地址分析服务”（如Chainalysis）自动识别高风险来源；

强制要求提供《链上钱包地址识别与验证机制说明》。

Q263：MiCA平台能否设置“内部积分”或“平台币”？

答：可以，但若积分具备“可转让”“可兑换”“可投资”性质，MiCA将视同加密资产管理：

  • 若积分可用于跨平台兑换或二级市场交易，则需申报为“加密资产”；

  • 平台币或积分需设立《白皮书》并提交备案；

  • 强烈建议进行“Token分类评估”以避免违规；

提供《平台积分非加密资产说明书》及系统隔离模块设计。

Q264：员工是否需进行定期合规培训？是否有备案要求？

答：是。MiCA配合AMLD6强制要求：

  • 每年至少一次全体员工反洗钱及数据保护培训；

  • 高级管理层、MLRO、IT负责人等需专项深度培训；

  • 培训内容、人员名单、签到记录、试卷成绩须备案保存≥5年；

建议建立《合规培训制度手册》+《培训记录登记表模板》。

Q265：MiCA是否规定客户资金必须设立“第三方信托账户”？

答：并未强制要求，但强烈建议：

  • 客户资金可设立在持牌银行信托账户，确保资金隔离与偿付优先权；

  • 若未设立信托账户，平台需自行提供《偿付担保》及《内部审计机制》；

  • 对高风险交易（如杠杆、保证金）建议强制实施资金托管机制；

可附《客户资金托管与偿付保障机制说明书》。

Q266：立陶宛BoL是否会进行“实地审查”？如有，频率如何？

答：是，MiCA规定监管机构可进行突击审查或定期检查：

  • 初次牌照发放前，BoL可能进行一次远程或实地尽调；

  • 持牌后，BoL每1–2年将安排审查（含审计文件抽查、系统演示等）；

  • 若发现重大缺失，BoL有权暂停牌照或强制整改；

建议准备《应对监管审查操作手册》+《平台演示标准流程文档》。

Q267：MiCA是否强制设置“虚拟资产交易异常识别系统”？

答：是。MiCA强调交易所应具备：

  • 实时监控客户交易异常行为（如爆量、跳价、羊毛行为）；

  • 自动生成STR（可疑交易报告）预警机制；

  • 连接内控风控模块与人工复核系统；

提供《交易异常检测规则说明》+《STR触发阈值设定文档》。

Q268：是否必须公开平台的大股东及实际控制人（UBO）？

答：是。MiCA联合《UBO透明化指令》要求：

  • 平台需向BoL提交股权穿透图 + 控制人声明；

  • 高于25%的股东必须进行KYC、资金来源证明及无犯罪背景审查；

  • UBO信息亦需向**立陶宛国家企业注册局（RC）**备案并公示；

建议提供《控股结构图》+《UBO尽职调查记录》。

Q269：MiCA是否限制“杠杆交易”或“加密资产衍生品”？

答：MiCA本身不涵盖加密资产衍生品（如：期货、杠杆代币），但若涉及：

  • 应额外申请MiFID II金融服务牌照（或与其合规）；

  • 不得将其归入MiCA申请业务范围；

  • 强烈建议平台与MiFID授权实体合作进行清算或通道服务；

可附《非MiCA适用产品划分说明书》以规避越权行为。

Q270：若客户为机构/法人而非个人，是否可以豁免部分KYC要求？

答：不可以。MiCA+AMLD6统一要求：

  • 法人客户亦需提交注册证明、UBO信息、实际控制人KYC；

  • 对于高风险国家法人客户（如高风险第三国名单），需执行增强尽职调查（EDD）；

  • 可使用《法人KYC标准清单》简化流程；

建议整合《自然人与法人的KYC操作指引》+《EDD启动流程图》。

Q271：MiCA对“空投（Airdrop）”的监管立场是什么？是否需备案？

答：MiCA对空投行为并无明确禁止，但具有如下监管关注点：

  • 若空投代币具金融属性或赋予投资权利，视同“加密资产发行”；

  • 若平台通过空投获取潜在交易用户数据，需申报为客户获取机制；

  • 若空投对象可在平台内直接交易或产生价值，必须备案其分发逻辑和KYC筛选；

实务建议：提交《空投机制合规说明书》，阐明是否为“推介行为”或“初始发行行为”。

Q272：MiCA对交易平台广告宣传有何限制？是否可找网红推广？

答：MiCA联合ESMA发布《加密资产广告指引草案》规定：

  • 所有营销行为需基于真实、准确、不过度承诺的宣传；

  • 若委托“推广者”（如KOL、博主、金融意见领袖），其应承担合规责任连带；

  • 应建立广告合规审查制度，保留每条广告素材存档≥5年；

 建议建立《加密资产广告审查制度》+《推广人员合规承诺书》。

Q273：MiCA对“收益型代币”或“质押回报产品”是否构成监管？

答：是。如平台提供质押返利、锁仓生息、流动性挖矿等业务，可能构成以下情形：

  • 若返利固定，视同证券或债券产品，可能需MiFID牌照；

  • 若返利浮动，亦需在MiCA申请“建议/承销/托管”等服务类别；

  • 所有“收益设计逻辑”需有合法来源支撑并披露完整风险；

实务上，应提供《收益型产品结构说明书》+《风险揭示书》。

Q274：申请MiCA过程中，公司是否可以同时运营旧VASP业务？

答：可以，但前提是：

  • 公司仍持有有效VASP牌照；

  • 应提交“MiCA过渡申请声明”，说明预计MiCA转换时间表；

  • 所有MiCA服务业务必须独立于旧平台模块；

建议提交《MiCA-VASP过渡运营安排说明书》。

Q275：MiCA是否强制平台披露其撮合规则及交易对清单？

答：是。MiCA要求：

  • 所有撮合平台须披露撮合引擎规则、定价模型、撮合优先级机制；

  • 需展示每个交易对的“基础货币与报价货币”、“手续费”、“清算机制”等；

  • 必须允许客户查询历史成交记录与实时深度行情；

可提交《撮合系统规则披露文档》+《交易对信息展示模板》。

Q276：是否可以委托第三方合规顾问或法律顾问作为RO/MLRO？

答：视情况而定：

  • RO（负责人员）须对平台经营负全面责任，不建议外包；

  • MLRO（反洗钱负责人）在符合条件下可由外部合规顾问担任，但需签订职责协议，并保留现场操作权限；

  • 所有RO/MLRO人选必须向BoL备案并接受背景审查；

 建议提供《外包RO/MLRO职责划分协议》+《尽职调查回执》。

Q277：MiCA是否要求平台披露冷钱包的地址或审计信息？

答：是。MiCA透明化原则要求：

  • 若平台持有客户资产（尤其冷钱包资产），应公开披露托管地址；

  • 提交定期审计报告或链上快照证明资金安全；

  • 冷钱包应分设平台资产与客户资产，避免混合使用；

建议平台定期发布《资产托管证明与冷钱包披露报告》。

Q278：MiCA是否禁止或限制平台开设子账户？

答：不禁止，但需合规控制：

  • 每位客户仅可开设唯一主账户，如需子账户，应提交结构说明；

  • 子账户不能用于混淆交易路径、掩盖KYC信息；

  • 若子账户用于不同服务类别，需明示风控与审计权限隔离机制；

可提供《客户账户结构说明书》+《子账户合规操作手册》。

Q279：平台用户来自第三国（如中国大陆、非洲）是否可以受理？

答：可以，但需额外审查：

  • 第三国用户KYC/EDD要求更高；

  • 若所在国属于FATF高风险地区，应采取限制措施或禁止注册；

  • 平台应明确列出可服务国家/地区清单并向BoL备案；

建议建立《国际用户接入政策》并随时更新IP及地址筛查机制。

Q280：MiCA牌照是否可以被转让？如公司股权变动是否需重新申请？

答：MiCA牌照不得转让。如出现以下情形，需提前向BoL报批：

  • 控股股东变更（>25%股份）；

  • 董事会重组或RO/MLRO更换；

  • 公司实际控制人（UBO）变动；

建议提前递交《拟议变更通知函》+《新股东尽职调查文件》。

Q281：MiCA是否要求平台对外披露管理团队和股东信息？

答：是。根据MiCA信息披露义务：

  • 应在平台官网或申请信息中披露董事会成员、RO、MLRO、关键岗位；

  • 股东（尤其是UBO）信息需在申请文件中明确，并接受ESMA、BoL审查；

  • 若平台涉及公众募集，还需附上管理团队资历、利益披露、冲突管理方案。

建议制作《董事及股东信息公开说明书》+《利益冲突管理政策》。

Q282：是否可以通过白标方式在多个国家展开服务？

答：可以，但应注意以下要求：

  • 白标品牌运营方需接受持牌平台的AML/KYC框架；

  • 实际客户关系方为持牌平台，白标方不能私自处理客户资金；

  • 需提交《合作结构协议书》+《职责划分图解》给BoL备案。

需评估白标品牌是否构成“虚拟平台运营”，建议限制其营销权限。

Q283：MiCA是否允许“匿名账户”或“隐私币交易”？

答：不允许。MiCA在对抗洗钱方面强制：

  • 禁止平台支持匿名币种（如Monero、Zcash等）；

  • 所有账户必须完成KYC/EDD流程；

  • 客户交易路径需具备可追溯性（traceability）；

平台应对支持币种设置名单 + 开设《禁止匿名交易币种列表》。

Q284：MiCA是否允许平台同时运营加密货币与NFT市场？

答：视具体情形而定：

  • MiCA不直接监管NFT，但若NFT具备可分割性或金融属性，仍被纳入“加密资产”范畴；

  • 同平台需将NFT板块与传统加密交易结构进行隔离；

  • 若NFT交易具广告、推广功能，仍需满足透明披露与AML/KYC要求。

建议建立《NFT运营与MiCA结构边界说明书》。

Q285：是否可以通过外部审计替代内部合规部门？

答：不可替代。MiCA要求平台建立自有合规责任体系：

  • 内部必须设立MLRO、合规官，履行日常监控与合规报告职责；

  • 外部审计师可提供辅助审查，但不替代日常职能；

  • 可外包部分合规工作，但必须保留内部控制权。

建议明确《外包合规服务协议书》+《合规权责清单》。

Q286：是否必须在申请前就搭建IT系统？是否可以后补？

答：建议在申请前基本完成系统蓝图及关键模块：

  • MiCA要求申请人提交系统描述文档、权限图、冷钱包结构图等；

  • 若系统尚未完全上线，可提交《系统开发计划表》+《测试环境截图》；

  • BoL更倾向于审批“系统已搭建完成或可运行版本”的项目。

建议提供PoC（Proof of Concept）版本或可操作的系统演示文档。

Q287：是否允许平台提供杠杆、合约、期权等衍生品交易？

答：
MiCA本身不涵盖加密资产衍生品，但欧盟MiFID II对其适用如下：

  • 若加密资产本身为证券/金融工具，平台即受MiFID II监管；

  • 提供杠杆、合约、期货等产品的，应持有MiFID相关授权；

  • 若以游戏化、奖励为名进行变相杠杆，构成重大合规风险。

建议撰写《金融衍生产品风险排除声明》并进行结构隔离。

Q288：是否可以使用开源钱包（如MetaMask）对接平台？

答：
技术层面可以，但应满足以下监管条件：

  • 开源钱包需集成平台KYC模块；

  • 所有链上交易路径必须可审计；

  • 平台不能放弃对客户私钥或授权行为的合规控制；

建议以“托管连接钱包模式”为主，避免裸钱包接入。

Q289：平台是否可以运营代币发行（如Launchpad）？

答：可以，但需要申请“承销”类CASP服务许可：

  • 所有发币项目需进行合规披露、KYC审查、项目审查；

  • 平台对客户资金募集行为负有责任；

  • 必须发布《代币发行白皮书》+《投资风险揭示书》。

建议撰写《Launchpad发行平台说明书》并提交至BoL审阅。

Q290：MiCA是否允许客户通过银行卡充值？是否需对接支付牌照？

答：允许。但应明确：

  • 若平台直接接受银行转账/信用卡充值，应接入持牌支付机构；

  • 平台本身不具支付结算功能，除非额外申请EMI/PI牌照；

  • 所有充值行为应记录交易路径、充值人身份，并进行风控评分；

建议平台建立《充值通道合规说明书》并对每个支付对接方进行尽调。

Q291：是否可以使用第三方KYC服务提供商？

答：可以，但需满足以下条件：

  • 第三方KYC提供商必须受欧盟《反洗钱指令》（AMLD）监管；

  • 平台应对其KYC流程进行尽职调查并留存报告；

  • 须签署数据保护与责任划分协议，并定期评估其表现；

建议附加《第三方KYC服务审查清单》和《合作协议样本》。

Q292：MiCA是否要求数据本地化？是否可将服务器设于境外？

答：不强制要求数据本地化，但必须确保：

  • 数据存储和处理符合法规（GDPR、MiCA、BoL监管要求）；

  • 可随时响应BoL及ESMA的数据调阅、审计；

  • 冷钱包数据、日志及审计记录应至少一份存于欧盟境内；

建议设立镜像服务器于立陶宛/EU本地，并撰写《数据处理声明》。

Q293：平台是否必须提供客户适当性评估机制？

答：是。MiCA要求服务提供者对客户进行“适当性评估”（Suitability Assessment）：

  • 判断客户是否具备理解加密产品风险的能力；

  • 对高风险产品（衍生品、杠杆类）应有附加警示；

  • 须保留客户评估记录 ≥5年备查；

建议建立《客户适当性评估问卷》+ 自动风控标签系统。

Q294：MiCA是否允许自动交易机器人（Trading Bot）接入平台？

答：可以，但必须：

  • 客户主动授权其接入交易指令；

  • 平台需对API接入进行权限限制与日志记录；

  • 明确风险由客户承担，平台不提供策略建议；

可创建《API接入说明书》与《Bot交易免责声明》。

Q295：平台是否可以发行平台币？MiCA对此有何监管？

答：可以，但须根据平台币性质区分：

  • 若平台币具备资产锚定功能 → 可能构成ART（需额外牌照）；

  • 若为一般效用型Token，用于平台抵扣/投票等功能 → 可由CASP发行；

  • 必须发布白皮书，并接受MiCA中披露义务监管；

建议撰写《平台币发行说明书》与《经济模型披露文档》。

Q296：MiCA对高频交易或做市行为有何特别要求？

答：目前MiCA未单独设专章约束HFT或做市行为，但要求：

  • 明确标识是否存在平台自营交易行为；

  • 做市策略须公开披露，不得误导客户价格；

  • 若涉及系统化撮合，应考虑MiFID II监管触发情形；

可制定《做市策略披露说明》及《撮合逻辑白皮书》。

Q297：是否可同时申请MiCA CASP与EMI支付机构牌照？

答：可以。MiCA与PSD2（EMI/PI）制度不冲突，实操建议：

  • 分设两个法人实体（或隔离牌照业务板块）；

  • 每类业务单独设置账户、团队、KYC体系；

  • 确保客户资金流转路径透明、防止功能混用；

可整合为“VASP+EMI双牌照合规架构图”。

Q298：平台是否必须对代币项目方开展尽职调查？

答：必须，尤其在提供代币发行、承销、交易上架等服务时：

  • 应评估项目方背景、Token功能、资金用途；

  • 查验是否涉及证券属性或欺诈风险；

  • 留存调查报告、合同与披露材料；

建议采用《Token项目合规尽调模板》并设审议机制。

Q299：MiCA是否允许跨境客户服务（如亚洲、拉美客户）？

答：允许，但平台应注意：

  • 面向第三国客户提供服务不得违反当地法规；

  • 不得主动营销至禁止加密服务的国家（如中国）；

  • 须做好KYC+Sanctions名单筛查，避免触发国际制裁条例；

可建立《非欧盟客户接入政策》与《国家禁区清单》。

Q300：客户是否可以使用第三方钱包地址提币？平台是否负责任？

答：允许客户提币至第三方地址，但平台责任如下：

  • 须完成地址白名单绑定流程；

  • 若为“非托管钱包”，平台应警示风险；

  • 若为“第三方平台地址”，建议进行Wallet Ownership声明收集；

应设计《提币申请流程图》与《地址绑定确认机制》。

Q301：MiCA是否强制平台建立“交易对手识别系统”？

答：在涉及撮合服务时，平台必须能够识别交易对手的身份，防范洗钱与市场操纵行为：

  • 系统应记录撮合各方的钱包地址与身份；

  • 若平台撮合为匿名对手方，需通过内部账户标识系统实现“可追溯性”；

  • 交易日志需保留 ≥5年，支持STR分析；

建议纳入《交易对手识别记录机制》模块，并生成对账报告。

Q302：MiCA是否允许“代币化债券”、“STO”在交易平台上线？

答：MiCA本身不涵盖证券类加密资产（即“security tokens”）：

  • 若代币化产品构成金融工具，适用MiFID II监管，由NCA监管；

  • 若不构成证券，但具ART属性 → 需额外申请ART发行牌照；

  • 一般平台应区分VA与ST产品线，防止越界；

如拟上线STO产品，应与立陶宛FMI平台或德国BaFin协作。

Q303：客户资产损失是否须承担补偿责任？MiCA对此如何界定？

答：MiCA要求平台履行“客户资产保护义务”，若因：

  • 平台系统故障、私钥泄漏、权限滥用导致客户资产损失；

  • 未经授权转账、黑客攻击平台资产损毁；

则平台须依据责任程度承担相应赔偿责任。

应提供《客户资产托管协议》并配置保险方案或补偿基金。

Q304：是否可以在获得MiCA牌照前就开展客户招募？

答：禁止在无牌情况下进行公开营销或提供服务。但可开展以下活动：

  • 内部测试平台、技术部署；

  • 对机构客户进行“一对一介绍”；

  • 预热宣传须注明“尚未获得MiCA牌照，不构成招揽”；

建议制定《Pre-License市场推广合规指引》。

Q305：平台如何设置“利益冲突管理机制”？

答：MiCA要求平台具备防范利益冲突的机制，适用于：

  • 自营交易 vs 客户交易；

  • 多角色操作（如托管人+发行顾问）；

  • 关联公司间转账或交易撮合等；

建议撰写《利益冲突识别与披露政策》及员工申报制度。

Q306：是否需将客户资产隔离存储？可合并进平台账户吗？

答：强制要求客户资产与平台自有资产分离存储：

  • 加密资产需隔离托管于客户地址；

  • 法币存款（如USDT赎回款）需设立客户专户；

  • 不可将客户资产用于平台运营或抵押用途；

建议设置“客户资产子钱包结构图”，同时审计确认路径。

Q307：若平台对接多个区块链网络，是否需单独申报？

答：不必单独申报，但需在以下方面符合要求：

  • 每个网络的权限管理、日志系统需符合监管审计要求；

  • 区块链接入应具备稳定性、不能随意切换或混用地址；

  • 不同链上的资产应单独计量、清晰核算；

可附《多链接入架构说明书》。

Q308：MiCA是否允许去中心化钱包或非托管钱包服务？

答：MiCA并不禁止“非托管服务”，但若涉及以下行为仍视为CASP：

  • 提供中介功能（如撮合、费率设置、界面）；

  • 设有KYC通道或接口管理权限；

  • 客户资产路径无法做到完全自托管；

非托管类平台仍可能受MiCA影响，需个案判断，建议律师出具判定意见。

Q309：MiCA实施后，立陶宛原有VASP是否自动转为CASP？

答：不会自动转换。原VASP企业需在过渡期内（预计为18个月）完成以下步骤：

  1. 向BoL提交MiCA牌照转换申请；

  2. 提交新增材料（如资本金、系统说明）；

  3. 接受重新审查与牌照重发；

BoL将设置“简化路径”，但仍需实质审查，建议提前准备。

Q310：客户如果发生纠纷，MiCA是否规定仲裁或投诉机制？

答：是。MiCA要求平台提供内部投诉机制，且：

  • 客户投诉应在15天内回复；

  • 须保留投诉处理记录；

  • 平台应设立独立投诉联系人或小组；

  • 重大争议可提交BoL/ESMA处理；

建议设立《客户投诉流程图》和《争议处理制度》。

Q311：平台是否可以接受“匿名客户”或只收加密资产？

答：不可以。MiCA强制所有CASP平台履行客户识别（KYC）及AML义务，要求：

  • 客户身份须经验证，支持实名；

  • 不得完全接受无来源法币或匿名钱包充值；

  • 若仅收加密资产，仍需识别其来源及真实身份（如链上分析、KYT工具）；

可集成Chainalysis、Elliptic等工具辅助链上身份识别。

Q312：平台负责人是否可由第三方外包公司承担？

答：不建议。MiCA明确规定平台须有“核心管理层”，包括：

  • 至少两名具备实际运营权限的董事或管理人员；

  • 不得将核心管理职责完全外包（如RO/MLRO）；

  • 可使用外包辅助服务（如审计、技术、安全），但“管理责任不得外包”；

建议指定独立董事+MLRO合规官由公司直接任命并签订合规承诺。

Q313：MiCA是否对外包IT服务有明确规定？

答：有。MiCA要求：

  • 外包IT服务提供商不得对系统操作拥有全部控制权限；

  • 应保留系统可审计日志；

  • 与外包方签订《服务级别协议（SLA）》与《数据保密协议》；

  • 核心权限如交易撮合、KYC结果审核等应由平台内部控制；

BoL审核时将检查系统权限结构图与合同样本。

Q314：是否可以只申请单一服务类别（例如仅做法币兑换）？

答：可以。MiCA允许CASP根据自身业务实际，仅申请一项或多项服务类型，但：

  • 不同服务类型需对应不同合规要求、资本金；

  • 如后续增加服务类别，需向BoL补充申请并获批准；

建议在商业计划书中明示初期与未来预期业务范围。

Q315：是否可以境外拥有客户支持中心？

答：可以，但需满足：

  • 客户服务流程应记录并可追溯；

  • 投诉接收机制需与立陶宛BoL备案；

  • 重要决策（如资产冻结、交易暂停）应由立陶宛公司本地决定；

建议将外设客户支持中心视为“辅助运营”，并附详细说明信。

Q316：平台上线前是否需通过技术审查或验收？

答：BoL及ESMA暂无统一测试机制，但：

  • 可要求平台提交系统测试报告；

  • 对冷钱包管理、权限架构、应急演练等关键模块进行验证；

  • 建议进行第三方技术审计或SOC2报告；

可使用《系统上线前测试报告》模板进行预备案。

Q317：是否必须提供加密资产白皮书？

答：如平台提供资产发行、承销或上线服务，则MiCA要求：

  • 对每个资产提供《Crypto-Asset Whitepaper》，内容包含资产功能、用途、风险；

  • 白皮书应由CASP签字背书，并向监管机构备案；

  • 不得对投资回报作误导性陈述；

建议提供双语白皮书模板并由律师审阅。

Q318：监管机构会现场检查平台办公场所吗？

答：有可能。BoL可在申请或年审阶段进行以下形式实地核查：

  • 确认实体办公场所是否存在；

  • 验证系统存储与操作是否符合权限控制说明；

  • 会见核心管理层及MLRO进行问询；

建议确保场所具备基本设施与可核实证明，如租赁协议、电信账单等。

Q319：MiCA要求的“内部审计”是否必须为独立部门？

答：不强制要求独立部门，但需满足：

  • 内部审计人员应具有客观性（不可兼任业务管理）；

  • 审计频率建议半年或每季度；

  • 报告内容应涵盖AML、权限控制、客户资产风险等关键点；

中小平台可由非管理层合规官临时担任，附《内部审计报告模板》。

Q320：是否可以作为海外集团的子公司申请MiCA牌照？

答：可以，但需符合以下条件：

  • 本地UAB公司须具备实质性运营（实地场所、本地管理）；

  • 集团控股结构需透明，UBO不得隐匿；

  • 所有控制权与资产管理系统必须归属立陶宛公司可控；

建议提供《集团结构图》与《职权分配说明信》。

Q321：MiCA是否强制平台设立“客户资金独立账户”？可使用混合账户吗？

答：是的，MiCA要求平台客户资产必须与公司自有资产完全隔离，并使用独立托管账户。混合账户将被视为严重违规。

实操提示：

  • 平台需提交银行/托管机构开设的“独立客户资金账户证明”；

  • 若采用冷钱包托管，需提供独立资产标签机制；

  • 监管期望可清晰追溯客户资产来源、归属与变动记录。

Q322：立陶宛MiCA是否支持“结构化代币”（如以基金、资产包支持的Token）？

答：支持，但需根据代币底层资产类型判断：

  • 若为证券性质资产 → 应另行取得Prospectus或MiFID适用牌照；

  • 若为非证券结构化资产（如黄金支持、房地产代币化） → 可在MiCA框架下处理，但需额外披露；

  • 平台须提交《资产支持机制说明》与《估值机制》。

建议提前准备《代币经济模型披露书》以供监管审查。

Q323：MiCA对营销活动是否有限制？可以进行空投或奖励机制吗？

答：MiCA对营销行为有以下要求：

  • 所有营销内容（含空投宣传、平台邀请奖励）必须真实、透明、可核实；

  • 不得引导性误导或宣称“保本”“高回报”；

  • 若涉及特定国家，还需遵守当地广告法（如德国BaFin广告合规）；

  • 建议预留所有市场活动记录，必要时可供稽核。

Q324：MiCA平台是否可以设立“稳定币兑换池”进行跨币兑换？

答：可以，但必须符合以下要求：

  • 需获得兑换服务许可（CASP第3或第4项）；

  • 若平台自行发行稳定币（ART/EMT），须满足额外披露与资本要求；

  • 所有兑换价格机制应向用户披露，避免“隐性滑点”；

  • 系统需记录每笔兑换订单路径、价格与用户确认过程。

Q325：MiCA是否接受境外公司股东（如开曼、BVI、香港等）？

答：接受，但须满足以下条件：

  • 提供UBO穿透结构图；

  • 所有股东必须提供KYC、无犯罪记录与资金来源说明；

  • 若为高风险地区（FATF灰名单/黑名单国家），BoL可能要求额外审查；

  • 强烈建议使用已合规备案的控股平台结构（如香港/新加坡法人控股更佳）。

Q326：MiCA对平台“撮合方式”有技术要求吗？是否必须中心化撮合？

答：MiCA接受中心化与去中心化撮合，但若涉及去中心化元素（DeFi混合型平台）：

  • 平台需保证其有控制“订单处理”或“成交确认”的能力；

  • 不允许平台将撮合完全交由智能合约而无法监管；

  • 所有撮合机制需可解释、可记录、可追踪。

平台需提交《撮合机制技术白皮书》作为IT系统说明附件。

Q327：平台是否可开放API接口给第三方做撮合/挂单服务？

答：可以，但需满足：

  • 第三方API接入者须签订合规合作协议；

  • 平台需保留对其操作范围与权限的控制；

  • 必须在系统中标明“此订单为外部接入”；

  • 不得授权API账户进行自营撮合（避免形成操控市场嫌疑）。

Q328：MiCA牌照是否可用于Token质押/收益农场服务？

答：视具体形式而定：

  • 若平台本身提供质押产品（Staking-as-a-Service） → 属于提供投资建议/管理服务，须明确申请服务项；

  • 若仅提供基础技术平台供用户自主操作（无平台托管资金） → 可作为“基础设施服务”登记；

  • 必须披露风险、年化收益、退出机制，并避免误导宣传。

建议准备《质押服务风险揭示声明》与《收益模拟说明书》。

Q329：MiCA是否要求平台披露“流动性池”管理策略？

答：是的，若平台提供AMM或聚合流动性服务：

  • 须明确流动性来源（用户/自营/做市商）；

  • 披露管理机制、交易对滑点容忍范围；

  • 应具备自动/半自动风控策略及触发条件。

Q330：MiCA牌照平台是否可以开展“Token化债券”、“数字证券”发行业务？

答：MiCA原则上不涵盖“金融工具类Token”（即Security Token），若涉证券性质的代币：

  • 须另行取得MiFID II或Prospectus Directive项下的监管资质；

  • 若结合MiCA平台作为托管、钱包或市场接入提供者，可构建“MiCA+MiFID”双重合规结构。

如涉及，请递交《证券型代币法律意见函》并说明平台角色边界。

Q331：MiCA对平台上线虚拟资产是否需预审批？

答：MiCA对“平台上线资产”（Token Listing）有合规披露要求，但不设审批机制。具体要求如下：

  • 若平台为集中式交易所，需建立资产甄选机制；

  • 所有上线资产须附带风险披露与功能说明；

  • 对“资产参考型代币（ART）”与“电子货币代币（EMT）”，可能适用更高披露标准；

  • 不得上线“未能明确归类、具高波动、或黑名单风险”的资产。

建议建立《Token Listing评估机制》，附合规审查流程、拒绝标准、审查委员会责任等内容。

Q332：MiCA平台能否允许使用DEX或DeFi系统？

答：MiCA目前不监管“完全去中心化”的协议系统（如Uniswap），但：

  • 一旦平台提供**“客户资产托管、撮合、执行或建议”**等服务，即视为“中心化服务商”；

  • 不可规避监管义务以“技术”外包之名义运行DeFi系统；

  • 若嵌套DeFi协议，也须符合MiCA中的“透明性、风险控制、审查机制”要求。

实务建议：合规框架下可嵌入受控DeFi组件，但需说明权限与用户保护措施。

Q333：是否可仅提供移动App界面服务？是否必须设网页端？

答：MiCA并不强制平台必须提供网页端或移动端。但要求：

  • 客户界面需支持完整身份识别、合规风险提示；

  • 若仅提供移动App，需说明KYC流程、订单执行机制是否完整、无障碍访问；

  • 应建立应急机制，避免系统故障导致客户资产被冻结；

提交《用户界面说明书》时，附App截图、功能清单、KYC流程动图等资料。

Q334：是否允许单一管理人员兼任RO、MLRO等多个角色？

答：MiCA允许初创企业在规模尚小时合并岗位，条件包括：

  • 须提交角色兼任的“风险说明”；

  • 该人员应拥有相关资历、经验并接受持续培训；

  • 不建议由股东兼任MLRO，以保证客观性；

最佳实务结构建议为：RO（负责合规治理） + MLRO（专责AML控制）分开设立。

Q335：平台可否使用子公司名义申请MiCA，而实际由母公司运营？

答：不可。MiCA要求牌照运营主体必须为申请实体本身，包括：

  • 客户资产托管权、IT系统控制权、KYC执行责任等；

  • 不得“壳公司”申请，而由其他实体远程操作；

  • 如涉及IT/合规支持服务外包，需提供合同与风险责任界定书；

所有MiCA牌照申请必须“责任与运营一致”。

Q336：客户资产是否可与公司营运资金混合存放？

答：严格禁止。MiCA规定：

  • 客户资产必须“独立托管、分类记录、清晰标识”；

  • 若为法币，应在“客户专属账户”内开设托管账户；

  • 加密资产应由系统打标签标注归属，具备可追溯性与恢复机制；

BoL要求在系统架构图中清晰展示客户资金池与公司资金池的隔离逻辑。

Q337：MiCA对多币种钱包是否有特别要求？

答：允许多币种支持，但要求：

  • 每个币种的交易日志、审计路径、权限结构须清晰；

  • 热/冷钱包之间的交互规则需完整备案；

  • 非主流币种或匿名币（如Monero、Zcash）使用需解释其合法合规依据；

建议平台内置“资产归类标签系统”，供AML分析使用。

Q338：公司是否必须投保责任保险？

答：不是强制规定，但监管建议：

  • 若涉及客户资产托管、执行或承销服务，建议投保职业责任险（PI）或营运中断险（BI）；

  • 可提高BoL对平台运营稳定性的认同度；

  • 投保金额应与平台规模与交易量相匹配；

可附上《保险保障说明信》作为申请支持材料之一。

Q339：是否必须在BoL备案所有服务使用的第三方API或外部接口？

答：建议备案，特别是涉及以下类型：

  • KYC服务商（如SumSub、Trulioo）；

  • 交易执行/路由系统（如API to CEX/DEX）；

  • 钱包服务或托管接口（如Fireblocks、BitGo）；

提交《外部服务API清单》，并附《第三方责任划分说明》。

Q340：若公司未来IPO或被收购，是否需重新报批？

答：MiCA要求公司发生以下情况时必须提前报备BoL：

  • 控股股东变更；

  • 上市、融资、转让控制权；

  • 管理层重大变动；

若BoL认定对合规控制有实质影响，可能重新审核其适当性并要求补充材料。

建议保留所有公司变更说明信、董事会会议记录及UBO穿透图。

Q341：MiCA对加密资产“白名单”或“黑名单”有明确标准吗？

答：MiCA本身并不设立统一的“白名单”或“黑名单”，但要求平台：

  • 对上线的每种加密资产进行充分披露与风险评估；

  • 若资产具高度波动性、匿名属性或无合理商业模型，应谨慎处理；

  • 平台须具备“资产审查程序”并保留审查记录；

  • 上线ART或EMT需额外说明其参考资产机制、稳定性管理策略等。

实务建议：参考欧盟ESMA或国家监管机构的监管警示清单，建立内部“资产清单管理政策”。

Q342：MiCA是否强制设立MLRO（反洗钱负责人）？

答：是的。根据MiCA与AMLD6联动：

  • 所有CASP必须设立MLRO；

  • MLRO需具备反洗钱背景与合规经验；

  • 不得由无经验人员或“挂名人士”担任；

  • MLRO可非立陶宛本地人士，但需明确工作机制与监管联络路径。

实务建议：提供《MLRO职责说明书》及其个人履历、AML培训记录等作为附件。

Q343：申请MiCA是否可通过现有的VASP过渡？

答：可以。立陶宛银行允许在MiCA正式全面实施前：

  • 以现有VASP身份提交MiCA申请；

  • 在MiCA过渡期内获得“临时豁免”以继续运营；

  • 但申请资料仍需补齐所有MiCA标准（如资本金、系统说明等）。

建议采取“双轨推进”策略：先持有VASP运营 → 同步申请MiCA升级。

Q344：MiCA对“加密托管”的定义包含哪些服务？

答：MiCA对“托管”服务界定如下：

  • 任何代表客户保管私钥、钱包访问权限的服务；

  • 不论是否收费；

  • 包含冷热钱包管理、权限控制、访问授权等。

若平台可“替客户重置密码、重发私钥或直接管理资产”，即构成“托管”，须受MiCA约束。

Q345：MiCA是否允许“自营交易”？会否受限制？

答：允许，但须申报。MiCA将“自营交易”（Proprietary Trading）列为第8类服务：

  • 须申报其服务类型；

  • 须建立“客户交易与自营交易隔离制度”；

  • 禁止使用客户资产或订单做为对手方；

  • 须设立“利益冲突处理政策”。

建议同时提交《自营交易政策说明书》与系统风控边界图。

Q346：MiCA对平台执行KYC程序有何具体要求？

答：KYC要求主要按AMLD6与BoL指引，需：

  • 初始识别：客户基本信息、身份证明、住址验证；

  • 风险评估：根据客户国籍、资产来源、交易规模分级；

  • 持续监控：定期更新客户信息；

  • 可疑报告：STR制度触发机制完整。

KYC流程应内嵌于系统中，附流程图+风险分级规则+供应商接口说明。

Q347：加密资产若作为支付手段是否需要申请EMI牌照？

答：视情况而定：

  • 若仅作为“价值载体”转账（如BTC支付服务），MiCA牌照即可；

  • 若发行自身的电子货币型代币（EMT）并用于结算功能，须申请EMI（电子货币机构）牌照；

  • 若同时提供法币存取、跨境结算，应评估是否构成支付机构业务。

建议提交《产品结构说明信》至BoL进行“前置合规意见函”。

Q348：MiCA是否适用于NFT与GameFi项目？

答：视NFT属性而定：

  • 若NFT具“唯一性、非可互换性”，不构成加密资产；

  • 若NFT具备分拆、标准化、流通性（如Fractional NFT），可能被视为效用型代币；

  • GameFi项目发行Token若具经济回报预期或可自由交易，可能构成MiCA监管资产。

建议提供NFT或Token的“功能与经济模型说明书”以供合规判断。

Q349：MiCA对平台系统日志与记录保存有何规定？

答：所有CASP平台必须：

  • 保存交易记录 ≥ 5年；

  • 保存KYC及客户通讯记录 ≥ 5年；

  • 系统日志需支持审计、导出、追踪；

  • 系统出具的报告（STR、内部审计等）须定期归档。

BoL审核系统时，重点查看是否具备日志备份、时间戳、防篡改机制。

Q350：MiCA是否接受远程办公？公司是否必须在立陶宛设立实体？

答：需设立本地运营实体（UAB公司），并：

  • 提供立陶宛地址（非虚拟地址）；

  • 指定常驻联络人；

  • 可部分岗位（如IT、后台）远程设置，但RO与MLRO需可随时响应BoL联络；

  • 不接受“空壳公司”、“伪设立公司”或仅租箱地址的方式。

建议在初期准备期间同步安排本地办公室与基础运营支持。

Q351：MiCA是否适用于NFT平台？如OpenSea类平台是否需申请？

答：NFT平台是否纳入MiCA，取决于NFT的**“可替代性与金融功能”**：

  • 若NFT本身具有金融属性、可用于交易所挂单、分割或集合投资（如NFT基金、可分割NFT） →将被视为加密资产，MiCA适用；

  • 若NFT仅为唯一数字作品（如艺术品、收藏品），非金融工具 → 可豁免；

  • 平台若同时提供其他类型加密资产交易或保管服务，仍需申请CASP牌照。

实操建议：准备一份《NFT非金融属性说明函》以配合合规审核。

Q352：MiCA牌照是否支持DeFi平台？是否必须中心化？

答：MiCA原则上监管**“可识别运营方”**的加密资产服务：

  • 如果DeFi平台有集中UI门户、开发团队、治理投票核心成员，则监管认为其有“可监管实体”；

  • 真正的纯DeFi（完全智能合约驱动、无中心化入口）目前仍未覆盖；

  • 建议有意申请的DeFi平台建立可识别实体（如DAO Foundation + UAB法人）组合。

可提交《合规运营桥梁结构说明书》，详述链上结构与线下法人责任划分。

Q353：MiCA对代币发行是否要求白皮书备案？内容要求有哪些？

答：是的，MiCA对代币发行人（尤其是ART/EMT或首次公开发行加密资产者）规定需提交**《Crypto-Asset Whitepaper》**，包括：

  • 代币性质、技术模型、发行机制

  • 投资者权利/义务、风险提示

  • 使用场景、治理结构、冷/热钱包说明

  • 披露责任人、发行人背景、财务预测

⚠️ 白皮书不需事前批准，但需在平台上线前通知监管机关备案。

Q354：MiCA是否要求所有客户KYC？是否支持匿名钱包或限额钱包？

答：MiCA配合《AMLD6》全面要求：

  • 所有客户（自然人/法人）必须KYC；

  • 不得允许匿名钱包地址与账户进行交易/存储；

  • 可设立低额钱包（如交易额 < €150 / 年）有豁免KYC权限，但仍需留存IP、设备信息。

实操建议：集成自动化KYC/AML模块，保留记录 ≥5年。

Q355：MiCA是否要求平台承担交易报税与报告责任？

答：平台须支持：

  • 生成用户年度交易报告（用于客户纳税）；

  • 向监管机关提交可疑交易报告（STR）；

  • 若有本地税务驻留义务，还需配合DAC8/EU跨境加密资产信息交换制度。

⚠️ 建议在注册初期规划交易记录结构，支持CSV/API导出。

Q356：MiCA是否允许平台提供杠杆交易或保证金服务？

答：MiCA不直接禁止杠杆服务，但：

  • 若涉及借贷、杠杆、衍生品交易，将被视为提供MiFID金融工具服务，必须申请MiFID II投资牌照；

  • CASP本身只能提供“现货+托管+撮合+建议”类服务。

可结合立陶宛证券商牌照或通过第三方结构对接。

Q357：平台是否可以将冷钱包托管外包？如使用Fireblocks或Copper？

答：允许，但需符合以下条件：

  • 外包服务方须具备监管或行业认证资质；

  • 平台仍需保有最终权限控制权与应急手段；

  • 冷钱包私钥权限与签名机制必须提交结构图说明；

推荐提交《冷钱包权限控制流程图 + 第三方托管合规声明》。

Q358：MiCA是否适用于加密支付网关服务商？如支持商户收币再兑欧元？

答：适用。属于以下两种CASP服务之一：

  • 加密资产兑法币服务（第3类服务）；

  • 加密资产传送服务（第5类服务）；

⚠️ 若平台提供商户对账、结算周期或锁汇机制，还可能被视为“加密资产钱包管理服务”。

推荐准备《商户加密支付流程图》与《加密兑汇风险说明》。

Q359：MiCA是否要求董事、RO或MLRO必须在立陶宛本地居住？

答：至少需满足：

  • 有一名核心管理人员居于立陶宛或能提供在立活动证明；

  • 远程配置MLRO可行，但需有合理解释及远程合规机制；

  • 董事会定期会议建议设置于立陶宛，保留会议纪要档案；

推荐：设立本地办公室，登记注册地址与合规值班电话。

Q360：MiCA平台是否需要购买商业保险或客户资产保障计划？

答：不是强制，但鼓励设立以下机制：

  • 网络攻击/冷钱包损失险（Cybercrime Insurance）；

  • 合规责任险（D&O Insurance）；

  • 客户资产保障机制（如：公司垫付机制）；

建议撰写《客户资产保障制度说明书》，并视交易量动态调整保险额度。

Q361：平台是否可预留“匿名浏览”入口，客户可先查看行情再开户？

答：可以。MiCA并不限制客户在注册前“浏览公开行情数据”或“产品说明内容”。

但注意：

  • **任何涉及下单、资金操作、模拟交易、用户习惯追踪分析（如用户钱包地址行为预测）**等行为，不得在未KYC前开放；

  • 不得设置类似“隐私浏览”但实际抓取KYC信息的暗箱机制。

建议在系统中明确划分匿名区（market view）与实名区（wallet, trading, deposit），并设置访问分层逻辑。

Q362：MiCA申请过程是否可使用代理签署？如公司高管不在欧洲？

答：可部分使用授权委托，但有关键限制：

  • 公司董事可授权签署部分申请材料（如提交说明函、附件声明）；

  • 但涉及最终负责人声明、受益人披露、RO/MLRO履职确认等文件，必须本人亲签或通过经公证的PoA（Power of Attorney）方式提交；

  • 建议使用立陶宛或欧盟本地公证机构，或通过Apostille认证。

实操建议：提前准备【签字授权模板包】，并准备“签字人样本留档”。

Q363：MiCA平台是否需披露算法或撮合机制细节？

答：是，MiCA要求平台披露与以下相关的系统说明：

  • 撮合逻辑：订单优先级、撮合时间点、是否允许提前挂单；

  • 手续费机制：滑点处理、挂单与市价费率差异；

  • 客户影响机制：如限价、止损执行方式；

推荐提供一份【撮合算法摘要说明书】与【系统流程图】，用于向BoL或客户公开披露。

Q364：MiCA牌照是否适用于智能合约市场（如Dex Aggregator）？

答：MiCA适用于有平台控制权的聚合器：

  • 若Aggregator由平台设定UI、参数预设、使用平台签名操作，则属于CASP服务；

  • 若Aggregator仅为开源、去中心化合约，平台仅为信息展示或跳转，则不构成MiCA监管对象；

  • 一旦涉及客户资产传输/兑换，则构成受规服务。

提交《DEX中介结构图》及“非控制声明”可减少监管疑虑。

Q365：MiCA平台可否向“基金”或“结构化产品”投资者提供建议服务？

答：提供“投资建议”是MiCA许可的第10类CASP服务。

但若建议行为涉及：

  • 构建组合（如加密资产ETF、Baskets）；

  • 提供固定收益、复利锁仓产品；

  • 包含资产再分配逻辑（如AI量化策略）；

则需同时符合MiFID II 投资建议服务牌照要求。

可考虑设立独立法律主体，分别申请MiCA（CASP）与MiFID II（资产顾问）牌照。

Q366：是否必须披露UBO结构到自然人终端？如控股路径很复杂？

答：是。MiCA及BoL要求穿透披露至自然人终极受益人（>25%）。

  • 不允许停留在公司、信托、SPV、基金上；

  • 如系家族办公室、信托基金结构，必须附说明信、证明文件及文件链条；

  • 所有UBO需完成KYC、无犯罪声明及签署责任函。

使用《控股结构图 + 穿透说明书》模板，配合申报。

Q367：MiCA牌照是否支持“客户多币种分账户”设置？是否可混合储存？

答：支持多币种账户（如BTC/ETH/USDT分别建立客户资产分账），但必须：

  • 使用客户分账户制度（Client Segregated Accounts）；

  • 系统应具备客户余额、币种、持仓快照、历史记录功能；

  • 禁止平台将客户多币种资产混合为平台自用流动池（除非客户明示授权）。

建议同时建立客户《授权使用说明机制》，增强透明度与合规记录。

Q368：平台能否设置“流动性提供者计划”？是否构成MiFID义务？

答：MiCA下平台可设置LP机制，但需谨慎：

  • 若LP为平台自身：视为“自营交易”服务；

  • 若LP为第三方机构：视为“机构交易账户”，其行为将受到BoL额外关注；

  • 若平台向LP提供手续费回扣、优先撮合权、免审核资格，可能构成非公平交易机制，需说明机制合法性。

可提交《LP接入机制说明书》及《公平交易保障制度》。

Q369：平台是否可提供多语言界面？MiCA是否强制设为立陶宛语？

答：界面语言无强制要求，可使用多语言（如英文+立陶宛语+中文）。

但以下材料必须以英文/立陶宛语版本为主提交BoL：

  • 申请表格、业务说明、KYC政策；

  • 冷钱包控制机制、内部报告制度；

  • UBO文件、合规制度手册。

推荐官方文件使用英文正式版，客户前台支持多语切换，增强国际兼容性。

Q370：MiCA平台是否可设置二级市场币种审核委员会？是否需监管批准？

答：可设立内部代币上线审查机制（Token Listing Committee），但需满足：

  • 制定代币上线标准、黑名单机制、流动性审查程序；

  • 所有审核须留档、每季度向BoL汇报上线/下架代币清单；

  • 若币种具争议性（如混币代币、匿名币、杠杆币种），需提前提交风险说明书。

可提交《代币上线机制内部规则》与《合规审查评分表》。

Q371：MiCA平台的收入是否需向立陶宛申报公司税？可否在其他国家报税？

答：如平台注册在立陶宛（UAB公司），即使实际营收来自其他国家，原则上仍须在立陶宛申报：

  • 立陶宛企业所得税为15%（如为微型公司≤€300,000收入可申请5%优惠税率）；

  • 若平台设有欧盟其他国家的“固定场所”（如办事处、托管服务器），可能触发双边税务协定；

  • 建议使用【国际税务规划结构图】配合“集团间关联交易转移定价报告”方式进行规划。

推荐设置“服务合同 + 费用转移机制”以合规控制税务支出。

Q372：平台是否必须建立客户投诉机制？具体流程如何？

答：MiCA强制要求平台建立客户投诉处理政策，包括：

  • 客户投诉邮箱、处理时间表（不得超过15个工作日）；

  • 内部记录系统，需留档 ≥5 年；

  • 指定负责人（可由MLRO或客户合规主管担任）；

  • 所有投诉须设“接收-处理-反馈-归档”闭环机制。

可提交《客户申诉处理制度模板》与《季度投诉统计报表》。

Q373：MiCA是否适用于NFT平台？是否构成CASP服务？

答：是否纳入MiCA监管取决于NFT的“可分割性与流通属性”：

  • 若NFT仅为独一无二的非金融类收藏品（如艺术、音乐），不属于MiCA加密资产；

  • 若NFT具备金融属性（如收益分红、转售市场、批量发行），则可被MiCA视为“可替代性资产”，需申请CASP牌照；

  • 若提供NFT交易平台、托管、兑换等功能，则构成CASP服务类型（1/2/3）。

推荐附NFT业务结构说明，列明其是否属于“非可替代性 + 非金融类资产”。

Q374：MiCA平台是否允许提供“合约交易”或杠杆服务？

答：MiCA不直接监管衍生品合约类服务，如杠杆交易、期货合约、永续合约等，但存在以下风险：

  • 此类业务受 MiFID II、EMIR 监管，通常需申请投资公司牌照（Investment Firm License）；

  • 如果平台将合约产品与客户资产混合托管，将触发额外风险披露义务；

  • MiCA CASP不得误导客户“加密资产交易即合约交易”。

建议分拆杠杆产品至其他平台或法律实体，MiCA主平台应以现货交易为主。

Q375：MiCA平台是否可以发行自己的平台币？是否需要额外备案？

答：可以，但须视发行币种性质：

  • 若为平台权益型币（如手续费折扣、投票权）且非投资用途，一般按“效用型代币”管理；

  • 若带有投资属性（如回购、分红、销毁机制），则可能被MiCA或MiFID认定为证券型代币；

  • 所有平台币发行前，需提交《白皮书》并通过合规审查，披露风险、用途、治理结构等。

推荐提交《代币发行说明书》及《客户权益声明模板》。

Q376：平台是否允许使用自动化机器人执行操作？是否需说明？

答：可以使用自动化脚本/机器人进行交易操作，但应：

  • 限制机器人权限，不得操作客户资金或绕过KYC流程；

  • 禁止用于“刷量”、欺诈、前置交易等违规行为；

  • 需在《系统说明书》中明示机器人模块用途与限制。

实操建议：所有机器人行为应纳入后台日志监控，定期审计其交易模式。

Q377：平台能否接受来自非欧盟国家的客户？如亚洲或中东？

答：可接受来自非欧盟地区客户，但必须满足以下合规前提：

  • 完成充分的KYC/AML审查；

  • 该地区未被列入欧盟高风险/受限名单；

  • 客户所在国家监管不禁止使用海外加密平台（如中国大陆、印度曾有限制）；

  • 平台需披露其数据传输与存储是否涉及跨境。

推荐附《非欧盟客户服务评估报告》以防BoL问询。

Q378：MiCA牌照是否可用于元宇宙项目中的资产交易？

答：若元宇宙资产满足如下特征，即构成MiCA监管对象：

  • 可流通（如游戏币、装备NFT）；

  • 有兑付价值或投机属性；

  • 存在中心化平台撮合、托管或资产传输行为；

元宇宙平台若提供资产兑换、托管、交易撮合，即属于CASP范围。

建议将元宇宙结构划分为“用户空间（非监管）”与“资产交易区（受监管）”。

Q379：MiCA平台是否允许使用链上oracle服务（如Chainlink）？

答：可以使用外部预言机服务，但应：

  • 确保其数据来源稳定、安全；

  • 合约逻辑中需包含Fallback机制防止中断；

  • 所有第三方服务需列入《系统合规说明书》并附风险声明。

建议设置“价格源验证机制 + 预言机监控指标”。

Q380：MiCA申请是否需披露与其他企业的合作协议？如银行托管/钱包供应商？

答：需要。以下合作协议应在申请材料中披露：

  • 托管银行 / 钱包提供商 / 合规服务外包 / 技术平台；

  • 每项协议需列出：服务范围、责任划分、终止机制；

  • 所有合作方需提供KYC、AML声明或受监管证明。

推荐附《第三方合作方清单表》与《服务协议摘要说明》。

Q381：MiCA申请公司是否必须设立专职IT部门？是否可外包？

答：MiCA并未强制要求设立内部IT部门，但对IT系统的合规性、稳定性及数据安全高度重视：

  • 可外包技术开发与维护，但必须签署《IT外包协议》；

  • 公司需有一名IT系统负责人（可兼任CTO）；

  • 所有系统运行与数据备份责任仍由持牌CASP承担；

  • 外包服务方必须接受监管抽查。

建议平台提交《IT系统职责分工表》与《外包服务合规声明》。

Q382：MiCA平台可以为客户提供法币出金服务吗？必须持支付牌照吗？

答：MiCA平台可以支持法币出金，但：

  • 不能自行操作结算，必须借助受监管支付机构（如EMI/PI）；

  • 自行持有客户法币并进行支付服务将被视为超范围经营，需申请PI牌照；

  • 客户出金流程需透明，且披露费用、周期、结算路径。

推荐与立陶宛或欧盟EMI机构合作，通过IBAN支付渠道合规实现出金。

Q383：平台上线前是否必须获得MiCA牌照？测试平台是否也受监管？

答：平台提供服务（如充值、下单、钱包创建）前，必须获得MiCA牌照；但：

  • 可提前建立测试系统，但不可开放公众访问或接受实盘资产；

  • 可申请在欧盟监管沙盒（如立陶宛BoL或ESMA试点）中测试；

  • 所有“Pre-launch”阶段必须具备内部风控、日志记录与数据保护功能。

推荐配合使用《Pre-MiCA测试期合规说明书》，阐述“上线前仅为内部测试”。

Q384：客户是否可以匿名注册账户或使用匿名钱包？

答：不可。MiCA明确要求：

  • 客户开户必须完成完整的KYC流程（含身份+地址验证）；

  • 不得支持匿名钱包对接（如不经实名的MetaMask）；

  • 禁止客户以假名、临时邮件注册账户。

推荐实施“实名验证 + IP地址识别 + 登录设备指纹校验”三重机制。

Q385：MiCA平台是否允许客户间P2P转账？是否需要交易撮合限制？

答：允许客户之间P2P转账，但平台必须满足以下要求：

  • 记录每笔交易的时间、对象、金额及理由；

  • 识别是否存在洗钱、结构化交易或非法套现风险；

  • 限制高频/大额匿名交易；

  • P2P功能若与托管系统整合，需配合AML动态监控。

实操建议：设置每日/每月转账限额，并启用自动监测工具识别高风险模式。

Q386：MiCA平台是否可以进行“链上发行”或“代币上架”？是否受额外监管？

答：可以进行链上发行，但应符合以下条件：

  • 所发行代币须符合MiCA所定义的加密资产类别（Utility/EMT/ART）；

  • 上架前需完成“Token Listing评估”；

  • 需提交发行白皮书、法律分类意见、技术文档；

  • 若代币具有证券属性，还需配合MiFID或Prospectus Regulation。

建议编制《Token Listing评估机制 + 技术与法律披露包》。

Q387：MiCA平台的员工是否需要合规培训？是否有强制时长或频率？

答：强制要求。MiCA合规框架中明确以下内容：

  • 所有接触客户或处理交易的员工每年至少进行1次合规培训；

  • 包括：AML/KYC、数据保护、系统使用规范、STR报告流程；

  • 需保留培训记录、考核结果与签到名单 ≥ 5 年。

推荐使用《员工年度合规培训模板》与《培训记录留档制度》。

Q388：MiCA平台若发生系统故障，是否需要报备？有无时限？

答：是的。MiCA要求：

  • 所有涉及客户资产安全、交易系统中断、数据泄露的事件，必须在72小时内向BoL报告；

  • 报告包括：事件发生时间、影响范围、应对措施、补偿机制；

  • 重大事件需由管理层签署正式说明信。

建议建立《重大事件应急响应流程图》+《报告责任分配表》。

Q389：是否可以将客户数据备份在非欧盟国家的云平台？

答：MiCA与GDPR共同规定：

  • 客户数据原则上应储存与备份于欧盟/EEA地区数据中心；

  • 若需跨境传输，必须提供“等效数据保护措施”，如DPA条款、传输影响评估等；

  • 中国大陆、俄罗斯等非“等值地区”需谨慎对待，可能需BoL书面同意。

推荐选择 AWS Frankfurt、Google Cloud Belgium 等数据中心，并提交《数据处理协议DPA》。

Q390：MiCA牌照是否可以转让或出售？是否可以变更UBO？

答：MiCA牌照不得直接转让，但可以通过以下方式实现实控变更：

  • 提前向BoL申请UBO/股东变更备案（重大持股变动>10%必须预先审批）；

  • 新UBO必须通过KYC与适当人选审查；

  • 所有实控权变更须附上背景说明、资金来源、商业逻辑等说明材料。

实操建议：提前准备《新股东尽职调查表》与《变更结构图 + 控股说明信》。

Q391：MiCA平台是否可以同时申请多类服务类型？是否必须一并启动运营？

答：可以同时申请多种服务（如钱包托管 + 交易所 + 法币兑换等），但：

  • 申请时必须在表格中列明所申请服务类别；

  • 无需所有服务同时上线，但需提交完整商业计划与技术说明；

  • 若未来增加服务类别，需向BoL提交服务扩展申请（附补充资料）。

建议在申请初期预留空间，并提交一份《阶段性运营启动时间表》。

Q392：MiCA是否允许使用虚拟办公室或联合办公空间？

答：原则上不鼓励，但并不完全禁止：

  • 可使用联合办公空间作为注册地址，前提是确保有专属办公间、实体运营存在；

  • 监管人员必须可随时上门稽查；

  • 需要提供租赁协议、实际办公照片、访问安排说明。

实操建议：配合递交《办公场所证明包》，包括租赁合同、门牌照片、座位布置图等。

Q393：平台上线后客户资产如何划分？公司资产与客户资金是否需隔离？

答：MiCA要求客户资产与平台自有资产完全隔离，包括：

  • 客户资产需保存在独立账户（加密资产托管地址或法币分户）；

  • 不得挪用客户资产作流动资金、抵押或再投资；

  • 客户资金需每日对账，并可接受外部审计。

推荐建立《客户资金隔离政策》及每日资产对账制度。

Q394：立陶宛MiCA牌照是否可以通过电子签章（e-signature）递交文件？

答：可以接受电子签名文件，但需满足条件：

  • 使用欧盟eIDAS标准认可的电子签章系统（如DocuSign、Adobe Sign EU区域授权）；

  • 所有签名者身份需明确；

  • 高管变更、AML政策、法定声明等重要文件仍建议使用实体签章 + 公证。

实操建议：采用BoL认可的签章服务提供商并备案。

Q395：BoL是否会对申请人进行面试或实地检查？

答：在申请阶段可能安排以下形式：

  • 远程会议（Teams / Zoom），询问RO/MLRO制度理解；

  • 文件真实性核查，如银行开户函、服务器合规证书；

  • 必要时安排实地稽核，尤其对于敏感业务如托管/兑换类。

建议准备好《面谈问答材料包》，涵盖AML制度、技术架构与商业模型逻辑。

Q396：MiCA平台是否可以设立子品牌或产品线运营？是否需报备？

答：可以设立多个品牌或业务线，但：

  • 主体公司名称必须为获牌CASP公司；

  • 所有子品牌/产品线需向BoL备案，披露其用途与网站；

  • 客户服务、资金流向、数据处理必须归属于母公司合规体系。

推荐提交《品牌使用说明书》+《多品牌合规一致性说明》。

Q397：平台是否可以通过API连接其他交易平台？是否需要额外审批？

答：可以集成API连接其他平台（如行情、流动性服务、下单接口），但需满足：

  • 所对接平台本身合规合法，并具MiCA或类似授权；

  • 提前申报API集成计划，列明数据流向、风控机制；

  • 不得将核心交易/撮合功能外包或规避自身监管责任。

推荐在《IT系统说明书》中列明“外部API结构图”。

Q398：客户是否可以在平台上设置自动交易程序（BOT）或使用AI策略交易？

答：MiCA不禁止算法交易或自动化，但平台需承担以下义务：

  • 客户启用BOT/AI时，平台应提示其风险；

  • 若算法交易对市场造成操纵、异常波动，平台需介入；

  • 强烈建议设立算法接入的限流机制 + 异常行为识别系统。

建议建立《算法交易接入政策》并限制BOT访问频率。

Q399：平台是否允许客户设置多重签名、多管理员账户？监管是否鼓励此机制？

答：监管高度鼓励使用多签（Multi-Signature）机制与权限分层：

  • 提高冷钱包安全性；

  • 降低人为操作风险；

  • 客户企业账户可以启用多管理员机制，但平台应建立权限日志与访问审计系统。

推荐配合冷钱包提交《权限签名结构图 + 权限说明文档》。

Q400：若MiCA公司计划未来引入VC或战略投资者，是否须提前申报？

答：是的，若投资者持股超过10%，或可实际控制公司，应提前申报：

  • 提交《重大变更申请》至BoL；

  • 附投资者KYC资料、资金来源证明、投资意图说明；

  • 监管将评估投资对公司治理、资金结构、合规稳定性的影响。

建议在初期搭建公司结构时预留股权空间，并设《投资人进入控制流程图》。

Q401：MiCA牌照是否支持提供加密资产抵押贷款业务？是否需额外许可？

答：MiCA 原文未直接涵盖“抵押贷款（Crypto-backed Lending）”业务，但如涉及客户资金/资产处理，需考虑以下监管要求：

  • 若平台提供贷款资金来源，可能触及信贷活动许可（非MiCA范围）；

  • 如第三方提供贷款，而平台仅作为撮合者，需明确免责条款与监管边界；

  • 平台须在商业计划中明确申报“是否涉及放贷或类金融服务”，否则可能因超范围经营被质疑。

实务建议：若需此类业务，建议附加《信贷模型说明书》与《业务分离策略文件》。

Q402：MiCA平台是否可为客户托管NFT类资产？NFT是否属于MiCA监管范围？

答：一般而言，**非可替代性代币（NFTs）**不属于MiCA核心监管资产范围，但：

  • 若NFT具备可分割性、金融属性或批量发行，可能被重新界定为受监管加密资产；

  • 若平台托管NFT，需证明其不具有支付/投资替代功能；

  • 若同时支持加密货币/稳定币，平台仍需完整CASP牌照。

建议准备《NFT资产分类及非MiCA豁免说明》，并向BoL申请预核准确认函。

Q403：申请MiCA牌照是否需提前在立陶宛开设银行账户？如外籍公司开户是否困难？

答：MiCA申请过程中不强制先开户，但实际操作中：

  • 多数公司需有立陶宛/EU本地银行或EMI账户以接收初始资本；

  • 开户需董事护照、公证文件、UBO说明等；

  • 若申请人为第三国实体，开户可能耗时2–3个月。

建议同步推进开户流程，并考虑先以EMI机构账户过渡，再升级本地银行账户。

Q404：MiCA牌照是否需要保留公司运营的客户聊天记录、电话录音等交互证据？

答：是的。MiCA第64条明确要求：

  • 对于涉及投资建议、订单执行、资产托管等关键行为，必须保留客户沟通记录；

  • 包括电邮、电话、即时通讯（如WhatsApp、Telegram等）；

  • 所有记录须保存最少五年，如涉及诉讼或监管调查，需配合延长。

实务建议：建立《客户互动记录保留制度》并部署合规记录归档系统。

Q405：在MiCA监管下，是否可以使用DeFi技术架构或链上合约自动化运营？

答：MiCA原则上支持技术中立，但对于DeFi：

  • 平台若为完全去中心化DAO形式，可能不适用MiCA；

  • 若平台对外提供撮合/保管/兑换等服务，即便基于DeFi协议，仍需受监管；

  • 所有链上操作应当配有链下合规控制，如客户识别、资产冻结机制等。

建议同时附上《链上合约自动执行模型图解》+《DeFi合规适配方案》。

Q406：MiCA平台是否可接受客户通过稳定币充值？如USDT、USDC、DAI等？

答：可以接受，但需满足以下条件：

  • 稳定币本身具备明确发行方、1:1储备机制、可验证清算证明；

  • 平台需具备识别机制，防止匿名来源或不合规稳定币注资；

  • 建议仅接受被MiCA承认的EMT或ART型稳定币。

实操建议：设定白名单稳定币列表，并配置交易对手方风险评估系统。

Q407：MiCA平台发生冷钱包故障/攻击事件时，是否必须向监管申报？申报时限是多少？

答：必须申报，依据MiCA第66条：

  • 凡涉及客户资产损失、系统入侵、数据泄露或冷钱包被破解，均属重大事件；

  • 须在72小时内向BoL与ESMA报告初步情况，并在10日内提交详细事故调查报告；

  • 若客户受影响，须在第一时间通知所有受影响账户。

建议预设《安全事件应急预案》并绑定合规官触发机制。

Q408：MiCA平台是否可以提供技术外包？例如：KYC系统/钱包托管系统是否可委托第三方？

答：可外包部分功能，但平台须承担全责：

  • 所有外包必须签署服务协议（SLA）；

  • 外包服务商必须具备欧盟监管认证或等效标准；

  • 平台仍需确保KYC数据、冷钱包密钥、交易记录可被监管追溯。

建议提供《外包清单》+《外包方审计合规性说明书》。

Q409：MiCA是否允许持牌CASP平台向非欧盟客户提供服务？是否涉及额外许可？

答：MiCA主要适用于在欧盟境内开展业务的CASP，如平台向第三国客户提供服务：

  • 不禁止，但需保证不违反对方国家法规；

  • 应区分服务边界，并设置地域访问策略；

  • 建议披露于Terms of Service，并设置风险提示。

推荐编制《跨境服务限制政策》并在官网使用Geo-Fencing地理识别策略。

Q410：MiCA实施后原持牌VASP是否自动转为CASP？是否需重新申请？

答：不自动转换。原持牌VASP必须进行MiCA过渡注册，包括：

  • 补交MiCA申请表 + 商业计划 + AML/KYC政策；

  • 在BoL设定的**过渡期（预计2025年6月前）**内完成资料更新；

  • 如未完成过渡，原VASP将失去欧盟监管资格。

建议提前准备“MiCA迁移包”，确保过渡顺利完成。

Q411：MiCA持牌机构是否需要定期向客户发送资产对账单或资金存管报告？

答：是的。根据MiCA第63条及客户资产保护相关条文，平台需：

  • 向客户提供至少每季度一次的账户对账单；

  • 报告内容须涵盖：资产类别、余额、托管状态、任何异动说明；

  • 如客户资产处于第三方托管状态，须列示托管方及安全保障信息。

建议建立自动生成机制，并保留发送/确认的审计记录，便于监管检查时追溯。

Q412：MiCA是否要求对高风险客户或高净值客户采取额外尽职调查措施（EDD）？

答：是的，MiCA要求平台遵守AML法规（含AMLD6），其中：

  • 高风险客户（PEP、公职人员、受制裁国家）须执行增强型尽调（EDD）；

  • 对于大额交易、非面见开户或来自高风险国家的客户，要附加背景调查、收入来源声明等；

  • 记录必须可供五年内稽核。

实操建议：系统内嵌EDD触发机制，配置PEP/Sanctions API、EDD模板清单。

Q413：平台是否可以与多个国家的RO（Responsible Officer）共享职责？是否允许分布式管理？

答：MiCA容许一定程度的职能外包或远程管理，但核心监管责任要求：

  • 至少一名RO常驻立陶宛，对接BoL；

  • 多RO设定须明确每位负责的范围，如IT安全、合规、AML等；

  • 所有RO需签署岗位职责承诺书，并随牌照申请提交。

建议制定《RO职责分工图》并在董事会章程中列明责任架构。

Q414：MiCA是否规定了平台必须提供客户资产“破产隔离（ring-fencing）”机制？

答：
是的。MiCA要求：

  • 平台资产与客户资产必须分离；

  • 不得用于自营或担保他人债务；

  • 需在系统中建立“客户钱包识别码”与平台钱包分账结构。

强烈建议附上《客户资产隔离结构图》与系统级账户分离逻辑图。

Q415：MiCA牌照是否允许发行稳定币？是否另需EMT/ART额外登记？

答：MiCA下稳定币属于两类监管对象：

  • EMT（电子货币代币）：需单独申请EMI许可，类似于银行电子货币；

  • ART（资产参考型代币）：受欧洲银行管理局（EBA）强监管，需额外登记；

  • CASP只能处理上述代币，不等于拥有发行权。

如拟发行稳定币，须参考 MiCA Article 15–23 并准备稳定币白皮书。

Q416：MiCA是否限制平台广告宣传的内容和对象？例如禁止向未成年人宣传？

答：
是的，MiCA对加密资产宣传设有合规框架：

  • 禁止虚假、误导性、夸大性描述；

  • 宣传必须注明风险，包括资产波动性、无担保、可能亏损等；

  • 不得以任何形式面向18岁以下未成年人投放加密投资广告。

建议准备《MiCA广告宣传合规指引》和定期合规审查广告文案。

Q417：MiCA平台是否需公开披露其冷钱包地址或资产储备情况？

答：部分需要披露，尤其是：

  • 平台若提供托管服务，应公开其资产托管策略、冷钱包存储机制；

  • 不强制公布钱包地址，但需说明资产安全性与备份机制；

  • 若为稳定币或EMT托管商，需每季度披露资产匹配报告。

建议公开《资产保障声明》与《钱包托管策略白皮书》，增加客户信任。

Q418：MiCA平台是否需要支持客户请求关闭账户并销毁钱包私钥？

答：是的，MiCA及GDPR数据保护法合并实施下，客户可要求：

  • 注销账户；

  • 清除其个人信息和身份数据；

  • 在可能条件下请求平台销毁其专属钱包密钥或解除与平台绑定。

平台应制定《账户注销及数据删除政策》，提供一键申请通道。

Q419：MiCA是否限制平台收取过高手续费或设置不透明定价模型？

答：
是的。MiCA要求：

  • 所有费用必须在平台开户前公示；

  • 不得隐藏交易费、网络费、清算费等；

  • 费率必须合理、透明，并提供英文或当地语种说明。

建议制定《收费标准披露手册》并经合规官审核后上线官网。

Q420：是否允许平台使用非欧盟第三国的托管服务商？如新加坡或开曼托管公司？

答：仅在满足以下条件下允许：

  • 第三国服务商需受等效监管，如新加坡MAS或瑞士FINMA；

  • 必须有明确的合规备忘录（MoU）；

  • 所有客户资产必须有审计、透明报告机制，可被BoL或ESMA抽查。

建议同时准备《托管外包合规说明》和《跨境托管审计流程图》。

Q421：MiCA平台是否可以提供杠杆交易或衍生品（如期货、期权）服务？

答：MiCA并不涵盖加密衍生品（crypto derivatives）。这类产品仍受《MiFID II》（欧盟金融工具市场指令）监管。

  • 若拟提供杠杆、CFD、期货、期权等服务，必须另行申请MiFID牌照；

  • 仅限提供加密资产本身（如BTC、ETH等）现货服务；

  • 如平台无MiFID资格，开展杠杆/衍生交易属于违规。

建议如需提供衍生品，另设子公司获取MiFID许可或通过持牌经纪商合作。

Q422：是否允许平台同时运营多币种（法币）支付通道，如支持USD、EUR、HKD等？

答：允许，但需满足以下条件：

  • 法币支付网关服务商必须是受监管金融机构（如银行、EMI、PI）；

  • 平台本身不可“擅自提供法币存取服务”除非持有EMI牌照；

  • 所有法币转账交易，须符合法币国家的KYC/AML规定。

实操建议：采用“EMI牌照+CASP双结构”，将法币托管与加密资产分离管理。

Q423：MiCA平台是否需要设立专门的数据保护官（DPO）或GDPR负责人？

答：如平台处理大量敏感客户数据（尤其是欧盟自然人数据），MiCA平台需：

  • 指派数据保护官（Data Protection Officer, DPO）；

  • 建立完整的GDPR合规框架，包括数据访问记录、用户同意机制、数据销毁流程等；

  • 若处理交易指令与KYC数据跨境，须备案数据转移架构（如使用AWS/SaaS）。

建议生成《GDPR合规报告》和《DPO岗位职责书》。

Q424：平台如欲变更技术服务提供商（如托管钱包系统、KYC API厂商），是否需要向BoL报备？

答：是的。根据BoL监管通知：

  • 涉及客户资产存储、交易撮合、KYC识别的关键系统供应商变更，须提前报备；

  • 除非平台拥有系统的“完全控制权”，否则视为“关键运营外包”；

  • 报备文件应包括《变更说明信》、《新供应商尽调文件》、《服务协议副本》。

建议平台建立“技术供应商管理政策”并设立外包审核小组。

Q425：MiCA是否要求平台设立内部审计功能？是否必须外聘审计公司？

答：MiCA要求持牌机构设有：

  • 独立内部审计职能（Internal Audit），可为内部岗位或外包；

  • 若年营收/客户规模超一定标准，必须由外部审计师进行年审；

  • 外部审计公司需在欧盟审计注册名册内登记。

建议设立《审计计划表》、每年更新《内部控制评估报告》。

Q426：MiCA是否允许平台设定交易最低门槛或账户激活费？

答：允许，但需：

  • 在开户前明确公示；

  • 不得设置“隐藏费用”或条件变动不透明的门槛；

  • 激活费用需合理，并非限制准入手段。

建议在T&C中加入“账户最低操作说明”和“费用政策章节”。

Q427：是否可同时申请MiCA CASP + ART + EMT等多种牌照？是否推荐？

答：技术上可行，但需分别满足其监管标准：

  • CASP：运营服务平台；

  • ART：资产参考型代币发行（如稳定币锚定一篮子资产）；

  • EMT：类电子货币代币，需配套EMI许可。

⚠️ 每种牌照的资本金、风控体系、白皮书要求皆不同，通常分阶段申请更合理。

实操建议：先取得CASP运营许可后，按业务规划推进ART/EMT发行。

Q428：MiCA牌照是否允许平台通过API提供B2B接入服务？例如提供白标解决方案？

答：可以，但须满足：

  • 接入方为合法注册企业并接受平台KYC/AML；

  • 平台需对所有通过API交易的最终客户行为承担责任；

  • 不得将监管义务“外包”给合作方。

建议签署《白标合作合规责任分配协议》+定期API审计报告。

Q429：平台是否可支持匿名交易（如Tor、隐私币Zcash等）？

答：否。MiCA严格禁止任何形式的匿名交易：

  • 明确要求客户身份必须可验证、可追溯；

  • 禁止支持匿名币、混币服务（Mixing/Tumbling）；

  • 使用隐私网络访问平台也必须强制KYC登录。

建议系统设定自动封禁匿名访问节点和列入黑名单资产。

Q430：MiCA是否对平台设置“灾难恢复时间（RTO）”或“业务持续时间（BCP）”要求？

答：是的，MiCA结合DORA条例要求平台具备：

  • 明确RTO（Recovery Time Objective），如重大宕机后1小时内恢复；

  • BCP（Business Continuity Plan）覆盖系统、数据、人事、通讯等模块；

  • 每年进行灾备演练并备案报告。

建议提交《IT灾难恢复计划》和《业务持续性管理手册》。

Q431：申请MiCA牌照时，如果当前已有VASP牌照，是否可以“升级”申请？

答：是的。立陶宛银行（BoL）设有**“VASP向MiCA CASP过渡机制”**，但需满足：

  • 现有VASP牌照有效；

  • 提交MiCA补充材料，包括新版本AML政策、系统安全报告等；

  • 向BoL发函说明“业务连续性计划”与申请升级理由。

实务建议：在VASP基础上“补交差额材料+流程”，有助于压缩审批周期。

Q432：MiCA平台是否可以使用虚拟办公室作为注册地址？

答：不可。MiCA要求**“实体办公场所 + 实质性运营”**：

  • 注册地址必须可实际接待监管抽查；

  • 租赁合同需附楼层照片、人员进驻计划；

  • 虚拟办公室服务（如仅收信地址）将被驳回。

建议在立陶宛租用真实办公场地，并配合人员驻场记录。

Q433：平台是否可以接受来自高风险国家（FATF黑名单）的客户？

答：可以，但需满足下列更高标准：

  • 加强客户尽职调查（EDD），如视频核验、地址证明等；

  • 必须在客户资料中注明“高风险类别”；

  • 平台需提交该类客户的单独STR备查。

⚠️ 建议定期审查客户名单并与FATF更新同步。

Q434：MiCA是否强制平台进行“客户适当性评估”？如果客户亏损平台是否要负责？

答：MiCA确实要求平台建立客户适当性模型（Suitability Test），但：

  • 并不要求承担客户交易结果损失；

  • 但必须记录客户风险承受能力、交易经验等数据；

  • 若客户属于“非适当客户”仍提供高风险资产，将在检查中被处罚。

推荐开发“投资者问卷模块” + 定期评估机制。

Q435：MiCA是否禁止平台提供“推荐奖励”或“拉新返佣”活动？

答：并不完全禁止，但存在严格限制：

  • 必须事先说明奖励模式，不得误导或夸大；

  • 禁止对未实名用户发放任何形式的佣金；

  • 若存在“链式返佣”或多层级推广结构，视同传销类违规。

建议所有推荐奖励活动均附带法律意见函备案。

Q436：平台收取的交易手续费是否需缴纳增值税？MiCA对此是否有特殊处理？

答：MiCA本身不设税务条款，但各成员国的税务机关对手续费处理存在差异：

  • 立陶宛目前对CASP服务中的手续费按“金融中介服务”免征VAT；

  • 但若平台还提供付费培训、订阅类报告、API接入等，需征税。

建议聘请立陶宛税务顾问编制《税务适用意见书》。

Q437：MiCA平台是否允许通过子公司或关联方持有合规资源（如技术系统）？

答：可以，但必须满足：

  • 控股结构透明，子公司纳入整体监管；

  • BoL可跨实体抽查所有合规文档；

  • 实际运营实体与申请实体之间必须有正式服务协议。

推荐提交《控股公司结构图》+《子公司服务授权函》。

Q438：平台可否仅在欧盟外（如新加坡）运营数据中心？

答：MiCA/DORA联合规定，关键系统数据必须存储于欧盟境内：

  • 不得将客户身份资料、交易日志、冷钱包密钥储存于第三国；

  • 非关键系统如官网内容、营销数据可设海外CDN。

强烈建议设置“欧盟主节点 + 海外镜像节点”的混合式合规架构。

Q439：MiCA平台是否可以为客户开设子账户或托管账户？

答：可以，但需符合以下监管要求：

  • 每一客户账户与平台自营账户必须隔离；

  • 不得混合资金，必须设置子账户分账系统；

  • 客户资产每日应有账务对账与出具凭证。

推荐使用“客户账户分账+定期审计+第三方审计师”的三重保障模式。

Q440：MiCA是否规定MLRO职责范围？是否需要设立替代MLRO人员？

答：MiCA规定MLRO（反洗钱合规官）必须：

  • 具备立陶宛/EU合规经验；

  • 每年完成规定反洗钱培训课程；

  • 配合提交STR报告，并列席合规会议。

⚠️ 若MLRO请假或离任，必须指派临时代理人并报告BoL。

建议提交《MLRO职责说明书》+《MLRO年内值勤记录》并每年审查一次。

Q441：平台客户是否必须完成活体视频认证？还是仅身份证+地址证明足够？

答：MiCA并未强制活体视频认证，但强调KYC需“高等级身份识别”。BoL建议：

  • 高频交易客户、机构客户应采用视频认证+文件核验；

  • 一般散户客户最低需身份证件 + 地址证明 + 风险承受力问卷；

  • 来自高风险国家客户，推荐附加活体认证流程。

最佳实践：结合SumSub、Jumio等KYC API引擎部署多层验证。

Q442：客户签署的服务协议需符合哪种法律格式？是否需要翻译？

答：

  • 客户服务协议应采用英文或立陶宛语版本，若为多语种客户，需提供相应翻译；

  • 内容必须包括：服务范围、风险提示、终止条款、客户投诉机制、MiCA免责声明；

  • 可采用电子签名，但需配合IP地址/时间戳留存。

建议使用DocuSign、Adobe Sign等符合eIDAS认证的签署工具。

Q443：是否可以从欧盟以外国家（如香港、新加坡）远程运营MiCA持牌平台？

答：MiCA允许部分岗位远程运营（如技术开发、投资顾问），但前提是：

  • 公司必须在立陶宛设有实体办公室；

  • 至少一名高级管理人员常驻立陶宛；

  • 合规/风控/MLRO岗位应在欧盟管辖内运营。

远程架构应配有《远程人员职责说明书》及技术访问控制文档。

Q444：可否使用智能合约执行客户资产托管/转账？是否需要提前申报代码？

答：

  • 可使用智能合约托管客户资产，但合约代码需通过审计；

  • 建议附第三方智能合约安全审计报告（如Certik、Hacken等）；

  • BoL鼓励提交源码版本 + 关键操作接口说明。

系统中应附权限控制图解及“黑天鹅操作手册”。

Q445：MiCA平台是否必须有独立董事？董事会结构有什么最低要求？

答：MiCA本身不强制独立董事，但BoL要求：

  • 公司至少有两名董事；

  • 建议董事中至少一人为“非股东”角色，以体现治理独立性；

  • 董事会应设立会议制度并记录关键决策（例如合规批准、产品上线）。

实务建议：董事结构设定为“CEO + 风控董事 + 财务负责人”有利通过审批。

Q446：平台可否与第三方DeFi协议（如Aave、Uniswap）集成？

答：MiCA允许平台整合DeFi协议，但：

  • 客户资产流向必须透明记录；

  • 所集成协议须披露智能合约审计报告；

  • 不得向客户“推荐”未审核协议，避免触及“建议类服务”监管。

建议平台以“技术接口”方式接入，并在系统文档中设立合规隔离层。

Q447：是否可向客户提供杠杆交易服务？MiCA对此有何限制？

答：MiCA并未禁止杠杆交易，但施加严格要求：

  • 杠杆倍数需合理（例如 ≤5x 为市场常规）；

  • 客户需签署《杠杆风险披露函》；

  • 需设置自动止损/追缴机制，平台不得将客户亏损转嫁系统风险。

风控模块应实现实时强平、保证金不足告警及审计留痕。

Q448：申请MiCA期间，公司是否可以试运营或Demo上线？

答：可以，但必须明确标示“Demo版本”或“受限试运营”：

  • 不得收取客户真实资金；

  • 不得公开宣传“合规运营”；

  • 可供监管演示用，但必须提交测试计划书和访问日志。

建议平台Demo版本隔离部署，并在首页标注“非正式运营环境”。

Q449：平台上线前是否需要进行PenTest（渗透测试）？谁可执行？

答：MiCA法规虽未强制，但BoL要求系统上线前具备信息安全审查：

  • 推荐每年执行一次完整PenTest，由第三方安全公司执行；

  • 报告应附漏洞发现、修复记录及最终签字页；

  • 可选择服务商：KPMG Cyber、NCC Group、EY Cyber Security等。

PenTest应覆盖交易系统、钱包接口、后台权限、数据库审计等多个模块。

Q450：是否需要在官网公开监管信息、MLRO联系方式、投诉渠道？

答：是的，MiCA要求平台设置“透明披露区”，需包含：

  • 公司名称、牌照编号、监管机构网址；

  • 客户投诉电邮、MLRO紧急联系方式；

  • 服务条款、费用表、风险披露文件。

建议官网设立“合规信息栏”，并定期自检更新内容。

Q451：MiCA持牌公司是否必须每年进行内部合规培训？培训内容包括什么？

答：是的。MiCA合规要求企业建立持续培训机制，培训内容包括：

  • MiCA法规更新与执行情况；

  • 客户投诉处理与STR识别机制；

  • 数据保护与IT系统权限管理；

  • 角色分离制度与操守标准（含MLRO/RO职责）；

  • 反洗钱（AML）与反恐融资（CTF）政策执行细节。

建议培训记录以PDF保存，并由MLRO签署回执，纳入年审材料。

Q452：MiCA牌照是否必须绑定公司银行账户？可否使用EMI或第三方支付？

答：是的，持牌实体必须具备银行账户以接收客户资金与监管结算。

  • 可使用立陶宛本地银行账户（如：Šiaulių Bankas、Luminor）；

  • 若无传统银行账户，EMI账户亦可（如Revolut Business）；

  • 账户需可提供客户资金隔离说明函（Segregation Letter）。

建议选择与BoL配合良好的金融机构开设多币种账户。

Q453：客户资产必须由第三方保管吗？平台可以自行托管吗？

答：MiCA未强制托管外包，但强调资产分离与托管安全性：

  • 平台可自托管（冷钱包、硬件设备等）；

  • 自托管需提交权限控制方案、安全审计报告、冷钱包技术文档；

  • 若第三方托管，必须签署托管协议 + 风险共担条款。

多数平台采用“冷热钱包混合 + 多签 + 双重权限”模式。

Q454：MiCA持牌机构是否可以销售DeFi类基金或结构性产品？

答：在MiCA框架下：

  • 平台不得直接销售未经核准的金融产品；

  • 如为结构性产品，应提交产品说明书 + 风险等级评估 + 投资者适当性分析；

  • 高风险产品需提供独立第三方审查意见。

建议先获取MiFID II投资类许可，再开展加密资产投顾或结构型销售业务。

Q455：MiCA是否要求设立风险委员会或合规委员会？董事会可否兼任？

答：MiCA未强制设立委员会制度，但BoL鼓励公司建立如下机制：

  • 合规委员会（Compliance Committee）：每季度评估合规风险；

  • IT风险委员会：评估系统更新、渗透测试、权限审计；

  • 可由董事会兼任部分职责，但需有会议记录及投票机制。

组织结构图中建议列明各委员会及职责归属，便于审批通过。

Q456：MiCA公司是否必须向客户提供提款说明或冷钱包出金接口？

答：是的。MiCA要求客户资产可按需取回，且出金机制必须明确：

  • 提供提款流程文档（含冷钱包提币路径说明）；

  • 设置提币限额、审批机制及黑名单系统；

  • 出金记录需存档5年以上。

建议平台配置“提款审核 + 双重签名 + IP绑定”机制，防范滥用。

Q457：是否可使用DAO架构控股MiCA持牌公司？DAO是否被认可为法人？

答：MiCA原则上不禁止DAO控股，但：

  • DAO本身在大多数欧盟国家不被认定为法人主体；

  • 控股路径需经SPV中介结构“穿透式”揭示最终控制权；

  • 必须提交DAO治理规则、代币投票机制说明与实际控制人声明。

BoL更倾向于“有实体+有董事”的传统架构，DAO仅适合作为间接股东或非控股参与者。

Q458：平台公告栏是否必须包含加密资产风险说明？是否有范本？

答：是的。MiCA要求平台官网/APP需设有显著风险提示，包括：

  • 加密资产可能剧烈波动；

  • 客户投资或无法完全收回本金；

  • 平台不承担客户投资损失责任；

  • 冷钱包或智能合约存在潜在技术漏洞。

可参考ESMA公开的《Retail Crypto Investor Risk Disclosure Template》。

Q459：MiCA是否允许平台提供API交易接口？如允许，是否需要额外申报？

答：允许。MiCA支持技术开放，但对API权限管理与使用目的有监管要求：

  • 提供API需有认证机制（如OAuth、API Key、IP绑定）；

  • 客户需签署《API使用协议》；

  • 若API允许下单、转账等操作，必须配合强验证（2FA）；

建议API提供日志审计、限速保护及权限分级文档。

Q460：MiCA监管是否接受NFT平台申请？NFT是否属加密资产？

答：MiCA目前将“独特、不可分割、非金融功能主导”的NFT排除在监管之外。

  • 若NFT具金融属性（如：收益分红、交易所交易），可能被重新定义为加密资产；

  • NFT平台可主动申请MiCA牌照，强化其可信度及银行合作可能性；

  • 建议提交《NFT非金融属性说明》避免混淆监管界限。

若平台允许NFT与稳定币互换，建议一并申请第3类服务（加密与法币兑换）。

Q461：MiCA持牌公司是否可以接入区块链预言机（Oracle）？

答：可以，但需遵守以下条件：

  • 所接入的预言机服务提供商需有透明的数据源披露；

  • 平台需设置“预言机失效响应机制”，防止因故障引发资产异常清算；

  • 若用于DeFi类合约，需要第三方安全审计意见 + 风险评估报告。

推荐设置双预言机冗余机制（如：Chainlink + Band Protocol）。

Q462：MiCA是否要求加密资产平台提供多语言服务界面？

答：并未强制要求多语言，但若服务面向不同欧盟成员国，需提供：

  • 至少英文界面及目标客户国的官方语言界面；

  • 风险提示、合规政策需有本地化版本；

  • 客服支持建议覆盖英语+本地语言（如德语、法语、立陶宛语）。

官方客户说明文档建议包含语言版本控制记录。

Q463：MiCA是否对智能合约部署方式有限制？是否必须链上开源？

答：MiCA未强制链上合约必须开源，但监管部门有以下建议：

  • 合约涉及客户资产逻辑（如交易撮合、资金池管理）应提交审计报告；

  • 若为平台核心功能建议开源并公开白名单控制权限；

  • 应提供智能合约版本控制说明及漏洞响应机制。

提交代码安全审计证书（如Certik、SlowMist）有助审批通过。

Q464：MiCA是否支持分布式身份（DID）机制进行客户KYC？

答：MiCA支持技术中立，可使用DID技术进行KYC身份绑定，但前提是：

  • 必须符合eIDAS（欧盟电子身份认证）或BoL认可的等效KYC标准；

  • 平台需存储KYC访问授权记录、加密密钥调用日志；

  • 如使用区块链存证KYC结果，应提供不可逆删除机制说明。

推荐结合传统KYC与DID验证形成双重认证。

Q465：平台是否可设立内嵌钱包（embedded wallet）并强制绑定？

答：MiCA允许平台设立嵌入式钱包作为服务一部分，但必须满足：

  • 客户知情并授权其资产保管方式；

  • 可自由转移资产至外部地址（不设出金限制）；

  • 清晰划分自托管钱包与客户账户余额。

客户资产报告需独立列示平台账户与个人钱包资产。

Q466：MiCA是否对Web3 DApp类服务有额外限制？

答：MiCA对提供“金融性质服务”的DApp提出监管适用，具体判断标准包括：

  • 是否可兑换价值单位（token）；

  • 是否向公众提供交易、借贷、质押等金融服务；

  • 是否中心化管理。

若满足上述条件，DApp营运者应申请MiCA CASP牌照。

纯工具类DApp（如NFT展示、浏览器插件）一般不纳入MiCA适用范围。

Q467：是否可以以法人控股结构方式设立多个MiCA牌照公司？

答：允许，但BoL会重点关注以下：

  • 母公司之间的控制路径与业务防火墙是否明确；

  • 是否存在“规避监管”的结构设计；

  • 各子公司是否具备独立运营能力与本地化要求。

应提交“控股结构穿透图”+ 每家公司业务划分说明。

Q468：是否可设立独立子品牌针对不同国家市场？MiCA是否允许？

答：MiCA许可持牌机构在欧盟内跨境设立分支机构或子品牌，只需：

  • 在ESMA统一备案平台上更新注册信息；

  • 每个子品牌需遵守当地语种、消费者告知义务；

  • 若为单一法人架构，可共用核心系统与AML政策，但需备案说明。

建议统一管理后台并区分品牌前台呈现。

Q469：是否允许持牌机构持有客户加密资产并利用其参与Staking？

答：可允许，但需满足透明+授权+隔离三大原则：

  • 客户需签署授权同意书，说明资产用于Staking；

  • 收益分配机制需清晰且客户可撤回；

  • 平台不得将客户资产用于“高风险合约”或衍生品抵押。

建议设置客户资产“可用余额”和“参与质押余额”分开展示。

Q470：MiCA牌照公司是否可提供Token生成与发行服务（Token Factory）？

答：可以，但若生成的Token拟上市流通或公众募集资金，则：

  • 必须提交《白皮书》（White Paper）并履行披露义务；

  • 若为EMT或ART代币，应事前获得欧盟央行或BoL核准；

  • Token智能合约应披露发行机制、总量限制、销毁机制等信息。

建议附上《技术文档》《发行方法律意见》《风险因素表》以配合合规。

Q471：申请MiCA时是否可以一开始申请所有10类CASP服务？

答：技术上是可以的，但有以下注意事项：

  • 每类服务都需单独提交相应的合规政策、系统说明及商业计划；

  • 审批时间会大幅延长，BoL需逐项核查；

  • 高管经验、技术系统需匹配多服务运营能力；

  • 建议按“核心服务优先”原则分阶段申请。

推荐初期申请3–5类服务，运营后逐步递交扩展申请。

Q472：MiCA下托管服务是否可以使用第三方系统？

答：可以外包部分技术系统，但必须确保：

  • 关键控制（如私钥、权限分层）由持牌机构掌握；

  • 第三方服务商需符合欧盟GDPR、ISO27001等标准；

  • 合同中必须列明数据主权归属与灾备安排。

外包合规说明（Outsourcing Statement）必须一并递交BoL备案。

Q473：MiCA要求的保险机制（Insurance Cover）标准是怎样的？

答：MiCA要求提供客户资金或资产保障的机制，可通过以下方式满足：

  • 购买专业责任险（Professional Indemnity Insurance）；

  • 建立内部保障储备金机制；

  • 若为第三方托管，可要求其具备保险或担保协议。

建议附保单摘要、保障额度说明、赔付条件列表一并提交。

Q474：是否允许与DeFi协议进行集成合作？

答：允许与DeFi协议进行接口集成，但MiCA要求：

  • 客户须知其资金进入非托管系统的潜在风险；

  • 合同中须设定责任划分（如智能合约Bug是否由平台承担）；

  • 应披露集成的DeFi协议名称、审计情况、安全报告。

所有合约交互必须记录于内部日志系统中，备查。

Q475：MiCA是否适用于NFT交易平台？

答：若NFT具有金融属性或可细分交易（如碎片化NFT），则适用MiCA；否则不纳入。

  • 纯艺术或不可替代性内容（如数位收藏）通常不适用；

  • 若NFT附带收益权（如租金、权益分红），则需作为“加密资产”监管。

建议平台进行NFT资产分类政策说明与法律意见函提交。

Q476：客户KYC后是否必须定期更新验证资料？

答：是的。MiCA要求：

  • 高风险客户每年更新一次KYC；

  • 低风险客户每三年更新一次；

  • 客户资料变动（如地址、职业、税务身份）须实时更新。

应设立KYC更新提醒机制，并保留完整日志。

Q477：MiCA是否允许与外部交易所对接API？

答：允许，但须：

  • 对接交易所为MiCA合规或有等效牌照；

  • 建立API权限隔离、访问频控、安全认证等机制；

  • 与外部交易所签订《接口责任划分协议》。

BoL可能要求对接交易所的AML政策摘要与系统审计报告。

Q478：MiCA是否允许提供杠杆或保证金服务？

答：MiCA本身不直接规范杠杆交易，但若涉及衍生品或杠杆工具，需额外满足：

  • 欧盟《金融工具市场法规》（MiFID II）的授权与限制；

  • 须取得附加许可或与持MiFID牌照机构合作提供；

  • 杠杆比例、清算机制、风险提示必须充分披露。

若无MiFID II授权，不建议开展杠杆或期货类服务。

Q479：MiCA平台是否必须提供客户资金隔离账户？

答：是，客户资产必须与公司自有资产隔离：

  • 客户资产专户需与平台营运账户完全分离；

  • 建议通过“客户资金信托账户”或“受监管托管人”方式持有；

  • 所有客户交易记录应与账户余额对应无误。

系统应每日生成客户资金对账报告，供审计查阅。

Q480：是否可在MiCA牌照获批前开展业务？

答：不可以。MiCA明确禁止在未获牌前提供加密资产服务，违反者将：

  • 被处以行政罚款（最高€5,000,000）；

  • 拒绝未来MiCA申请资格；

  • 纳入欧盟“高风险市场行为者”名单，影响其他欧盟业务审批。

可在申请期间完成系统搭建与内测，但不得对外正式开放运营。

Q481：MiCA是否允许设立分公司运营特定业务模块？

答：允许设立分公司（branch），但：

  • 主牌照主体仍须为立陶宛UAB；

  • 分公司需备案其功能范围、内部管理、人员架构；

  • 若分公司位于其他欧盟国家，须同时满足该成员国的本地监管对接流程（passporting）。

不建议在初始申请阶段就启用多地分支，增加审批复杂度。

Q482：是否可以引入非欧盟国家的法人作为股东？

答：可以，但需满足以下条件：

  • 股东提供全面KYC与资金来源说明；

  • 出具其注册地法律意见函（说明可作为控股方）；

  • 若来自高风险国家（FATF名单），可能需额外审查。

高风险国股东需特别说明资金合规路径，并提交合规顾问审阅报告。

Q483：MiCA牌照是否可用于提供“加密资产借贷服务”？

答：可提供借贷服务，但仅限：

  • 借贷合同清晰明示双方责任；

  • 有充分风险揭示；

  • 若涉及利率或清算机制，平台必须披露算法规则、违约处理方式；

  • BoL会重点审查资产回收机制。

不得提供非法集资、变相吸收公众存款型的“理财型借贷”。

Q484：MiCA牌照申请过程中是否需进行沙盒测试？

答：非强制，但建议申请人：

  • 启动自主内部沙盒系统，模拟关键流程；

  • 与立陶宛监管的金融创新办公室对接（Innovation Hub）；

  • 提供测试报告或沙盒运行总结作为补充材料。

若未来EU层面开启MiCA监管沙盒试点，有提前参与经验将具竞争优势。

Q485：MiCA平台是否可以引入自动化投资策略？（如机器人顾问）

答：可以，但须：

  • 披露所有算法逻辑原理；

  • 提供人工介入机制（override protocol）；

  • 对外清楚声明风险不由平台兜底。

自动化模型应附有风控阈值和人工审查机制，避免算法错误蔓延。

Q486：MiCA是否要求平台必须有风险控制委员会或内设风控官？

答：不强制设风险控制委员会，但平台需证明：

  • 有独立风控功能；

  • 日常监控由非业务部门负责；

  • 高风险操作需审批并记录。

大型平台建议设立内控委员会（ICC）或聘请合规顾问辅助风险监测。

Q487：申请MiCA时提交的“财务预测三年”要达到何种准确性？

答：MiCA不要求“盈利性”，但财务预测须：

  • 具合理性（符合市场逻辑、服务模型）；

  • 显示业务可持续（不依赖非法资助或对赌结构）；

  • 包含收入结构、成本结构、净利润估计与敏感性分析。

BoL关注预测的可执行性与配套资金支持，而非“营收最大化”。

Q488：MiCA是否适用于跨境稳定币清算业务？

答：适用，但需明确以下：

  • 是否发行资产参考型代币（ARTs），则须额外适用MiCA特定章节；

  • 是否提供清算服务、结算托管服务等，需要申请相应CASP服务类别；

  • 稳定币发行者还须满足额外资本金与储备义务。

跨境清算结构需在运营前取得ESMA+EBA联合批准。

Q489：MiCA是否允许平台引入“推荐返佣”模式？

答：允许，但需遵守：

  • 不得虚假宣传或误导投资者；

  • 返佣结构须公开透明、明示收益逻辑；

  • 所有推荐行为应记录于客户行为日志，并可追溯。

BoL关注该机制是否引发洗钱风险或市场操纵行为。

Q490：MiCA合规过程中是否可以使用开源系统或模板？

答：可以使用开源方案，但需满足以下条件：

  • 已被充分测试、支持权限控制与数据追踪；

  • 所有开源模块应由技术负责人审阅并出具风险评估；

  • 修改后的版本应封存代码版本并接受审计。

不建议使用未经审计或缺乏社区维护的“低质量”代码，避免被质疑技术不健全。

Q491：MiCA平台能否使用海外云服务商（如AWS、新加坡阿里云等）？

答：MiCA并不绝对禁止海外云服务，但必须满足：

  • 数据处理、客户敏感信息须存于EU境内；

  • 若使用海外云服务，需提交：

    • 数据跨境说明文件；

    • 数据主控权归属说明；

    • 灾备计划与数据加密机制；

  • 建议设本地镜像节点或采用欧盟认可的数据托管合作商（如 OVH、Hetzner）。

⚠️如核心数据不在欧盟，可能面临BoL拒批风险。

Q492：是否可以申请MiCA CASP牌照仅经营一种服务类型？

答：完全可以。申请MiCA牌照时：

  • 可选择1–10项服务类型中的任意一种或多种；

  • 每项服务类型有对应最低资本金与合规要求；

  • 初期可先申请一种服务类型，后续再申请变更或扩展。

示例：如仅申请“托管加密钱包”，资本金门槛为€125,000，业务聚焦更利于合规准备。

Q493：平台上线前是否必须完成所有系统测试？是否强制提交报告？

答：是，BoL明确要求：

  • 系统须完成至少一轮完整集成测试（UAT）；

  • 交易系统、钱包管理、风控系统均需有功能验证；

  • 建议提交“系统测试总结报告”作为申请材料补充。

系统稳定性是技术审查重点，建议提前2个月完成模拟上线演练。

Q494：MiCA是否对平台收费结构（佣金、滑点等）有特别限制？

答：MiCA不设硬性收费上限，但要求：

  • 所有费用标准需公开披露；

  • 客户下单前须明确告知费用组成；

  • 不得隐藏佣金、间接收费或进行价格操控。

BoL会重点查验平台“费率透明性政策”（Fee Transparency Policy）。

Q495：是否可通过股东借款方式注入注册资本？

答：不建议。MiCA对“实缴资本”有以下要求：

  • 须为实质性出资（现金+可追溯来源）；

  • 不可使用带有还款义务的借款；

  • 股东可进行增资，但资金须留存于公司账户并可随时调用。

若使用借款注资，BoL有权要求剔除该笔资金并拒绝核准。

Q496：申请MiCA期间是否可以“预营运”或“测试上线”？

答：不可公开对外营运，但可内部封测：

  • 可搭建“内部测试环境”（sandbox）用于演示；

  • 不得对真实客户提供服务；

  • 所有客户交互活动需等正式获批后才能启动。

部分项目为展示融资需求，会提供模拟Demo，但不得带有实际交易功能。

Q497：MiCA是否允许公司同时运营虚拟资产与传统证券业务？

答：允许，但须：

  • 明确业务边界、资金隔离、团队独立；

  • 传统证券业务须另持牌照（如欧盟MiFID II下的投资公司牌照）；

  • 不得将加密资产与证券资产混同处理。

若存在跨资产组合，平台需就合规边界出具法律意见函。

Q498：申请过程中公司结构是否允许变化（如董事辞职、转股等）？

答：原则上不允许中途变更，除非：

  • 变更具有合理解释（如不可抗力）；

  • 已向BoL提交变更说明、更新文件、股东决议等；

  • 全套资料须重新提交，可能导致审查周期重新计算。

建议申请期间保持管理层、股东结构稳定，否则将影响最终核准。

Q499：MiCA是否对加密资产的“估值方式”有明确规范？

答：MiCA要求平台：

  • 使用公允估值（fair value）原则；

  • 参考多家交易所市场价或第三方数据商（如CoinMarketCap、Kaiko）；

  • 不得使用自有平台单一报价作为估值标准。

对于非流通代币，建议使用第三方审计估值模型并定期更新估值机制。

Q500：是否需要设置客户资金保障机制（如存保制度、信托分隔）？

答：MiCA明确要求平台：

  • 分离客户资产与自有资产；

  • 客户资产托管账户不得用于抵押、质押或再投资；

  • 推荐使用银行托管、信托账户或多签控制结构；

  • 对客户资产遗失或失误，应有“赔偿基金”或“责任保险”。

若无客户资产保护措施，BoL可能要求平台出具额外担保。

Q501：MiCA申请是否允许外包KYC/AML服务？

答：允许在一定条件下外包：

  • 可委托合规外包商（如KYC服务商、AML软件提供商）；

  • 但主体责任仍由CASP持牌公司承担；

  • 必须签署正式合规外包协议（Outsourcing Agreement）；

  • BoL会要求申请时提供：

    • 外包供应商尽职调查文件；

    • 服务说明；

    • 数据权限划分；

    • 审核责任机制。

⚠️不可将MLRO职责完全外包，需保留公司内部的合规总负责人。

Q502：公司设立为“母公司+子公司”结构是否更适合MiCA申请？

答：可行，但需注意：

  • MiCA要求申请主体为欧盟境内法人，子公司可申请；

  • 控股母公司需出具股东支持声明（Shareholder Support Letter）；

  • 控股结构必须清晰、可穿透、无灰色信托或代持；

  • 建议对子公司注资达到资本金标准，并确保其为实质性运营实体。

常见结构为：开曼控股 + 立陶宛UAB营运公司。

Q503：MiCA对客户申诉处理有何最低标准？

答：必须具备以下机制：

  • 指定负责人员处理客户投诉；

  • 明确书面投诉流程与时间表（通常7–14个工作日回复）；

  • 投诉记录须保存5年以上；

  • 提供客户专属联系渠道（email/portal）；

  • 须向BoL年报中披露投诉统计数据。

建议附带《客户投诉处理政策》（Customer Complaint Handling Policy）一并申报。

Q504：MiCA是否允许平台提供收益型产品（如Staking、存币生息）？

答：视具体结构而定：

  • 若属于非担保收益型产品（如staking），平台需评估是否构成“投资产品”；

  • 若涉及收益承诺、利率协议，可能构成证券属性，应另持牌；

  • 需提交法律意见函说明该类产品不构成MiFID产品或集体投资计划。

建议审慎处理“固定收益+宣传”的产品包装，BoL对此极为敏感。

Q505：MiCA对平台营销行为是否设限？

答：是，MiCA及BoL要求：

  • 所有宣传内容必须准确、清晰、非误导；

  • 需具备营销审查机制，记录发布渠道和内容；

  • 禁止在宣传中暗示“无风险”、“保本”等；

  • 多语种宣传需保持一致性，中文/英文/立陶宛文不得偏差。

建议设立《营销合规审核制度》，并由合规官最终签署归档。

Q506：MiCA是否要求披露客户交易对手（counterparty）？

答：在以下情境下要求：

  • 若平台为撮合中介或做市商，须向客户披露交易对手身份或机制；

  • 如平台与关联方发生自营交易，应特别标注，并设立“防利益冲突政策”；

  • 所有撮合与报价机制须具“公平性测试”（Fair Execution Policy）。

客户须明确知晓其交易机制：是否对手盘、是否独立定价。

Q507：若系统因意外停服，如何向监管报告？

答：MiCA要求建立《重大运营事件报告机制》，包括：

  • 停服2小时以上，或影响交易/客户资产安全的，24小时内向BoL报告；

  • 内容应包括事件时间、原因、影响、处理措施；

  • 报告须附系统截图、通讯记录等证据。

建议同时设立灾备节点（DR site）并进行年检测试。

Q508：MiCA对是否允许DeFi平台申请CASP有何明确规定？

答：DeFi平台若具中心化运营主体，仍可申请MiCA CASP：

  • 若DeFi协议由某公司控制前端、智能合约升级权、API访问，则可视为合规运营主体；

  • 去中心化治理型DAO项目难以满足MiCA的法律实体要求；

  • 建议DeFi协议设立实体法人作为运营公司再行申请。

此类平台需特别提交“治理结构与权限说明文件”。

Q509：MiCA是否接受远程董事或跨境MLRO？

答：接受，但需：

  • 至少有一名董事或高级管理人员在立陶宛或欧盟内常驻；

  • 跨境MLRO可接受，但必须说明其如何实现日常监管、KYC审查、STR响应等；

  • 建议远程角色配合立陶宛本地运营人员形成混合团队。

建议在商业计划中列明人员“地理分布与值勤安排图”。

Q510：申请MiCA时必须具备法律顾问与审计师吗？

答：强烈建议具备，BoL在以下方面有明确要求：

  • 提交法律意见函（尤其涉及Token属性与产品分类）；

  • 指定独立审计机构负责每年审计财务报表；

  • 合规服务机构可代为协调，但法律与审计仍需由授权第三方完成。

MiCA申请往往需出具至少一份正式法律意见，建议由具欧盟金融合规经验律师起草。

Q511：CASP是否可以在多个国家设置分支机构或办公室？是否需要单独备案？

答：可以，但需注意以下合规要求：

  • 母公司为MiCA持牌CASP主体，可在其他欧盟国家设立分支或子公司；

  • 若设立“分公司（Branch）”，须进行ESMA登记备案（passporting流程）；

  • 若设立“子公司（Subsidiary）”，不自动享有MiCA护照权，可能另需许可；

  • 分支应遵守当地消费者保护、语言披露、KYC要求；

  • 各国监管可能要求其本地数据接入权限或合作机制。

建议在《商业计划书》中附带【跨国运营结构图】及【各分支合规责任划分表】。

Q512：MiCA对员工人数是否有最低要求？是否可以采用外包团队？

答：无硬性“员工人数”限制，但必须满足：

  • 公司架构中需列出：合规官（Compliance Officer）、MLRO、IT负责人、运营负责人等关键岗位；

  • 每个核心岗位须有人担任，不能空缺；

  • 可委托部分功能性岗位外包（如IT维护、KYC），但核心管理岗位不可外包；

  • BoL会查验是否为“壳结构”，如无真实人力、办公运营，牌照难获批。

建议设立基本团队规模为 5–10人，混合本地与远程运营人员。

Q513：MiCA是否支持跨平台流动性合作（如API订单聚合、共享流动性池）？

答：支持，但有以下前提：

  • 需确保客户指令执行的透明性与公平性；

  • 合作平台需具备合规资质（MiCA、EMI或受监管交易所）；

  • API对接方不得为未许可的第三方平台；

  • 所有撮合行为必须记录并可审计；

  • 需设立《外部流动性源合作政策》及《第三方接口安全测试报告》。

BoL对流动性来源安全性与客户资产保护高度敏感。

Q514：MiCA CASP平台是否允许提供借贷（Lending/Borrowing）服务？

答：借贷服务并不包含在MiCA CASP 10类服务中，属于灰色地带：

  • 若平台撮合加密资产贷款，应符合欧盟信贷法规或另持有EMI/银行牌照；

  • 提供利率衍生服务、质押借贷等，需评估是否触及MiFID II或CRD/CRR框架；

  • 建议提交法律意见函，明确此类产品不构成金融工具。

若涉及加密质押、借贷，请预留MiFID顾问结构。

Q515：MiCA是否允许平台对接NFT市场？NFT属于MiCA监管范围吗？

答：MiCA不直接监管非金融类NFT，但：

  • 若NFT具备可分割性、交易性、金融属性（如权益分红、交易撮合），可能被视为可替代代币（fungible）；

  • 若平台为NFT提供发行/交易/托管服务，BoL可能将其纳入监管；

  • 建议NFT项目附带资产分类意见函；

  • 若NFT交易功能嵌入至平台，应额外设立用户披露机制。

具金融属性的NFT项目未来可能被纳入MiCA或ESMA监管扩展范畴。

Q516：MiCA是否适用于加密游戏（GameFi）或元宇宙项目？

答：视项目类型而定：

  • 若GameFi或Metaverse中设有代币交易、兑换、转账、储值、撮合等功能，即可能触发MiCA；

  • 若平台为其他项目提供钱包托管/流动性兑换等服务，即为CASP活动；

  • 代币分发若带有“募资/发行/定价机制”，可能落入MiCA第5节发行监管条款。

GameFi平台建议从MiCA视角审查其“代币角色 + 平台功能 + 客户接触路径”。

Q517：MiCA持牌机构是否可以跨界拓展为电子货币机构（EMI）？是否需要另持牌？

答：必须另持牌：

  • MiCA CASP牌照仅允许提供加密资产相关服务；

  • 若平台提供客户资金收取、发放、储值卡、支付服务，需申请EMI或PI（Payment Institution）牌照；

  • 可采用双牌照结构：MiCA CASP + EMI（建议以两家UAB公司运营）；

  • 金融分工明确：传统支付 vs 加密服务。

BoL支持双牌照同步管理，但不可功能重叠或混用用户资金池。

Q518：是否可以先申请VASP过渡性牌照，再升级至MiCA？有何差异？

答：可以，但注意以下差异：

项目 立陶宛VASP（2024前） MiCA CASP（2025起）
审批机关 BoL商业部门 BoL金融市场监管局
服务范围 基础交易/钱包 10类完整CASP服务
跨境效力 不具护照权 可全欧盟护照通行
法律依据 本地反洗钱法 欧盟MiCA条例
资本金 无统一要求 €50K–€150K起
 

建议原VASP客户提前筹备过渡升级计划，避免监管真空期风险。

Q519：MiCA平台是否可以为企业客户提供托管账户服务？

答：可以，前提是：

  • 平台具备保管服务许可（CASP第1项）；

  • 企业客户需签署托管协议，明确权限、费用、访问方式；

  • 客户资产需与平台自有资产隔离保管；

  • 平台必须出具资产保管证明，并配合审计。

多数项目为项目方、发行方或基金设立“托管账户”以提升可信度。

Q520：MiCA牌照持有公司是否可以为他人提供白标平台服务（White Label）？

答：理论上允许，但有高度合规风险：

  • 若白标合作方未获MiCA授权，即构成非法提供服务；

  • 持牌方仍对客户合规、交易行为承担最终责任；

  • 建议仅将技术层白标，而客户KYC、资产托管、交易对手等仍由持牌方主导；

  • 合同需清晰界定风险、责任、利润分成、系统边界。

建议附带《白标平台合规责任分配图解》，并提前通知BoL该等合作安排。

Q521：平台如何证明其冷钱包的私钥控制权仅由授权人员掌握？

答：MiCA合规要求平台建立清晰的私钥控制制度，包括：

  • 指定授权私钥保管人员名单（不少于2人）；

  • 使用多重签名（multi-sig）或门限签名（threshold signing）机制；

  • 提供冷钱包权限控制图（可附系统结构图）；

  • 建立“密钥生命周期管理政策”，包括生成、备份、轮换、注销等流程；

  • 向BoL备案冷钱包托管策略。

BoL在监管访问时会要求演示“签名流程”并检查权限日志。

Q522：MiCA是否允许平台进行“自营交易”？有何限制？

答：MiCA原则上不鼓励“无透明披露”的自营交易：

  • 平台如涉及自营行为（proprietary trading），需在商业模式中显著披露；

  • 须设立防利益冲突政策（Conflict of Interest Policy）；

  • 若同时撮合客户订单与自营订单，必须区分订单簿；

  • 客户须明确知悉平台的撮合逻辑。

建议避开“同池撮合”机制，否则易触MiFID或市场操纵红线。

Q523：MiCA是否允许使用链上KYC服务或区块链身份验证系统？

答：可接受，但需满足：

  • KYC服务提供方须符合欧盟AML标准（第6号指令要求）；

  • 区块链身份系统需具备数据准确性、实时更新、GDPR合规能力；

  • 若使用“链上评分”、“声誉系统”等，需有人工复核补充程序；

  • 不得完全依赖链上验证进行身份决策。

强烈建议在链上身份系统外保留传统KYC核查接口。

Q524：平台是否可以提供稳定币（如USDT）兑法币（如EUR）赎回服务？

答：可以，但前提为：

  • 平台持有CASP第7项：兑换加密资产与法币服务许可；

  • 需与有法币出入金资质的银行或EMI合作；

  • 应披露稳定币发行人（如Tether）的风险与储备情况；

  • 若平台直接参与USDT清算通道（如OMNI、TRC20），需具备对应冷/热钱包系统接入证明。

对客户而言，该服务仍属“加密→法币”路径，MiCA高度关注AML、Fiat Gateway安全性。

Q525：MiCA是否支持代币化现实资产（RWA）的服务提供商？例如房地产或债券代币化。

答：支持，但属于混合监管领域：

  • 若RWA代币具备金融属性（如分红、本金返还、收益权），可能落入MiFID II、Prospectus Regulation监管范围；

  • 平台必须出具RWA代币的法律意见，说明其为可交易型资产或证券型资产；

  • 应披露底层资产的评估报告、托管协议、清算路径等；

  • 发行人应具备相应资质，如受监管基金、信托、托管机构。

MiCA对“虚拟资产 vs 金融工具”的界限审查极严，RWA项目建议联合MiFID合规顾问先行审查。

Q526：MiCA是否规定了客户资产的强制分离机制（segregation）？

答：是的，客户资产必须与平台自有资产严格隔离：

  • 必须设置“客户加密资产账户”与“平台运营账户”分离；

  • 同样适用于法币资金（如客户EUR资金与平台运营资金分开）；

  • 需出具客户资产分离政策（Client Asset Segregation Policy）；

  • BoL可随时要求审计资产分离报告与系统权限隔离图。

未能清晰隔离客户资产属MiCA高风险违规行为，轻则整改，重则吊销牌照。

Q527：平台是否可以设置“转介人机制”或代理销售代币服务？

答：允许，但必须设置以下机制：

  • 转介人（introducer）不得进行合规审查或代收款；

  • 所有最终KYC、资产托管、交易撮合，必须由持牌CASP完成；

  • 应签署正式《转介协议》并申报其身份至BoL；

  • 禁止夸大宣传或误导性销售话术。

建议将转介佣金制度纳入《外部销售行为规范》。

Q528：MiCA牌照下，是否必须每年更新商业计划书或政策文件？

答：是的，以下文件必须至少每年更新一次：

  • 商业计划书（Business Plan）；

  • 风险评估报告（Risk Assessment）；

  • 合规审查制度（Compliance Manual）；

  • 客户适当性政策（Client Suitability Policy）；

  • IT安全政策、钱包管理策略。

BoL每年均会开展持续监管审核，未更新文件可能被要求限期整改。

Q529：平台是否可以只持有部分CASP服务类别的牌照？

答：可以，MiCA牌照具模块化授权模式：

  • 可单独申请任意一项或多项CASP服务（共10项）；

  • 每项服务均需提交针对性商业说明与制度文件；

  • 若后续新增服务，需补充申请及修改资本金结构；

  • 建议优先申请“第1、2、4、7类”等常规业务服务。

不建议一次申请全部10项，易导致审查周期延长及审批难度提升。

Q530：MiCA是否有监管沙盒机制？CASP可否申请试点？

答：有，欧盟支持“数字金融监管沙盒”（Digital Finance Sandbox）：

  • 由ESMA/EBA/EIOPA与本地监管（如BoL）联合推动；

  • 适用于新型加密产品、创新服务、复杂合规结构测试；

  • 平台可提交《沙盒参与申请表 + 技术说明 + 风险评估》；

  • 通过后可在监管保护下小范围上线试点功能；

  • 沙盒期结束后需补充正式MiCA牌照。

建议将高风险产品（如收益产品、链上借贷）优先在沙盒中试点。

Q531：MiCA牌照公司是否可以参与链上DeFi协议或质押？是否会构成监管问题？

答：MiCA对DeFi的直接规定尚不完善，但监管预期如下：

  • 如平台运营方与DeFi协议存在控制关系（如DAO创始成员、管理员、代码更新权限者），视为“中心化活动”，适用MiCA；

  • 若CASP为客户提供链上质押服务，属于资产管理或托管行为，需具备第1类或第4类服务授权；

  • 如仅为技术接入（提供API桥接、前端入口），应在用户协议中声明“风险自负”；

  • BoL会核查是否绕过中心化监管、掩盖责任主体或存在实质控制人未申报情形。

若涉及链上DeFi交互，建议附加《链上协议接入透明披露指引》，并就智能合约风险作专门风险警告。

Q532：MiCA是否允许与其他MiCA持牌平台之间进行跨平台钱包打通（例如内部“ClearNet”）？

答：允许，但需确保：

  • 双方皆为注册MiCA CASP持牌公司；

  • 建立**“跨平台转账记录机制”**，可追踪客户身份、转账动因、反洗钱痕迹；

  • 需对打通的双方账户设置标签及权限审计功能；

  • 披露对接目的（如流动性管理、客户资金划拨、资产互通）；

  • 必须由法务和合规人员签署《平台互联责任备忘录》。

实质是“钱包互通”方案，监管重点在于AML可视性与系统安全同步性。

Q533：MiCA牌照机构是否可以发行自身平台币（如utility token）？是否需要双重许可？

答：可以，但需满足以下条件：

  • 平台币不得具备“储值承诺”、“回购机制”或“固定兑换比率”等特征，否则构成“电子货币代币”（EMT）；

  • 若平台币用于手续费抵扣、参与质押、治理等，建议通过独立白皮书注册流程（Article 4）；

  • 若附带权益或募资成分，需参照“可替代代币”监管路径，提供法律意见函说明非证券化特征；

  • 自发代币若在平台上交易，需额外披露潜在“利益冲突”风险。

若平台币涉及增值回购，建议另设发行载体并与交易平台职责隔离。

Q534：MiCA是否要求客户交易活动可“溯源”？平台如何保证审计透明度？

答：强制要求客户交易活动全链下+链上留痕，包括：

  • 交易日志需记录：客户身份编号、订单时间、匹配时间、交易对、对手方、手续费；

  • 链上交易应保留交易哈希+钱包地址+链上标签；

  • 平台需具备至少5年审计留存机制，并能按监管要求输出审计报表；

  • 建议使用“只读合规API”或“审计镜像节点”实时同步平台活动给BoL监管团队。

使用外部审计系统（如Chainalysis、Elliptic）可大幅提升透明度与信任度。

Q535：MiCA持牌平台是否可以发行或销售“证券型代币”？是否必须同步MiFID授权？

答：若代币构成证券型代币（Security Token），则：

  • 不受MiCA直接监管，需转向MiFID II、Prospectus Regulation、CSRD等法律框架；

  • 若平台进行销售、撮合、交易撮合，即构成“投资服务”，需同时取得MiFID牌照；

  • 如只提供托管服务或技术转让，可豁免部分要求，但仍需申报；

  • 多数平台采取双主体结构：MiCA CASP公司+MiFID授权券商公司，共同承接业务。

若计划进入STO市场，需重新编制《商业计划书（金融工具专用版）》。

Q536：MiCA是否允许使用“冷+热钱包混合方案”？监管倾向如何？

答：允许使用冷热钱包混合方案，但需满足：

  • 客户资产中的90%以上应保存在冷钱包中；

  • 热钱包仅保留为满足流动性日常需求的资金部分（如不超过10%）；

  • 冷钱包必须为多签、物理隔离、私钥分层存储；

  • 热钱包需接入风控监控系统，并每日出具转出限额记录；

  • 整体钱包策略应形成《资产托管与钱包管理政策》向BoL备案。

若平台曾发生过热钱包被盗事件，可能被要求临时关闭该接口。

Q537：客户进行OTC交易是否纳入MiCA监管范围？是否需要特别制度支持？

答：属于MiCA范围内交易类型之一，监管要求包括：

  • OTC交易需通过平台合规系统备案，不得私下撮合或绕平台下单；

  • 应建立《大宗交易政策》：设置最小交易量阈值、审核机制、定价机制；

  • 需要独立生成交易记录、反洗钱记录、录音或合规说明文件；

  • 须向客户披露其非市场撮合风险及可能溢价或折价现象。

建议OTC模块使用合规自动撮合引擎，避免纯手工操作带来的合规盲区。

Q538：MiCA CASP平台如何满足“公平定价”义务？需提交哪些支持文件？

答：MiCA要求平台提供“透明、无歧视的定价机制”，包括：

  • 建立《订单撮合规则》和《费率机制披露制度》；

  • 显示订单簿深度（如买一、卖一、量价分布）；

  • 披露手续费计算逻辑（Maker/Taker机制、滑点等）；

  • 提供合理的市场比较机制（如参考CoinMarketCap或交易所均价）；

  • 每季度提交“费率与流动性透明度报告”。

若定价机制涉及算法撮合，BoL可能要求查看模型文档与源代码摘要。

Q539：平台是否可设立分等级客户KYC制度？如何构建KYC分级模型？

答：允许分级KYC（risk-based approach），建议如下结构：

等级 用户类型 核查程度
L1 小额用户 基本身份（姓名、出生日期、邮箱）
L2 中额用户 身份证+自拍验证+地址证明
L3 高净值客户 全部资料+来源证明+资产评估
L4 企业或机构账户 注册文件、董事KYC、UBO调查、W8BEN

  • 不同等级设定不同额度、交易权限；

  • 风险评级与KYC等级需挂钩，确保动态调整；

  • 建议使用eID、Liveness检测、PEP数据库等工具加强验证。

必须设有“高风险客户强化核查流程”，并配备定期回访机制。

Q540：是否必须设立“交易异常行为识别机制”？应包含哪些关键指标？

答：MiCA要求平台建立自动识别机制识别潜在非法行为，包括但不限于：

  • 高频交易触发；

  • 自买自卖（wash trading）；

  • 多账户对敲；

  • 非常规时段大额转账；

  • 地址快速换手、黑名单交互行为。

关键指标建议包括：

  • TAT（Time to Alert）：系统从识别到警告的时间；

  • 行为对比分数（如历史交易偏离指数）；

  • IP地理跳变频率；

  • 钱包标签变更记录；

  • 需设置合规人员审核阈值，并保留日志。

推荐使用机器学习模型（如Random Forest或Anomaly Detection）提升精准识别率。

Q541：MiCA是否接受AI驱动的风险评估系统？监管机构有何要求？

答：MiCA监管框架不禁止AI系统，但对AI使用需满足以下合规要求：

  • 所有AI算法用于KYC、AML、市场监测等必须“可解释”（explainable）；

  • 须向监管机构提交《AI系统工作说明书》（含算法原理、训练数据、误判率）；

  • 禁止使用黑箱模型（如无法输出模型逻辑路径的深度网络）；

  • 必须设立人工复审机制，避免机器判断独断执行（如账户冻结）；

  • 强烈建议使用“可溯源AI”结构，并保留日志 ≥5年。

推荐构建“AI+人工双层验证”架构，用于高风险用户筛查与交易异常监测。

Q542：是否可以通过其他欧盟国家的MiCA牌照进行跨境服务？如何申报？

答：可以，MiCA引入欧盟单一护照机制（passporting）：

  • 持有立陶宛BoL核发的MiCA牌照后，可向其他EEA国家开展服务；

  • 需提交《跨境服务意向通知》（Notification of Cross-border Activities）；

  • 呈报内容包括：拟开展服务内容、目标国家、客户接触渠道、合规安排；

  • 无需重复申请牌照，但如当地有增设性监管要求，仍需遵守。

建议提前在《商业计划书》中注明passporting意向，便于BoL审查。

Q543：若平台开展代币销售活动（如IEO/IDO），是否构成MiCA下的发行义务？

答：构成，具体情况如下：

  • 若平台为项目方代为销售代币，视同“crypto-asset offering”行为；

  • 平台需承担《白皮书审查责任》与“适当性评估义务”；

  • 项目代币需由平台协助申报白皮书至监管机构；

  • 若涉及投资承诺或财务收益，则可能转为EMT或ART监管范畴。

建议建立IEO审核委员会，配合《代币筛选与上架政策》进行事前评估。

Q544：MiCA平台能否开设“子钱包”（sub-wallet）为客户配置不同策略账户？

答：允许设立，但应具备以下制度保障：

  • 子钱包之间需有明确的内部权限边界与资金隔离机制；

  • 所有子钱包活动仍应汇总到客户主KYC信息之下；

  • 若子钱包具独立策略功能，应设立“风险揭示机制”；

  • 平台应可实现客户自主查看每个子钱包的资产和风险分布。

建议附设“客户投资偏好设置问卷”，匹配子钱包产品选择。

Q545：MiCA是否对平台员工的合规培训有硬性规定？需频率与内容为何？

答：有，MiCA要求所有员工应定期接受以下合规培训：

类型 频率 内容要求
AML/KYC培训 至少每年1次 含客户尽调、STR识别、风险评分
IT安全与数据保护 每年更新 GDPR、系统权限、冷钱包操作
虚拟资产市场操守 每半年1次 包括市场操纵、交易合规
案例学习与模拟应对 不定期（推荐季） 包括历史合规事件解析、应对流程演练
 

建议保留培训出勤记录、考试报告与内容教材，作为监管抽查备档资料。

Q546：如何界定MiCA下的“自营交易”和“客户交易”？监管机构如何判定？

答：MiCA下定义如下：

  • 自营交易（Proprietary Trading）：平台为自身资产进行买卖，或使用平台资产参与撮合行为；

  • 客户交易（Client Transaction）：平台纯撮合或作为中介撮合客户之间的订单。

⚠️ 若平台自营账户与客户账户无隔离、频繁对敲，则可能被视为操纵市场。

应编制《自营交易政策》并向BoL说明对自营行为的识别、隔离和限制机制。

Q547：MiCA是否允许设立VIP客户方案（如大户免手续费）？是否需要公平披露？

答：允许，但必须满足以下条件：

  • 制度化VIP客户标准：如交易量、资产量、日均活跃；

  • 提供VIP等级须在用户协议中完整披露；

  • 不得以不透明方式变更用户等级；

  • 须确保一般客户不受歧视性限制（如撮合优先级一致）。

建议设立《客户等级管理制度》并附透明升级标准、等级适配权益。

Q548：MiCA牌照下平台是否可以设立“教育账户”或“虚拟模拟账户”？是否需纳入监管？

答：可以设立，前提是：

  • 明确标注“仅供学习使用”或“非真实资金”；

  • 不得用于募集资金或误导客户投资；

  • 用户在平台注册时应签署模拟账户使用声明；

  • 所有模拟交易数据需与实盘系统隔离，不可混用。

若平台通过模拟账户引流转化为真实交易，应设置清晰的“入金转化流程提示”。

Q549：MiCA是否要求交易平台建立“市场监测团队”？职责与架构如何设定？

答：强烈建议设立独立市场监控职能团队，承担以下职责：

  • 日常交易行为数据分析与市场异常识别；

  • 与合规、风控、IT对接，评估潜在违规交易；

  • 参与STR提交与内部合规会议；

  • 担任白皮书审核、代币上架建议角色。

架构建议为：市场监测主管 + 1–3名数据分析师 + 合规代表 + 技术支援接口人员。

Q550：平台系统是否必须具备“交易回溯”与“链上同步接口”？应保存多久？

答：MiCA对交易系统提出明确备查与同步要求：

  • 所有交易必须可追溯，包括订单路径、签名时间、撮合源头；

  • 与链上交易事件同步（如ERC-20转账、地址匹配）；

  • 建议设立“链下链上映射数据库”；

  • 所有数据必须保存至少5年，高风险账户建议保存7年以上；

  • 应具备“交易查询系统”供合规人员随时调用记录。

建议平台使用事件日志自动归档系统，增强监管应对能力。

Q551：MiCA下是否允许提供杠杆（Leverage）或保证金（Margin）交易？

答：MiCA监管框架中未直接授权杠杆交易为标准CASP服务，实际应符合以下条件：

  • 若提供杠杆或保证金功能，平台须向BoL额外备案《衍生工具交易风险说明》；

  • 须披露杠杆比例（如1x/3x/10x），并设置强平机制；

  • 须对用户进行适当性测试，确保其了解杠杆风险；

  • 若杠杆资产构成衍生产品，则可能触及MiFID II管辖。

建议：如平台涉及杠杆，建议分拆为“CASP + 受监管投资公司”双结构或限制于专业投资者。

Q552：MiCA是否禁止平台发行自己的平台币（如交易所代币）？

答：未禁止，但需满足严格前置条件：

  • 平台币若可流通并具备投资价值（如回购、手续费抵扣、分红），视为MiCA意义下的加密资产（crypto-assets）；

  • 必须向BoL递交完整的白皮书，内容含经济模型、治理机制、风险因素等；

  • 平台不得使用客户资产操纵平台币价格；

  • 若平台币承担清算或支付功能，可能被重新分类为EMT或ART，需持牌发行。

实操建议：将平台币归类为“功能型积分”并限制交易流通可降低监管敏感性。

Q553：平台是否可以为客户提供“结构性产品”或“打包资产篮子”？

答：可以，但需满足以下条件：

  • 产品成分（如多个代币组合、时间锁定机制）需在发行前获得BoL认可；

  • 须提供产品说明书、风险说明与回报结构模型；

  • 若包含收益承诺或本金保护，易被视为MiFID投资产品；

  • 建议向专业投资者开放，零售客户需额外适当性评估。

建议构建《结构化虚拟资产品质控制流程》，每款产品单独归档。

Q554：MiCA是否允许将NFT纳入平台交易范围？

答：允许，但仅限于非金融化NFT：

  • 若NFT为“唯一标识数字商品”或艺术品收藏品，通常不属于MiCA加密资产定义；

  • 若NFT具备分割性、流动性或投资属性（如GameFi土地、分红权、打金券），则可能被视为MiCA监管对象；

  • 平台应出具《NFT属性判定报告》说明其是否构成加密资产或证券型代币；

  • 必须披露NFT智能合约源代码与稀缺性算法设计。

不建议平台允许“碎片化NFT（F-NFT）”直接交易，否则极易触及MiFID或基金监管。

Q555：平台如何应对链上治理代币的“协议升级”或“硬分叉”？监管有何要求？

答：MiCA要求平台建立“协议变更管理制度”：

  • 当链上治理导致协议参数变更或硬分叉时，平台应设立应急响应机制；

  • 包括冻结相关资产交易、发出变更通知、技术兼容性分析；

  • 须评估是否存在客户资产损失或版本兼容风险；

  • 向BoL报备《影响评估报告》，如构成重大变更，应向客户公开披露。

推荐每季度对所支持链上资产进行版本审查并记录版本号及合约状态。

Q556：MiCA对跨境客户是否有额外申报或监管要求？如亚洲或美洲用户？

答：有以下要求：

  • 平台必须评估其服务是否触达欧盟以外用户；

  • 若主动招揽第三国用户（如提供服务界面、客服或广告），可能须遵守该国监管；

  • 建议设立《第三国客户识别与控制策略》，包括：地域IP识别、电话/语言识别；

  • 对于高风险国家（如FATF灰名单），应加强客户尽职调查与交易审查。

平台可设定“禁止访问名单（IP Block List）”避免违反境外合规规定。

Q557：是否可以设立“收益型产品”或“定期锁仓奖励机制”？

答：可以，但监管重点在于是否构成金融工具或证券：

  • 若产品含固定收益率或回本保证，极可能被重分类为证券；

  • 必须进行产品风险评级与客户适当性测试；

  • 建议收益来源透明，切勿使用“复投”模型或“拉新奖励”；

  • 平台需向BoL提交《收益型产品申报说明》。

不可称为“理财”、“托管增值”等，避免涉嫌变相集资。

Q558：是否可以接入第三方DeFi协议，如借贷协议或AMM？MiCA有何立场？

答：MiCA对此持高度谨慎态度：

  • 若平台为客户提供链上DeFi协议入口，视为“结构性交易服务”，应持牌且需承担全部风险；

  • DeFi协议必须经过智能合约审计，具备治理机制；

  • 不可将客户资产直接注入不可控的DeFi池中；

  • 须披露DeFi协议来源、智能合约逻辑、过去攻击记录等。

最佳做法是模拟DeFi机制于中心化平台内部，避免合规不确定性。

Q559：平台是否需要为客户生成“年度报表”或“交易流水”？内容应包含哪些？

答：MiCA要求平台为每位客户至少提供年度交易与资产报表，包括：

  • 年度资产余额快照（各类加密资产及法币）；

  • 所有交易流水记录（买入、卖出、充值、提现）；

  • 费用明细与手续费开支；

  • 客户账户活动审计摘要；

  • 适用于CRS/税务申报用途的年度总结。

建议采用PDF或电子签名PDF，并保留原始数据格式供监管稽核。

Q560：MiCA是否要求平台具备对客户交易行为的“可疑模式识别机制”？

答：是的，属于反洗钱合规义务核心部分：

  • 平台必须设定交易行为监控系统，包括：

    • 高频交易监测

    • 快进快出行为识别

    • 地址异常转移（新注册即大额出金）

    • KYC不符交易类型（风险模型）

  • 每月需输出异常行为报告并由MLRO审阅；

  • 可结合AI算法与规则引擎（如JMLT规则、链上路径分析）；

STR（可疑交易报告）必须在怀疑形成后24小时内递交主管机关（如BoL或FIU）。

Q561：MiCA是否允许平台开展自动策略交易（如量化程序化交易）服务？

答：允许，但需满足以下条件：

  • 平台若提供策略交易工具或算法交易接口（API），应设定使用门槛；

  • 用户使用前须签署《自动化交易风险揭示书》；

  • 算法可执行交易行为不得绕过风控/限价机制；

  • 对频繁调用API者，平台应设限频率和订单量，防止系统压力或市场操纵；

  • 平台应保存策略调用日志 ≥5年，供事后合规稽核。

建议设立“策略交易专用账户”，以便与普通账户逻辑区分管理。

Q562：MiCA是否允许用户进行场外OTC交易？是否纳入监管？

答：MiCA允许合规前提下开展OTC交易：

  • OTC交易应在平台内撮合或备案，防止绕监管执行；

  • 平台需具备OTC对手方尽调机制与可疑交易监控能力；

  • 建议设置OTC交易最小门槛（如等值10,000 EUR），防止滥用；

  • 平台应提供OTC订单确认函、KYC配对说明等记录；

  • 所有OTC交易须与平台主账户系统对账，避免脱链操作。

平台不得作为买方/卖方双边撮合者参与自营，否则易构成市场干预。

Q563：MiCA是否接受云服务（如AWS、Azure）作为平台IT托管基础设施？有何要求？

答：接受，但平台需：

  • 提交《系统托管说明书》，列明使用云服务商详情；

  • 明确说明数据主控权仍由平台持有；

  • 云端服务器必须设于EEA境内（或通过数据合规豁免说明）；

  • 加密资产私钥、KYC信息等不得仅存于第三方云，无多重备份；

  • 云服务合同应包含数据可用性、灾备能力、突发事件响应条款。

建议结合私有云+公有云混合部署方式，确保可控性与弹性。

Q564：MiCA是否对平台代币资产储备设定比例要求？如EMT/ART托底资产？

答：是的，特别适用于：

  • EMT（电子货币代币）：需100%储备+日度核对；

  • ART（资产参考代币）：需高相关性资产储备且每日估值；

  • 平台应设立独立托管账户或与第三方保管人签署托管协议；

  • 储备资产种类须为低风险可流动品（如欧元、国债、银行存款）；

  • 每月应出具第三方审计证明储备充足性，报送BoL备案。

不得使用自身平台币或高波动性加密资产作为储备底仓。

Q565：MiCA下的“市场操纵”行为包括哪些？平台如何防范？

答：MiCA采用类似欧盟《市场滥用条例》（MAR）框架，定义市场操纵行为包括：

  • 虚假订单（如拉单不成交、对敲）；

  • 涉嫌“做市误导”（wash trading）；

  • 散布虚假信息操纵价格（如Telegram群造谣）；

  • 事前知悉项目利好并提前交易（内幕交易）；

  • 平台“暗箱上币”并控盘拉升/砸盘。

平台应设定：

  • 交易行为监控系统；

  • 交易数据异常告警机制；

  • 合规审查委员会复审项目及行为；

  • 针对交易员与员工设定“锁仓期”“不得自营账户”等限制。

Q566：MiCA是否对平台的多语言网站、白皮书翻译版本有强制要求？

答：有以下规定：

  • 向EEA国家公开服务的平台，其白皮书必须至少提供英文版；

  • 若面向特定国家/客户提供服务（如立陶宛、法国、西班牙），应提供对应语种的翻译版本；

  • 白皮书翻译内容应与原文一致，建议由专业翻译机构出具“译文一致性声明”；

  • 网站多语言内容也应同步合规更新，特别是风险揭示和使用条款。

不一致版本可能引发误导宣传、合规责任及客户投诉，建议定期审阅各语言版本一致性。

Q567：平台是否可以接受DAO（去中心化自治组织）作为客户主体？MiCA怎么看？

答：可接受，但需：

  • DAO必须有法定代表人或签署代理人（如基金会）；

  • 应提交治理结构说明、智能合约控制权说明；

  • 提供组织章程或治理协议，并解释投票机制；

  • 对DAO主钱包执行严格KYC/KYB，识别实际控制人；

  • 平台需向BoL说明为何认定该DAO“可识别、可控、可评估风险”。

实操中建议DAO设立法律代理机构（如开曼基金会）完成主体识别与签约。

Q568：MiCA是否接受平台以“收益分享”形式支付顾问费、BD费？

答：允许但应纳入合规审查：

  • 须披露与顾问/BD/推广方之间的激励机制；

  • 分享比例、考核机制、结算周期应书面列明；

  • 禁止设定“拉人头收益结构”或多层裂变奖励；

  • 所有付款应通过银行或平台钱包链上明示可追溯；

  • 若顾问提供交易建议，应持MiFID许可。

推荐设立《外部合作方激励政策》，并提交BoL审查备查。

Q569：MiCA是否要求客户资产与平台资产完全隔离？如何做到？

答：是，属于MiCA核心义务之一：

  • 所有客户资产必须存放于隔离账户（segregated account）；

  • 可采取链上独立地址（每人一地址）或子钱包识别系统；

  • 平台不得挪用客户资产用作自营、抵押或借贷；

  • 应每日核对客户余额与系统总账匹配；

  • 建议将托管权交由独立第三方（如欧盟保管银行或专业加密托管人）。

平台自有资产、收益与客户资产分账应具“总账–子账”结构清晰记录。

Q570：MiCA是否支持平台同时开展支付业务或卡产品？如何实现合规？

答：支持，但需取得额外牌照：

  • 若平台提供欧元充值、代扣、银行卡绑定、发卡业务，则构成支付机构服务（需PSD2或EMI牌照）；

  • 可与第三方EMI合作，由其发卡并承接结算；

  • 需与合作方签署《三方协议》明确客户数据与资产权属；

  • 所有支付服务必须符合GDPR与KYC要求；

  • 发卡服务应受欧洲央行或当地央行监管。

推荐构建“MiCA平台 + EMI支付模块”双结构，平台聚焦资产管理与交易，支付交由合规持牌方。

Q571：MiCA牌照下是否可支持客户的“多币种钱包”功能？监管有何要求？

答：可以支持，但平台须满足如下监管合规要求：

  • 每一种币种（无论是加密资产、EMT或ART）都应在系统中独立建账；

  • 所有币种资产须可独立核算、出具余额证明，并与系统总账一致；

  • 若某币种为MiCA下受规管产品（如EMT/ART），则其储备、白皮书等亦需单独披露；

  • 跨币种自动转换（如BTC自动兑换USDT）须设置清晰的汇率来源和转换授权机制；

  • 强烈建议将多币种钱包结构与冷/热钱包管理机制同步设计。

推荐在用户界面显著标注每种资产的性质（证券型 / 稳定币 / 普通代币），避免混淆投资判断。

Q572：MiCA监管下是否支持平台引入“收益共享型代币”（Revenue-Sharing Tokens）？

答：MiCA不直接禁止此类代币发行，但此类产品存在高度被归类为证券型代币（Security-like crypto-asset）的可能：

  • 若代币持有人可基于其持币比例获得平台收入分成或利润回报，则具备证券要素；

  • 此类代币应按《证券法》及MiFID II框架接受额外审查与合规披露义务；

  • 通常需提交金融工具白皮书、进行投资者适当性评估、并设立锁仓与二级市场限制。

建议此类设计结合立陶宛FSA或欧盟ESMA提前咨询意见，避免触发监管雷区。

Q573：在MiCA架构下是否可以开展Launchpad业务？需要额外合规吗？

答：可以开展，但必须具备以下合规控制机制：

  • 所有参与Launchpad项目代币需完成MiCA下的白皮书备案；

  • 投资者需完成高级KYC、适当性测试及风险评估；

  • 平台应公示项目尽调报告，包括技术风险、代币分配、治理机制等；

  • 禁止“盲盒式”销售或隐藏分配机制；

  • Launchpad销售记录、投资分布、收入应完整保留 ≥5年。

建议设立独立审核委员会，对上线项目进行合规评估并出具风险评级。

Q574：MiCA是否要求对智能合约进行代码审计？是否必须第三方审计？

答：强烈建议，尤其是下列情形应由独立第三方完成审计：

  • 所有托管资产、交易撮合、链上资产桥接类智能合约；

  • 用户资产存取控制类（如冷钱包签名逻辑）；

  • 项目方发行代币涉及合约逻辑分发者；

  • 涉及资产清算、赎回、稳定锚定等操作逻辑的代码。

监管机构不强制特定审计机构，但若审计报告出自无资质机构，可能无法获得监管认可。

推荐使用具有欧盟执业记录的智能合约安全机构，并提供完整英文审计报告 + 改进说明。

Q575：平台是否必须对链上地址标注风险等级？是否需接入链上数据服务？

答：MiCA并未强制规定风险标注义务，但以下措施属合规最佳实践：

  • 建议接入链上数据分析服务（如Chainalysis、Elliptic、ScoreChain）；

  • 对用户充值地址来源、交易对手、频繁互动地址进行打分并记录；

  • 高风险地址（如DPRK相关、Sanction List）应自动拦截并生成STR报告；

  • 建议设置自动识别 + 手动复审结合机制，确保审慎性。

链上地址监控建议与AML/KYC政策同步更新，并作为客户风险评分的一部分。

Q576：是否可以为企业客户设立多用户访问权限（如管理员/财务/操作员）？如何配置合规？

答：允许设置，但平台应满足以下安全与合规要求：

  • 多角色用户应支持独立登录+权限控制（RBAC模型）；

  • 高权限用户如“提款授权人”应需二级验证（如OTP + 冷钱包签名人）；

  • 所有操作应记录日志、操作IP、时间戳，并保留 ≥5年；

  • 企业账户需提前提交用户权限结构图及签字授权文件；

  • 推荐在《企业客户KYC登记表》中设立权限分配专栏。

避免设置“超级用户”权限绕开内部控制机制。

Q577：平台是否可以设置“交易返佣”机制？是否会构成操纵激励？

答：可以设置，但必须满足公平透明与反操纵的基本合规条件：

  • 返佣政策必须在用户协议中公开披露；

  • 应基于真实交易行为（如成交金额、日均持仓）制定返佣等级；

  • 严禁设定高频拆单套利式返佣逻辑；

  • 所有返佣记录应链上同步或后台系统可完整备查；

  • 应明确返佣上限与返佣时间窗口，避免成为操纵市场的手段。

若返佣为推荐制（Referral），建议设置多级绑定限制 + 实名实名实名验证。

Q578：MiCA下的白皮书是否可以使用NFT形式链上发布？有合规风险吗？

答：理论上可以作为一种辅助发布方式，但必须注意：

  • 官方合规提交版本必须为PDF/Word等可读文本格式；

  • NFT仅可用于内容同步与链上时间戳证明，不得替代正式白皮书备案；

  • 链上白皮书NFT应可公开访问、无Token Gate限制；

  • 平台须向BoL提交该NFT白皮书的镜像URL与hash值说明。

若使用NFT形式发布建议附加PDF签署版，供用户下载与查阅。

Q579：MiCA是否支持使用“去中心化身份”（DID）完成KYC流程？监管接受吗？

答：MiCA目前未禁止DID，但其监管接受度需满足以下前提：

  • DID提供者必须为受监管的身份验证服务商（如eIDAS合规）；

  • 平台仍需对DID认证结果进行复核与信息补充；

  • DID认证内容须涵盖基本身份数据（姓名、出生日期、居住地）；

  • 所有KYC认证数据必须保留在平台可调取的审计系统中。

建议将DID作为辅助认证工具，而非KYC主系统的唯一来源。

Q580：MiCA是否强制设立“投诉处理机制”？如何构建合规客服体系？

答：是，MiCA明确要求平台具备正式的客户投诉处理程序：

  • 须设立投诉专用邮箱、在线表单或电话渠道；

  • 所有投诉应在15个工作日内作出回应，特殊情况不得超过35日；

  • 平台应设立投诉登记簿，记录投诉内容、处理时间、责任人员；

  • 须定期向BoL提交投诉统计数据、客户满意度与改进计划；

  • 若客户对处理结果不满意，应说明向BoL或消费者保护组织申诉路径。

推荐发布《客户投诉机制政策手册》，并在官网底部设立透明通道。

Q581：MiCA对“加密资产流动性提供者”（Liquidity Provider, LP）是否有限制？

答：MiCA允许平台使用LP机制，但须进行合规披露与风险隔离：

  • 若LP为平台自营，应披露LP身份、交易对手风险、交易逻辑；

  • 不可将客户资金直接借出给LP或由LP代为撮合；

  • 若为外部LP（如做市商），应签署《LP协议》，明确止损机制及追保责任；

  • 所有LP交易数据应可追溯，并进行定期审计。

BoL可能会抽查LP账户的交易数据与对冲情况，确保不影响客户公正交易。

Q582：MiCA下能否设置“子账户”、“子钱包”或“子账户授权管理”？

答：可以，合规设置须符合以下条件：

  • 子账户必须记录在主账户名下，并具备单独KYC与权限控制；

  • 所有子账户行为应可审计、可撤回、具备操作限制（如限额）；

  • 若子账户由第三方机构托管，需额外提交该机构资质与协议；

  • 建议在《企业账户服务协议》中列明子账户控制人及授权范围。

建议冷钱包托管仍由母账户统一控制，避免权限扩散造成风控真空。

Q583：MiCA是否要求客户交易行为设置“限仓”或“风控预警”机制？

答：不是强制要求，但监管建议平台设置以下控制项：

  • 用户单日最大交易金额 / 最大持仓上限；

  • 持仓波动剧烈时的系统提示与强平预警；

  • 高频交易、刷量行为识别机制；

  • 用户信用评分与历史行为评估，匹配交易权限等级。

在商业计划书中加入“风险控制引擎”设计，有助于强化平台合规印象。

Q584：MiCA合规平台是否可以设置“Token质押挖矿（Staking Mining）”功能？

答：可设，但需区分技术性Staking与收益类Staking：

  • 技术性Staking（如ETH 2.0质押）需披露验证人节点机制；

  • 收益类Staking属加密资产收益产品，必须提供详细收益分配逻辑、历史APY说明、风险披露；

  • 用户收益来源不可为平台“预付”或“本金保证”，否则易被视为虚假或非法集资。

BoL或ESMA可能要求该产品结构出具法律意见，证明其不具备证券属性。

Q585：MiCA对平台的“系统变更”是否有申报义务？

答：是的，涉及以下重大系统变更需提前向BoL备案：

  • 核心IT系统更换或结构性调整（如钱包系统迁移）；

  • 撮合系统逻辑变更（如从订单簿模式切换至AMM）；

  • KYC引擎服务商变更；

  • 钱包权限签名逻辑调整或新增密钥结构。

平台应设置IT变更登记制度，每次变更应形成变更影响分析与测试报告。

Q586：是否可以将用户资产委托给外部第三方托管机构（Custodian）？

答：允许，但平台需保证以下几点：

  • 托管机构必须为欧盟或等效司法管辖区内的受监管实体；

  • 双方应签署托管协议，内容包括：保管义务、私钥控制机制、备份恢复程序、破产隔离保障等；

  • 客户需知情同意其资产被托管，并可查验托管方身份与地址；

  • 平台仍承担“最终客户资产归还责任”。

建议平台设立“托管机构审查与尽职调查机制”，并每年更新审查报告。

Q587：MiCA是否允许用户在平台注册多账户？

答：MiCA不禁止用户注册多个账户，但平台需：

  • 对每个账户独立完成KYC与风险评估；

  • 合并账户间的交易视为“相关账户”行为进行审计；

  • 禁止滥用返佣机制、套利系统等以多个账户规避交易规则；

  • 平台应能识别同一身份名下的所有账户并进行行为交叉分析。

如提供“家庭账户”或“企业名下多用户”，应设联合责任条款。

Q588：平台是否可为客户提供“API交易权限”对接第三方交易工具？

答：可以，但需合规控制：

  • 应对API申请人进行KYC，并要求披露其最终受益人（如为量化团队）；

  • 应限制API权限范围（如读取/下单/查询/资金划转），并设频率控制；

  • 所有API访问记录应完整留存 ≥5年；

  • 第三方API不得绕开用户界面进行风险提示与确认。

建议引入《API合约》，列明风险分担、数据保护及接口审计规则。

Q589：MiCA监管下，平台是否必须进行“系统压力测试”？

答：是的，属于IT治理合规的一部分：

  • 每年至少进行一次完整的系统压力测试（Stress Test），模拟高交易量、突发市场波动等场景；

  • 包含：撮合系统响应、钱包系统出入金速度、数据备份恢复能力、DDOS攻击响应；

  • 测试报告应形成文档，并在年度监管汇报中呈交；

  • 建议引入第三方安全审计机构参与，并评估系统脆弱点。

可同步进行BCP（Business Continuity Plan）演练，提升平台在危机中的合规能力。

Q590：MiCA是否对“客户资产赔偿机制”提出明确要求？是否强制购买保险？

答：MiCA未强制所有平台购买保险，但高度建议建立赔偿机制与风险准备金：

  • 平台可设立专项风险基金账户（如按收入的一定比例计提）；

  • 鼓励购买托管保险、热钱包损失保险、网络攻击赔偿险；

  • 客户协议中应明确说明赔偿范围、条件、金额上限等；

  • 若不设保险，平台必须提供“足额资本保障说明”作为替代。

BoL可能会要求高风险业务平台在资本要求基础上追加保险保障。

Q591：平台如何满足MiCA对“冷钱包管理权限”的监管要求？

答：MiCA对冷钱包（Cold Wallet）管理提出高度审慎的控制标准：

  • 签名权限最小化：冷钱包应采用多签（Multisig）或MPC（多方计算）结构，避免任何单人可单独转出资产；

  • 权限人员备案：所有冷钱包操作权限人员（含技术人员、管理层）需向BoL报备；

  • 操作双重审计：每次出金应由两人以上交叉审批，附日志记录；

  • 地理与物理隔离：建议冷钱包私钥存储于不同地点的安全硬件设备（HSM / Ledger Vault）；

  • 意外应急流程：平台应制定冷钱包私钥损坏、遗失、遭攻击时的应急恢复制度（如Shamir备份）。

推荐提交《冷钱包权限控制图》及《冷钱包出入金流程审计制度》作为配套合规材料。

Q592：MiCA是否支持平台设置“奖励积分、平台币回馈”机制？

答：支持，但应避免构成证券发行或误导宣传：

  • 积分或平台币不得承诺升值或固定回报；

  • 如平台币用于抵扣手续费，应披露规则并定期更新；

  • 回馈机制应清晰定义用途（如交易费抵扣、服务兑换等）；

  • 不可进行市场推广性空投以拉新（可能构成不合规发行）；

  • 若平台币可在二级市场流通，必须评估是否构成资产参考代币（ART）或EMT。

所有“奖励计划”应有配套《使用说明书》，并定期由合规团队审阅。

Q593：MiCA是否允许设立“定投计划”或“资产组合跟投工具”？

答：允许，但视具体结构而定是否触发MiFID或基金类监管：

  • 若平台仅提供定投工具（如每月自动买入BTC），需说明工具执行逻辑与客户授权；

  • 若为资产组合跟投产品（如复制某基金经理的组合），可能被视为管理类服务，需额外MiFID许可；

  • 定投产品必须提供中止机制，并不得强制扣款；

  • 平台应在投前披露波动、费用、退出路径等详细说明。

建议在提供该类功能前咨询法律顾问并出具“非集体投资构成”意见书。

Q594：MiCA平台是否可以支持“合约交易”“杠杆交易”？合规条件是什么？

答：MiCA本身不直接禁止，但前提是：

  • 所有衍生品（如永续合约）若参考资产为“证券类加密资产”，可能引发欧盟《金融工具指令》（MiFID）监管；

  • 平台必须清晰说明杠杆来源、爆仓机制、清算模型；

  • 应设置最高杠杆倍数限制，一般不超过5倍；

  • 所有杠杆交易应设强平线、通知机制与风险揭示；

  • BoL可能要求提供《杠杆交易产品风险评估报告》。

若用户基数超过10万以上，ESMA可能进行集中监管抽查。

Q595：MiCA下平台是否可以为用户提供资产托管+收益理财服务**？**

答：可以，但须明确定义并披露“收益来源”：

  • 收益不可为平台垫付或隐含“保证收益”；

  • 应公开披露资产去向（如存入DeFi协议或对接传统货币市场基金）；

  • 所有收益理财产品应设赎回机制、清算周期说明；

  • 平台应披露收益浮动性，并设置风险提示窗口。

若平台将客户资金投入自己控股或关联项目，应披露并设独立评审机制。

Q596：MiCA平台是否可提供“链上治理参与”服务？（如用户投票参与项目治理）

答：可提供，合规要点如下：

  • 应清晰区分：平台是否只是工具中介（relay）还是投票代理人；

  • 如平台代用户投票，必须说明投票标准、代理原则；

  • 所有投票记录需链上公开可验证；

  • 不得代用户决定其投票权使用方向，除非获得授权协议书；

  • 平台应披露项目治理结构和重大事项影响。

建议附带《用户链上治理参与说明书》及“免责声明”机制。

Q597：平台如何处理用户因法律变更、制裁等原因被冻结账户？MiCA有否规定？

答：MiCA要求平台：

  • 明确制定冻结账户政策：包括司法要求、制裁名单（如OFAC、UN）、诈骗案件；

  • 所冻结资产应隔离管理，不可转移或混用；

  • 平台应保存所有冻结原因、监管通知记录；

  • 用户可提出复议申请，平台应在合理时间内回复；

  • 若冻结超过6个月，应提交BoL特别说明或申请处理建议。

强烈建议与专业法律团队合作设立《资产冻结应对标准流程》。

Q598：MiCA是否允许设置“交易战队”“交易竞赛”类运营活动？

答：允许，但必须符合公平公开原则：

  • 所有竞赛规则应提前披露，含奖励计算、违规行为界定；

  • 平台员工或关联账户不得参与；

  • 奖励发放应公开透明，可链上验证；

  • 不得设置“拉人返佣+交易积分”的拉新竞赛结构；

  • 须设置风控规则防止刷单/对敲操作。

若奖励为代币，仍需审查其属性是否构成ART/EMT/证券类资产。

Q599：MiCA是否接受平台的“内部交易所代币”？如何判断是否属于可豁免通证？

答：MiCA将“通证”区分为以下几类：

  • EMT（电子货币代币）：锚定法币，如USDT、EUROC；

  • ART（资产参考代币）：锚定资产篮子、黄金、指数等；

  • 普通加密资产：如ETH、BTC，或平台币；

  • 证券型通证：如STO、含分红权或治理权的代币。

若平台发行“内部代币”，须说明：

  • 是否具备货币功能；

  • 是否承诺升值、参与利润、治理权；

  • 是否用于支付交易费、上币费等平台功能；

  • 是否可交易、是否上市二级市场。

若构成EMT或ART，则须申请对应牌照；否则可归类为“普通加密资产”，仍需备案。

Q600：MiCA是否强制平台员工完成合规培训？内容是否需存档？

答：是的，MiCA要求：

  • 所有合规相关岗位（RO/MLRO/客服/运营）每年至少完成一次合规培训；

  • 培训内容包括：AML/CFT指引、客户投诉应对、MiCA更新、KYC制度执行等；

  • 培训需形成记录，包括出勤表、教材内容、测验结果；

  • 推荐设置线上+线下混合模式；

  • 培训记录保留至少5年，供审计与监管抽查使用。

可将培训纳入员工KPI评估机制，建立长效制度。

Q601：MiCA是否允许平台跨国运营多个国家用户？有哪些合规条件？

答：是的，MiCA牌照持有者可向整个欧盟境内提供服务（“护照权”），但需注意：

  • 必须通过BoL提交跨境通报（Notification of cross-border provision）；

  • 平台需设定服务国家列表，披露用户获取方式与语言支持；

  • 若向非欧盟国家提供服务（如亚洲、中东），则需逐国判断是否违反当地法规；

  • 建议对非欧盟用户显示服务限制声明（geo-block或提示语）；

  • 合同条款中应列明适用法律、纠纷处理地。

可配置地理IP限制、KYC模板语言本地化、条款弹窗提示等技术合规措施。

Q602：MiCA平台是否必须对接链上分析服务商（如Chainalysis / Elliptic）？

答：不是强制要求，但强烈建议：

  • BoL未明确规定必须使用特定服务商；

  • 但平台需证明其有能力识别链上风险（可疑交易、黑名单地址、Tornado Cash）；

  • 若自主开发链上风险识别引擎，需说明模型逻辑与更新频率；

  • 使用第三方服务时，应提供合作协议、风险报告样本。

建议在STR机制中保留“链上来源识别逻辑”，并设定每日自动风险监测任务。

Q603：MiCA是否规定平台如何处理用户多账户或家庭账户共享问题？

答：MiCA鼓励平台：

  • 明确“一人一户”制度；

  • 对于存在多个账户的情形，应建立识别逻辑（如手机号、IP、地址比对）；

  • 对家庭共享设备使用情况应设置风险控制；

  • 严禁一人多号进行刷单、套利；

  • 对同一身份证明绑定多个账号的，应触发人工复审。

建议设立《用户账户规则与多号检测策略》，在风险控制系统中设预警模型。

Q604：MiCA平台是否允许提供NFT交易？合规要求有哪些？

答：MiCA不适用于纯粹非金融类NFT，但若NFT具以下特征则可能纳入监管：

  • NFT本身可分割并大量发行（如“伪NFT”或系列代币）；

  • NFT具备收益权、投资回报属性（如平台分红NFT）；

  • NFT嵌套了金融产品（如GameFi中的“收益矿机”类NFT）。

如平台支持NFT交易，应：

  • 定义NFT分类、展示其非金融属性；

  • 提供风险披露页面；

  • 建议设定二级市场交易限制（如冷却期、数量限制）；

  • 提交NFT项目合规评估报告。

若NFT项目本身具有“证券”属性，则需附加STO合规说明。

Q605：平台是否可对用户的链下资产（如银行卡入金）提供保障？

答：MiCA允许平台对客户资金提供一定保障机制，但须：

  • 明确保障方式，如保险、银行担保、风险准备金；

  • 不得承诺“百分百赔付”、“无风险兑付”；

  • 若采用第三方银行代收服务，需提供银行协议副本；

  • 所有链下入金行为必须进行AML监控，识别资金来源；

  • 建议设立用户充值限额、黑名单银行账户识别机制。

若平台建立储备金池，应向BoL申报其结构与风险控制机制。

Q606：平台是否可以支持用户绑定信用卡/Apple Pay等支付方式？

答：可行，但需符合以下要求：

  • 必须通过PCI-DSS合规支付通道，不可自行存储用户卡号；

  • 建议与受监管的支付机构（如Stripe、Adyen）对接；

  • 所有卡支付入金行为必须进行KYC匹配检查；

  • 出金时不可直接回信用卡账户（建议设中间钱包或IBAN账户）；

  • 平台应对绑定卡进行3DS验证、防欺诈监测。

不建议允许用户绑定他人信用卡付款，防止欺诈与洗钱风险。

Q607：MiCA是否对平台每日可处理的交易量有上限？

答：MiCA本身不设固定交易量上限，但BoL对“系统压力测试与风险控制能力”有期望：

  • 平台应设定每日处理量预估模型；

  • 若出现交易量急剧上涨，需启动限流/风控预案；

  • BoL可要求申请人提供“最大可承受交易量技术报告”；

  • 对于日交易量超过一定规模（如1亿欧元），将可能触发专项审计。

建议结合技术架构设立《高交易量应对机制与交易限额控制模型》。

Q608：MiCA平台是否必须披露所有Token Listing标准？

答：强烈建议公开透明Token上架流程，包括：

  • 评估标准（项目方背景、法律属性、白皮书审核）；

  • 风险等级分类（如红黄绿三色分级）；

  • 上币决策机制（是否有委员会、多维审批）；

  • 披露信息更新机制（如项目破产、团队变动）；

  • 所有上线Token必须保留尽调档案及合法性声明。

平台可设《Token Listing政策》单独页面，并附示例项目评估流程。

Q609：MiCA平台是否可以开设子品牌或以不同域名运营？

答：可以，但需向BoL备案以下内容：

  • 每个域名与平台之间的实际控制关系；

  • 不可让用户误以为其访问的是独立平台；

  • 所有子品牌必须由MiCA持牌实体统一运营与监管；

  • 营销、风控、合规体系需一致；

  • 不得利用子品牌避开主平台的监管与风控措施。

推荐统一设立“品牌授权说明页”，列示关联域名与持牌主体关系。

Q610：MiCA是否允许平台使用AI或机器人处理客户服务与交易撮合？

答：允许，但必须设立以下管控机制：

  • 明确AI系统的决策边界与可解释性；

  • 用户应知情其与AI交互的场景（如客服机器人、自动订单执行）；

  • 撮合系统若由AI决策，必须有人工可介入机制；

  • 合规审计中需提供AI系统模型说明、日志记录、误差处理机制；

  • AI系统应定期接受第三方安全评估与性能审核。

若使用AI处理合规监控（如交易反欺诈、链上监测），仍需设置人工复核机制。

Q611：MiCA是否对平台提供“借币”或“杠杆交易”有明文禁止？

答：MiCA并未全面禁止，但将此类行为视为高风险金融服务，须附加说明和风控机制：

  • 借币服务（Lending）：需明确借贷合同、利率、违约处理机制；

  • 杠杆交易（Margin Trading）：需明确最大杠杆倍数、强平逻辑、维持保证金要求；

  • 用户应签署高风险交易声明；

  • 平台需设每日风险敞口上限与整体资金池比例限制；

  • 必须出具《杠杆及借贷产品风险评估报告》。

建议使用“合格客户机制”筛选可使用杠杆服务的客户。

Q612：MiCA下平台是否可提供“收益宝”、“灵活账户”等收益型钱包？

答：收益型钱包属于类金融产品，MiCA要求：

  • 收益来源必须真实、可追溯，不得为平台垫付或虚构；

  • 应提供详细收益模型（如Staking节点收益、资产质押等）；

  • 不可宣传“保本保息”，需提供风险披露书；

  • 应设退出冷静期，且用户可随时查看资金去向；

  • 若涉及资产再投资（如质押ETH），需说明中介结构及安全机制。

建议披露收益变化历史图表，强化透明性合规。

Q613：MiCA是否允许提供“代币化实物资产”（如黄金NFT、房地产Token）？

答：允许，但需满足法律属性披露 + 资产确权机制清晰：

  • Token化资产必须有对应实物凭证或法律所有权登记；

  • 应说明托管机制（如实物黄金由哪家银行/仓储公司持有）；

  • 房地产类须披露不动产登记编号、估值报告；

  • 投资人须签署“投资非证券型代币”的知情书；

  • 建议获取法律意见函说明其不构成MiFID下证券。

若代币具备回购承诺、收益权等，则需额外考虑《欧盟证券法》框架合规性。

Q614：MiCA是否要求平台用户界面（UI）必须提供特定语言？

答：MiCA未强制，但建议：

  • 至少提供英文及目标市场官方语言版本（如面向德国，需含德文）；

  • 所有关键合规信息（如KYC条款、风险披露）应支持用户熟悉语言；

  • 不建议通过Google翻译等自动服务提供正式合规内容；

  • 建议合规文档使用专业翻译，并保留版本控制日志。

若平台有多语言版本，需确保各版本法律效力一致，避免误导风险。

Q615：平台是否可使用“全币种钱包”（如一个地址支持多链资产）？

答：可行，但需满足以下技术与风控条件：

  • 所有链上资产必须能被追踪、备份、恢复；

  • 多链钱包必须支持独立私钥管理或使用多签/MPC结构；

  • 用户界面中需清晰显示每种资产的链别、确认机制；

  • 禁止使用无法识别来源或不透明路线的跨链桥；

  • 若支持资产互换（swap），应列明价格来源与滑点限制。

建议为每种链资产设置独立风控规则并列入合规流程。

Q616：MiCA是否允许平台设置“推荐返佣制度”？

答：允许，但需防止其演变为“传销式”结构，建议如下：

  • 返佣应基于真实交易量，不得诱导开设多个账户；

  • 不应设置层级返佣（如无限级别下线）；

  • 所有返佣行为应登记并可审计；

  • 应披露返佣比例、计算逻辑及税务处理建议；

  • 禁止为未经KYC的账户提供返佣。

建议引入《推荐计划合规政策》，明确规则边界。

Q617：MiCA是否对用户提款速度有最低要求？

答：MiCA要求平台披露提现时间，不强制具体时效：

  • 建议设定提现标准流程时间（如≤24小时）；

  • 若触发风控（如大额或地址变更），应在《提款规则》中列明；

  • 所有提现请求应有操作日志、交易广播证明；

  • 平台应提供提款状态实时查询功能；

  • 若使用冷钱包出金，应注明人工操作时间段。

长时间未处理提现可能构成客户投诉与监管介入依据。

Q618：MiCA是否支持平台提供法币稳定币服务（如自发USDE等）？

答：支持，但自发稳定币（ARTs / EMTs）属于MiCA下监管重点：

  • 稳定币发行人必须获得EMI或ARTs牌照；

  • 应建立储备金账户，提供储备金审计证明；

  • 披露锚定机制（法币、算法等）及流动性支撑模型；

  • 禁止用于误导性宣传（如冒充官方货币）；

  • 所有稳定币交易必须支持链上追踪与风险识别。

若平台只提供第三方稳定币（如USDC），则应验证其合规性。

Q619：MiCA是否允许平台内设“社区治理”、“DAO模块”？

答：允许，但须明确其与核心平台之间的法律边界：

  • DAO投票不可影响平台核心控制权；

  • 所有DAO提案应备份、记录，形成治理档案；

  • 用户应知情DAO提案结果不具法律强制性（如仅为建议）；

  • 若DAO控制资产（如生态基金），需披露其托管机制；

  • 建议披露《DAO章程》并出具法律意见说明其不构成非法证券发行。

不建议将平台重大决策（如Token上架、费率变更）交由DAO全权控制。

Q620：平台是否可以仅获得MiCA牌照而不申请EMI牌照？

答：可以，是否申请EMI取决于是否经营电子货币/法币储值业务：

  • MiCA牌照适用于虚拟资产服务，如交易、托管、发行等；

  • 若平台要提供法币钱包、充值/提现到欧元账户等功能，则必须获得EMI或与EMI合作；

  • 也可通过Payment Institution（支付机构）合作方式嵌入法币功能；

  • 不申请EMI的MiCA平台应禁止用户使用其账户存放法币余额。

建议在合规架构中清晰划分MiCA与EMI模块，并明确合作边界。

Q620：平台是否可以仅获得MiCA牌照而不申请EMI牌照？

答：可以，是否申请EMI取决于是否经营电子货币/法币储值业务：

  • MiCA牌照适用于虚拟资产服务，如交易、托管、发行等；

  • 若平台要提供法币钱包、充值/提现到欧元账户等功能，则必须获得EMI或与EMI合作；

  • 也可通过Payment Institution（支付机构）合作方式嵌入法币功能；

  • 不申请EMI的MiCA平台应禁止用户使用其账户存放法币余额。

建议在合规架构中清晰划分MiCA与EMI模块，并明确合作边界。

Q621：MiCA平台是否可以支持“子账户”或“托管账户”模式？

答：可以，但必须建立严格的托管责任和子账户映射机制：

  • 每个子账户必须与唯一KYC身份绑定；

  • 子账户之间不得直接互转资产，必须经由主账户授权；

  • 若为企业用户设置多层子账户，建议引入“权限层级管理”（如操作员、审核人）；

  • 子账户内资产应在账务系统中清晰分离；

  • 平台须保留所有子账户操作日志和授权链路。

常用于资产托管、交易团队账户分工、白名单机构管理等场景。

Q622：MiCA是否规定平台必须每天生成账单或交易清单？

答：MiCA未强制每日生成账单，但要求可实时导出交易记录，并建议：

  • 每日生成内部账务报表（对账、冷热钱包余额、交易明细）；

  • 用户端应允许下载个人交易记录（CSV、PDF等格式）；

  • 所有资金流动、钱包变动、订单撮合记录应可导出以供稽核；

  • 平台应设《账务对账制度》，定期与审计系统核对。

若平台使用多币种、跨链交易，更应有统一结算与合规核算模型。

Q623：平台是否可以支持匿名交易或隐私币？

答：MiCA 明令禁止匿名币（如Monero、Zcash“Shielded”）及匿名账户：

  • 所有交易必须可关联用户身份，满足KYC/AML要求；

  • 禁止提供无实名开通交易服务；

  • 隐私币除非完全可审计、可追踪，不可上线；

  • 平台可设隐私保护功能（如昵称展示、部分信息加密），但不得掩盖监管可识别性。

可接受“合规可审计”的链上隐私增强方案（如Tornado Fork合规版本、zkSync附属证明等）。

Q624：MiCA平台是否可以对接DeFi协议？例如作为“流动性提供方”？

答：可以对接，但需满足以下前提条件：

  • 所有对接协议必须是审计过的合规项目；

  • 必须披露对接策略、合约地址、收益计算方法；

  • 若使用平台用户资金提供流动性，必须取得用户明示授权；

  • 建议由法务评估DeFi协议合规性，并出具接入风险控制书；

  • 不得自动复投或跨协议调配用户资产，避免形成混池或损失。

平台与DeFi互动行为应记录在案并报告给监管，如年度合规报告中说明用途与收益。

Q625：MiCA平台是否可将热钱包托管交由第三方？

答：允许，但需满足以下合规条件：

  • 第三方钱包提供商必须是MiCA认证托管服务商（CASP）；

  • 合作合同应包含热钱包运营职责、赔偿机制、数据接口说明；

  • 平台应具备实时监控能力、API安全认证和审计机制；

  • 需对第三方热钱包服务商进行年度尽职调查（Due Diligence）；

  • 所有客户热钱包资产变动必须同步平台账务系统。

建议热钱包分层限额，例如单笔交易/日累计额度设限。

Q626：MiCA是否规定私钥管理方式必须为MPC？是否可采用硬件HSM或多签？

答：MiCA未规定唯一标准，但要求私钥管理必须高安全、可审计、不可单点故障：

  • MPC（多方计算）为目前广泛认可方案；

  • 多签（Multisig）+ HSM（硬件安全模块）亦可接受；

  • 建议提供系统架构图、私钥恢复流程、权限分层机制；

  • 平台需出具第三方安全评估报告或渗透测试报告；

  • 建议每半年进行密钥轮替与权限审计。

BoL在审批时会特别询问冷/热私钥的备份与隔离机制。

Q627：MiCA是否要求平台提供APP移动端？

答：非强制，但如有APP版本，应符合以下要求：

  • 与网页版功能一致，尤其是在KYC、交易、资金管理方面；

  • 提供“用户安全模块”（如指纹登录、2FA）；

  • 应对APP进行安全测试（如OWASP Mobile Top 10）；

  • 不得通过APP绕过监管条款（如隐藏风险披露、跳过合规流程）；

  • 建议APP上线前向BoL提交简要说明报告。

APP版本的使用数据与异常操作应纳入平台风控与审计机制中。

Q628：MiCA是否允许平台为用户提供第三方税务服务（如生成税表）？

答：允许，但需满足以下原则：

  • 税务服务应作为附加服务，并非MiCA合规义务；

  • 应提供免责声明，说明税表仅供参考，用户应自行向本国税局申报；

  • 若合作第三方税务公司，应公示其资质与服务协议；

  • 建议提供交易分类与利润/亏损计算接口导出功能；

  • 平台不得为用户提交或代替纳税。

可与Koinly、Accointing等平台集成提供报税文件导出。

Q629：MiCA平台是否可以进行Token预售或IEO？

答：可以，但必须完整履行资产发行人（Crypto-Asset Issuer）责任：

  • 提交完整的白皮书（White Paper）并经BoL备案；

  • 披露发行目的、资金用途、流动性安排、退出机制；

  • 不得误导用户，承诺收益或保本；

  • 上线时间、锁仓机制、销售渠道应全程披露；

  • 必须建立代币认购流程及反洗钱控制。

推荐设置冷静期+认购退款机制，强化用户权益保护。

Q630：MiCA平台是否必须建立“内部举报机制”或“合规热线”？

答：是的，属于内部治理要求之一：

  • 应设立员工或客户匿名举报系统（Whistleblower System）；

  • 所有举报应记录、评估、形成合规回应流程；

  • 需指定内部负责人审查所有举报（如合规官、RO）；

  • 对所有不当行为的举报应制定处理时限；

  • 平台应提供《内部举报制度与反报复政策》。

建议与第三方合规平台合作，如Whispli、EQS，强化信任保障。

Q631：MiCA平台是否可以通过API开放交易功能供第三方接入？

答：可以，但须在合规与技术接口层面双重把控：

  • 所有API接入方必须先完成KYC并签署合作协议；

  • API交易须强制启用权限控制（如读取、下单、转账分离）；

  • 应限制访问频率、防止滥用和接口攻击（建议WAF防护）；

  • 应记录每次调用日志，含请求时间、参数、用户ID等；

  • 若为机构客户API，应制定《API交易授权规则与安全评估书》。

所有通过API完成的交易都需进入平台风控系统处理，不能跳过交易规则。

Q632：MiCA是否允许平台推出“理财产品组合”或“资产配置推荐”？

答：允许，但仅限于非承诺收益类建议型产品：

  • 可通过算法生成资产组合，但需注明“建议性质”；

  • 不可为非合格客户推荐高风险产品（如杠杆代币、波动性资产）；

  • 建议产品组合应附带《风险承受能力测评报告》；

  • 若平台为组合产品收取管理费，需披露费率结构；

  • 所有组合应提供每月收益披露与调仓记录。

不得使用“无风险”、“保底收益”、“稳赚不赔”等误导性措辞。

Q633：MiCA是否允许设立“合格投资者专区”？哪些客户可进入？

答：允许，并建议平台划分专区与权限管理机制：

  • 合格投资者通常指高净值客户、机构客户、专业交易者；

  • 进入专区应完成额外的《投资者分类声明书》和《风险知情书》；

  • 可开放更复杂的产品（如期权、杠杆、Staking池等）；

  • 建议平台内部系统按KYC分类自动分配用户访问权限；

  • 应防止普通用户绕过机制访问专业产品。

平台后台应能导出每位用户“投资者类型”的分类依据与授权记录。

Q634：平台是否可以与第三方支付机构（如Stripe、Checkout）合作法币充值？

答：可以，但需满足下列条件：

  • 第三方支付机构应具备欧盟EMI或PI资质；

  • 与平台之间应签署正式的《代收/代付合规协议》；

  • 用户充值流程中应披露“由第三方收单，不代表MiCA持牌人收款”；

  • 平台应定期审核其KYC/AML程序是否符合MiCA等效标准；

  • 所有法币充值应具备“资金追踪链条”并接入平台账务系统。

若第三方支付方出现交易争议，平台应提供用户介面记录与证据文件。

Q635：MiCA是否规定Token必须开源或可审计？

答：MiCA未强制代码开源，但强烈建议：

  • 重要合约（如转账、授权、销毁逻辑）建议开源并由第三方审计；

  • 白皮书中应说明合约部署时间、合约地址及升级逻辑；

  • 禁止设有隐藏控制权、后门转账、权限无限增发等机制；

  • 建议出具《合约安全评估报告》并公示主要漏洞修复历史；

  • 若使用Upgradeable Proxy（代理合约），应特别注明变更权限及流程。

否则在面谈/审批时可能被质疑“项目不透明或中心化控制过强”。

Q636：MiCA平台能否在Telegram、Discord上开展运营？需注意什么？

答：可以使用社交媒体运营，但不得作为正式客户沟通或服务渠道：

  • Telegram、Discord群组应注明“非正式沟通平台，不代表法定服务通道”；

  • 不得在群组中直接发布投资建议或交易信号；

  • 不得让客户通过非官方渠道提交KYC或身份信息；

  • 所有群组管理员应经过平台授权，并保存用户互动记录；

  • 群内客服若涉及资产相关内容，应引导至官网或App操作。

建议设定群组守则并使用机器人（Bot）记录风险披露。

Q637：MiCA是否规定平台必须向欧盟客户开放？是否可只做非欧盟业务？

答：MiCA的本意是规范在欧盟境内对客户提供虚拟资产业务的平台：

  • 如仅面向非欧盟客户，原则上不必取得MiCA牌照；

  • 但若使用.eu域名、欧盟语言、支持欧元充值，或在欧盟设服务器、人员，即构成服务行为；

  • 若平台虽在第三国注册，但针对欧盟居民提供服务，仍须受MiCA约束；

  • 最佳策略为设立“地理封锁机制”（Geo-Fencing）并在合规政策中披露“不对欧盟客户开放”；

  • 可通过Cloudflare、IP数据库等实现自动识别访问来源。

MiCA监管重点为“欧盟居民是否可访问 + 是否提供服务 + 是否存在推广行为”。

Q638：MiCA是否对平台的“市场推广”行为有限制？能否打广告？

答：可进行市场推广，但需遵守以下合规原则：

  • 所有广告内容需真实、清晰、无误导性；

  • 禁止使用“无风险”、“稳赚”、“限时暴涨”等诱导字眼；

  • 建议广告中标明“虚拟资产存在市场风险，不适合所有投资者”；

  • 如含收益示例，应注明“仅为历史数据，不构成未来承诺”；

  • 广告渠道如为欧盟境内媒体，应出具《广告合规备案表》存档。

每次广告投放应记录投放平台、文案、覆盖用户、时间、转化数据等信息，用于未来稽核。

Q639：MiCA是否要求平台具备内部风控引擎？可否外包？

答：平台需具备有效风险控制系统，但可选择以下三种方式：

  • 自建风控系统：代码与逻辑自控，推荐大型平台；

  • 使用外部SaaS系统（如Chainalysis、Elliptic Risk Scoring）；

  • 混合方案：使用SaaS输出风险评分，自建系统处理规则触发。

关键要求：

  • 所有风控操作应可回溯与审计；

  • 所有异常账户、行为、地址应设等级并形成行动建议（如冻结、KYT查询）；

  • 必须每日生成风险事件日志与处理状态表。

平台应设定《风控响应时间SLA》（Service Level Agreement）及风控团队轮值表。

Q640：MiCA是否允许多个平台共享同一合规架构？如集团多个子品牌？

答：允许，但必须满足以下独立与授权机制清晰的条件：

  • 每个平台应具备独立合规标识（如CASP编号）；

  • 合规架构（如KYC/KYT系统、审计系统）可共用，但需每个平台留有审计副本；

  • 不得出现集团“统管客户资金”或“跨平台转账无审计”的行为；

  • 建议出具《共享合规系统协定》说明权限划分；

  • 各平台应能独立生成监管报告、合规文件、投诉机制。

若一个母公司控股多个MiCA平台，应申请母公司+子公司并行监管结构。

Q641：MiCA持牌平台是否可以跨国设置客服中心？例如设在亚洲或非洲？

答：可以，但需满足以下条件：

  • 客服外包或跨境设置需有正式的服务协议与数据安全管理制度；

  • 所有客服须接受AML/KYC基础培训并了解平台风险政策；

  • 数据跨境需符合GDPR要求（特别是客户身份、交易等敏感信息）；

  • 投诉、纠纷、争议处理机制必须由欧盟总部负责主导；

  • 平台应指定一名欧盟内的客户保护联络人，与BoL对接。

BoL重点审查：是否存在客户数据泄露风险、客服误导销售、以及无法提供审计链。

Q642：MiCA是否要求客户资产“每日对账”？如是，对账方式有哪些？

答：是，MiCA明确要求平台每日核对客户资产：

  • 客户资产应与平台自有资金严格隔离；

  • 每日对账包括：客户余额 vs 区块链地址实际余额 vs 内部账系统记录；

  • 建议生成《客户资产对账报告》（每日自动化）；

  • 异常金额应当日报备，次日修复或做差异说明；

  • 如使用托管钱包（如Fireblocks），应具备API核账机制。

平台应具备完整的账务审计链条，从“充值-交易-提现”全链路可追溯。

Q643：MiCA是否允许平台提供“刷卡买币”服务？如使用Visa/MC通道？

答：允许，但需满足：

  • 刷卡渠道须由受监管金融机构提供（如EMI、银行或PSP）；

  • 客户完成KYC前不得开启刷卡功能；

  • 需对每笔交易设置风控（如限额、BIN号筛选、防盗卡机制）；

  • 平台应与卡机构签署风控共享协议；

  • 支持交易应与客户账户自动绑定，且不能匿名支付。

所有卡类支付应保留6年以上交易日志与反洗钱评估记录。

Q644：是否可以在MiCA牌照下提供“场外OTC大额撮合服务”？

答：可以，但平台必须设立OTC业务独立流程：

  • OTC客户需完成高级KYC及反洗钱审查；

  • 应设置最低交易门槛（如5万欧元）；

  • 应明确是否为平台撮合还是自营对手方；

  • 应有交易撮合记录、报价机制、合约签署记录；

  • 建议使用独立页面或接口操作，分开系统数据与报价渠道。

高净值OTC客户建议额外签署《适当性匹配声明》。

Q645：MiCA平台是否允许提供USDT或BUSD等非欧盟发行的稳定币？

答：MiCA允许支持非欧盟稳定币，但有限制：

  • 必须对该稳定币进行风险评估，并取得其项目方合规信息；

  • 平台需在官网注明其非MiCA监管资产；

  • 不得将其作为客户资产保值推荐用途；

  • 若该稳定币总持有客户金额超过50万欧元，需提交额外流动性与信用风险说明；

  • 建议平台逐步引导客户转向MiCA合规稳定币（如EURe）。

若平台自营发行稳定币，须单独申请ART/EMT牌照，不可混用。

Q646：MiCA对“员工持Token”是否有监管限制？

答：有以下合规要求：

  • 员工若持平台所发Token或参与项目融资，需签署《员工利益冲突披露书》；

  • 核心管理层须申报所持Token比例、购买时间、来源、锁仓情况；

  • 若员工在二级市场交易Token，建议纳入交易监控机制；

  • 若员工参与DAO治理或合约升级，需申报并分离职责；

  • 内部员工不得在未披露信息前提前交易（防内幕交易审查）。

建议平台建立“员工Token管理制度”，定期稽核并对高持仓员工设置观察期。

Q647：MiCA平台是否可以给客户发放“交易奖励”或“空投”？

答：允许，但必须满足：

  • 奖励或空投须公平、透明、事前披露；

  • 不得以“奖励”为名义误导客户频繁交易或诱导充值；

  • 奖励机制文件需归档，包括对象、时间、数量、目标、是否为推广；

  • 空投涉及第三方项目时，平台应评估其是否合规、是否构成证券；

  • 建议不定期审查“奖励结构”是否符合GDPR、营销公平原则。

若奖励具有实际经济价值，可能需视为“附加报酬”并计入财务合规报表。

Q648：MiCA是否允许平台开展借币业务（如币币抵押借贷）？

答：视具体业务而定：

  • 若平台作为撮合方，并未承担信用风险，可在合规架构下运行；

  • 若平台作为借出方或承诺本金/收益回报，可能构成金融工具，应报BoL额外许可；

  • 建议平台建立《借贷协议》、《风险揭示书》、并强制客户签署；

  • 所有借贷关系应有链上记录与合规合同，并接入风控系统自动管理；

  • 应披露“借贷违约应对机制”与资产处置流程。

大额借币建议附带质押物估值流程，含价格波动的清算机制。

Q649：MiCA平台可否与DeFi协议打通接口，如通过Uniswap/Venus等？

答：谨慎可行，但需全面风控：

  • 与DeFi协议交互的资产必须可回溯并明确协议控制权；

  • 若平台将客户资产投入DeFi协议，应取得客户授权；

  • 建议设立《DeFi桥接使用政策》说明每一合约的功能、审计、漏洞应对；

  • 每笔交易建议自动生成日志，并保存在中心系统中审计；

  • 对于非审计协议，不建议客户参与，亦不推荐对接。

与链上协议打通时，平台需具备链上地址管理策略及权限验证流程。

Q650：MiCA平台的代币是否可以在香港、新加坡等地区交易？

答：技术上可以，但必须满足对方国家监管要求：

  • MiCA监管的是在欧盟提供服务的行为，不限制其代币流通；

  • 但平台应确认目标国家是否将其Token视为证券或交易所牌照范围；

  • 建议平台在发行白皮书中明确说明该Token不向特定国家居民销售；

  • 若需上线到他国平台，应准备《法律适用性意见书》（Legal Opinion）；

  • 可将海外交易作为“二级市场流通”，但平台自身不得主动营销。

MiCA牌照不代表“全球通行”，建议每个目标市场皆做监管分析。

Q651：MiCA是否允许平台提供多语言版本网站？多语种需符合同一合规标准吗？

答：允许提供多语言网站，但必须满足以下合规要求：

  • 所有语言版本必须内容一致，特别是风险披露、用户条款、KYC政策等；

  • 如存在翻译误差，平台须以“欧盟官方语言版本”为准，并声明其为主导版本；

  • 建议设立内部翻译审查程序，并由法律合规部门最终确认发布；

  • 不可出现“语言差异带来的法律偏差”，否则视为误导营销；

  • GDPR及客户投诉处理机制需在所有语言版本中完整保留。

推荐语言优先级为：英语 + 立陶宛语 + 客户主要来源地区语言（如中文、德语、葡语）。

Q652：MiCA申请中必须提供Token Listing的全流程文档吗？应包含哪些内容？

答：是的。Token上架（Listing）机制需详细说明，内容应包括：

  • 上币评估机制（包括商业评估、合规评估、技术评估）；

  • Token合规属性分析，包括证券性评估、项目透明度、智能合约安全性；

  • 风险揭示书模版（Risk Disclosure）；

  • 项目方尽职调查报告（含背景调查、资金用途、Token分配结构）；

  • 退市机制说明；

  • 合约审计报告引用与保留机制；

  • Listing审核委员会组织架构（建议由RO/MLRO参与）。

可提交《Token Listing机制流程图》及《上币审批记录模版》。

Q653：MiCA对“冷钱包”如何定义？是否可以使用第三方托管方案？

答：MiCA未强制“冷钱包”，但在客户资产保护章节中推荐使用不可联网的储存机制：

  • 冷钱包是指物理隔离、不能远程控制的钱包（如硬件钱包、HSM模块）；

  • 可使用第三方托管方案（如BitGo、Fireblocks等），前提是：

    • 该机构受MiCA认可或欧盟等效监管；

    • 签署托管协议，包含访问权限、应急恢复、双签结构；

  • 平台须保留冷钱包资产审计日志，并定期与BoL报告资产状态。

建议冷钱包配置双重签名（2/3结构），并由独立合规人员或董事会联署授权。

Q654：MiCA平台是否可以设置“手续费浮动机制”？比如根据用户等级或Token波动调整？

答：允许设置浮动机制，但必须遵循：

  • 所有收费机制应提前公开披露；

  • 每次手续费调整应记录变动说明，归档保存；

  • 浮动比例需明确边界（如：“0.1%-0.25%”）；

  • 不可随意、频繁变更，避免误导客户；

  • 若手续费设计与持仓Token、参与活动相关，需附上“手续费优惠方案说明文件”。

建议建立《费用结构透明政策》供审计或客户调阅。

Q655：MiCA是否允许平台拥有非欧盟客户？是否必须区隔用户池？

答：允许服务非欧盟客户，但需做好“合规区分”：

  • 平台应在系统中区分 EU 用户与非 EU 用户（如不同接口、URL、合规文档）；

  • 非欧盟客户需同意非MiCA监管服务条款（并签署免责声明）；

  • 建议对非欧盟客户使用不同的市场策略和产品设计；

  • 避免误导性宣传“MiCA覆盖全球”；

  • 有些国家（如美国、中国）可能限制其居民使用该服务，须设置IP或身份证识别屏障。

若平台“主要客户”来自欧盟，BoL可能要求进一步跨境监管报告。

Q656：申请MiCA时是否需要提交公司章程（Articles of Association）？需特别编写吗？

答：是，BoL在第一轮申请中通常会要求提交公司章程：

  • 内容应符合立陶宛《公司法》规定，并附加CASP相关经营目的说明；

  • 应明确：

    • 公司经营范围包括“提供虚拟资产服务”；

    • 权力结构中有对合规负责人、合规委员会的设定；

    • 允许设立合规储备资金、设定合规预算；

  • 若章程中含有Token发行或平台业务条款，更有助于监管理解其营运逻辑。

推荐在公司注册时就制定“MiCA适配型章程”，便于后期同步管理层架构与制度。

Q657：MiCA是否规定公司名称中必须包含“Crypto”、“Digital”或相关字眼？

答：不强制，但建议：

  • 公司名称需体现经营实质，避免与传统银行、保险机构混淆；

  • 如选择“Digital Asset”、“Crypto”、“Token”、“Exchange”等字样，需说明其用途；

  • 若选择通用词（如Global Trade Ltd.），建议额外附营业说明与官网链接说明；

  • BoL更关注经营实质，但不接受“误导性品牌命名”（如EU Central Bank Exchange Ltd.）。

命名应与域名、网站、法定文件、白皮书保持一致性。

Q658：MiCA是否允许设立“子品牌”来运营特定国家或市场业务？

答：允许，但需合规披露：

  • 子品牌必须归属在MiCA持牌主体或其全资子公司名下；

  • 所有合规政策、条款仍需统一备案；

  • 子品牌官网、宣传资料应链接至MiCA持牌公司主页，并说明监管实体；

  • 客户关系（开户、合约签署、KYC）须归属主体公司；

  • 若子品牌启用独立技术架构，需再提交系统审查报告。

建议设立《子品牌运营策略说明书》并向BoL备案。

Q659：MiCA是否允许客户通过第三方机构（如IB、渠道商）开户？

答：允许设置中介开户（Introducer Broker）机制，但极度严格：

  • IB须完成尽职调查、签署合规协议并接受反洗钱培训；

  • 所有KYC/EDD仍必须由MiCA持牌公司完成最终审核；

  • 禁止IB代开户、代签协议、代收款项；

  • 每一个IB/渠道商需备案并附联系方式、主要市场、客户数量等信息；

  • 应定期对IB客户行为进行监控与审计。

可建立《渠道商管理政策》，附标准协议模版与KYC审查指引。

Q660：MiCA持牌后是否必须每年向监管机构做一次内部审计？

答：是，MiCA持牌机构每年至少进行一次内部合规审计（Internal Compliance Audit）：

  • 可由内部合规部门完成，也可委托第三方独立审计机构；

  • 审计内容包括：AML/KYC制度执行、客户资产保护、系统安全、投诉处理、STR提交等；

  • 审计结果需形成《合规审计报告》，并在规定时间内报BoL；

  • 重大缺陷（如数据泄露、政策失效）必须在30日内提交整改计划。

建议设立《年度审计时间表》并形成董事会定期合规回顾机制。

Q661：MiCA是否要求对员工进行反洗钱与MiCA知识培训？培训需记录吗？

答：是的。MiCA对员工培训有明确监管要求：

  • 所有核心员工（前台客服、合规团队、IT人员、市场团队等）必须接受至少每年一次的AML/KYC培训；

  • 培训内容可包括：

    • MiCA核心制度（如客户适当性、资产保护）；

    • STR提交流程；

    • 客户行为异常识别；

    • 系统操作中合规事项；

  • 每次培训需保存：

    • 培训材料；

    • 签到记录；

    • 培训测验记录（如适用）；

    • 培训反馈报告。

建议建立《合规培训年度计划表》与《培训记录档案夹》，供审计与BoL抽查使用。

Q662：MiCA是否要求设立“可疑交易报告（STR）”的内部提交流程？

答：是。STR（Suspicious Transaction Report）提交流程是AML框架中的核心内容：

  • 平台应设立STR识别标准，并配备MLRO为唯一授权上报人员；

  • STR触发条件包括：异常交易行为、客户资料不一致、巨额交易频繁等；

  • STR须在发现后立即上报立陶宛FIU（金融情报单位）；

  • 应有完整记录，包括内部发现、调查、上报、后续追踪流程；

  • STR日志应保留至少5年，不得告知客户（避免“tipping-off”）。

推荐配套文档：《STR提交流程图》《STR触发指标手册》《STR样本范例包》。

Q663：MiCA是否允许设立“家庭办公室专属通道”或高净值客户服务方案？

答：允许，但必须符合“客户平等待遇”原则：

  • 平台可以根据客户资产规模、交易频率等设立高端服务方案（如定制顾问、VIP账户经理）；

  • 但不得在合规要求（如KYC/EDD）上设置更宽松门槛；

  • 所有客户类别差异服务应公开说明并具备可审计标准；

  • 如设立专属通道（如API速度优先、交易折扣等），应防止利益冲突与操纵风险。

建议将高净值客户方案纳入商业计划中备案，并形成《客户分层策略》文档。

Q664：MiCA是否强制要求独立设立“审计委员会”？

答：不是强制性规定，但建议设立：

  • 对于规模较大的CASP平台，BoL倾向于设有审计委员会的治理架构；

  • 审计委员会应独立于运营团队，负责：

    • 内部审计评估；

    • 外部审计配合；

    • 合规报告审查；

  • 成员可包括独立董事、合规负责人及法律顾问；

  • 建议将审计委员会的职责与权限在《章程》或《公司治理手册》中明确写明。

对DeFi背景公司或Token发行项目尤为重要，用于增强信披透明度。

Q665：MiCA申请是否需要披露董事会会议制度与频次？

答：是。平台应向BoL提交其公司治理安排，内容包括：

  • 董事会会议计划（建议每季度1次以上）；

  • 会议记录保留机制；

  • 各董事出席情况统计；

  • 涉及风险、产品、IT系统等议题的提案机制；

  • 对关键决策（如Token上架、合规整改）是否通过会议表决等。

推荐提供《董事会会议制度摘要》作为申请附录，有助于展示治理透明度。

Q666：MiCA是否允许董事或股东持有其他加密平台股份？会有利益冲突问题吗？

答：允许持股，但须披露并管理利益冲突：

  • 所有董事、高级管理人员及股东若同时参与其他加密平台，应在申请中申报；

  • 若该平台与MiCA申请平台存在直接或潜在竞争、业务往来，需提出防冲突措施；

  • 建议签署《利益冲突申报书》，并设立董事会议回避机制；

  • 多平台持股结构如涉及交易撮合或托管业务，BoL会特别审视控制链条与透明度。

建议附上股权结构图、冲突防控机制与内部申报机制。

Q667：MiCA是否对“风险评估矩阵”有明确模版？必须提交吗？

答：MiCA未提供固定模版，但BoL审核时强烈建议提供：

  • 风险评估应涵盖：

    • 法律合规风险；

    • 技术系统风险；

    • 市场波动风险；

    • 客户欺诈与洗钱风险；

  • 建议使用“风险等级 + 概率 +影响 + 应对措施”的4段式模型；

  • 风险等级建议区分为：高 / 中 / 低；

  • 每项风险应匹配明确的合规控制措施与负责人。

附件建议提交：《综合风险矩阵表》《风险监控年度更新制度》。

Q668：MiCA是否对平台技术开发方背景进行监管？例如是否允许外包中国或印度开发商？

答：允许外包开发，但必须符合以下规定：

  • 核心平台技术（撮合、KYC、资产管理）若由第三方提供，必须签署合规开发协议；

  • 外包方是否位于欧盟以外，BoL并无绝对禁止；

  • 但平台仍需：

    • 拥有技术系统完整访问权限；

    • 拥有源代码控制权；

    • 设置应急接管机制；

  • 系统开发必须满足GDPR、日志记录、权限控制等MiCA要求。

建议附《IT系统外包协议》《源代码接管流程图》《技术背景合规尽调报告》。

Q669：MiCA平台是否可以支持“链上资产证明机制”用于客户资产透明度披露？

答：可以，属于合规增强措施：

  • 支持平台公开链上地址、存证机制，以供客户核实资产状况；

  • 可借助zk-SNARK或Merkle Tree生成Proof of Reserve；

  • 若使用加密算法进行资产总额披露，需附带算法验证逻辑与审计报告；

  • 不可将链上展示替代年度审计，但可作为辅助透明度机制。

建议提供《资产证明机制说明书》及技术架构示意图。

Q670：MiCA是否接受Token未上市前预注册？申请时是否需提交完整Token白皮书？

答：可接受尚未上市Token的平台申请，但需披露：

  • Token设计蓝图、经济模型、未来发行计划；

  • 如Token尚未发行，需说明预计上市时间与初期发行平台；

  • 白皮书即便未最终定稿，也应提交草案或结构目录；

  • 如申请平台将以该Token作为平台币或手续费支付机制，需披露Token用途、流通安排、发行人身份等；

  • BoL会审查是否存在潜在的非法集资、误导性宣传、项目方控制风险。

建议同步提交《Token Pre-Launch Disclosure Form》与《Token Governance Model》。

Q671：MiCA对Token经济模型（Tokenomics）有什么关注重点？

答：BoL 和 ESMA 关注以下几点：

  • 分配机制是否公平透明：是否有锁仓期、是否有早期投资者利益倾斜；

  • 通胀率与供应机制：总发行量是否有限？是否存在持续增发机制？是否披露增发逻辑；

  • 激励与销毁机制：是否涉及交易激励、质押收益、回购销毁等；

  • 治理机制：是否由持币人治理？是否中心化？是否与平台服务关联？

建议提交《Token经济模型说明书》，附上图解、时间表、智能合约摘要。

Q672：MiCA是否强制披露Token持有人分布？

答：是。以下内容需在申请时或Token发行前披露：

  • 前十大持有人钱包地址；

  • 项目方/员工/VC/合作方持币数量；

  • 是否存在锁仓期、解锁时间表；

  • 若为DAO项目，需说明投票权与治理权如何分配。

推荐附带《Token持有人结构表》+《解锁计划图表》。

Q673：MiCA对平台是否允许提供“杠杆交易”？

答：MiCA 并未直接禁止杠杆，但有如下监管要求：

  • 若平台提供杠杆（如3x、5x），将被视为“加密衍生品服务”；

  • 可能需申请MiFID许可而非仅MiCA；

  • 杠杆产品必须披露风险、设立追加保证金机制、强平机制；

  • 需额外风控系统、客户适当性评估、模拟测试功能。

⚠️ 一般MiCA初期不建议申请杠杆服务，除非已有欧洲衍生品运营经验。

Q674：MiCA是否禁止平台设立多币种钱包？

答：不禁止，但必须满足：

  • 每一种虚拟资产（Token）需提供独立托管与操作记录；

  • 必须区分客户自有资产与平台自营资产（防止混合）；

  • 每一种资产应有冷钱包配置、多签机制、权限分层；

  • 平台需提供资产分类账或链上映射机制。

建议附《多币种钱包系统架构图》和《权限管理制度》。

Q675：MiCA是否允许设立DeFi与CeFi混合业务平台？

答：可以，但要符合以下条件：

  • CeFi部分（法币兑换、账户托管、撮合交易）必须由MiCA牌照主体承接；

  • DeFi部分必须具备明确的治理机制、安全审核机制；

  • 平台需清楚划分两者之间的资产流转与责任边界；

  • 客户必须在接入前同意相关声明（免责声明、技术风险说明等）。

可提交《DeFi-CeFi业务边界图》与《DeFi模块合规说明书》。

Q676：MiCA是否允许平台参与NFT交易或发行？

答：MiCA主要针对可转让、可交换型加密资产，纯NFT并非其监管范围：

  • 若NFT具有金融属性、可分割、可转让，可能落入MiCA范围；

  • 平台如提供NFT发行/交易服务，需说明其非证券化/非衍生性；

  • 若NFT绑定现实权益（如门票、产权），可能落入其他欧盟监管框架；

  • 不建议以MiCA CASP身份主导NFT交易所运营。

可附《NFT非金融属性法律意见函》。

Q677：MiCA是否要求平台披露收入模式？是否要提供“盈利路径”说明？

答：是，BoL非常重视平台“可持续性与风险自负能力”：

  • 商业计划必须披露收入来源（手续费、上币费、托管费等）；

  • 如涉及第三方合作收入，应列明合约机制；

  • 若平台短期内无盈利计划，需列明融资计划与支持资金来源。

推荐附上《平台营收模型图》与《三年财务预测表》。

Q678：MiCA是否允许使用加密货币缴纳手续费？

答：允许，但有条件：

  • 必须在《客户协议》中说明；

  • 应设定结算周期（如每日按USDT/BTC结算平台手续费）；

  • 客户交易账单应标明费用币种与等值法币金额；

  • 应具备实时价格转换机制与价格来源说明。

建议系统集成CoinGecko或Chainlink喂价模块。

Q679：MiCA平台是否可以开展空投活动（Airdrop）？

答：允许开展空投，但需合规处理：

  • Airdrop必须说明目的（市场推广、奖励机制）；

  • 不得向未完成KYC客户空投可交易Token；

  • 若Airdrop涉及Token权益、后续交易或治理权，需向客户披露风险；

  • 若空投Token为证券属性Token，可能触发额外牌照义务。

建议附《Airdrop风险披露模板》与用户签署机制。

Q680：MiCA平台可否通过Launchpad发行新Token？监管如何判断？

答：可通过Launchpad进行发行，但受以下监管标准限制：

  • 平台不得直接推荐投资行为；

  • 必须评估发行Token是否为可转让证券（Transferable Crypto-Asset）；

  • 必须披露发行方、募资用途、分配比例、锁仓机制等；

  • 应向BoL提交《白皮书摘要》及风控说明；

  • 若多个Token集中发行，平台可能承担监管中介责任。

⚠️ Launchpad如具撮合或推荐性质，建议同时考虑是否需MiFID许可。

Q681：MiCA是否允许平台提供Staking（质押）服务？如何合规？

答：允许，但需满足以下合规条件：

  • 明确区分平台自营Staking与中介Staking；

  • 客户资产需托管隔离、并清楚列明质押收益、风险；

  • 平台不得承诺固定收益（避免构成投资合同）；

  • 若Staking涉及第三方协议（如ETH 2.0），需披露技术与对接方式；

  • 应有《Staking服务协议》、《收益计算公式说明》、《风险提示书》。

推荐配置Staking流程图 + 风险评估报告，附加法律意见书说明非构成基金或金融工具。

Q682：MiCA是否允许提供加密货币借贷服务？

答：MiCA框架原则上不涵盖借贷服务，但若平台同时提供此类业务，监管重点包括：

  • 是否涉及利息或收益回报；

  • 借贷对象是否为平台内其他用户或平台本身；

  • 借出资产的风险是否已被明确披露；

  • 是否设有风控机制（抵押、清算逻辑等）；

  • 此类服务可能需另外获取欧盟信贷或贷款牌照。

建议附《Crypto Lending合规架构图》及第三方法律意见。

Q683：MiCA是否要求对客户资产设立“破产隔离机制”？

答：是。MiCA规定CASP必须确保客户资产在平台破产情况下可被优先保护和分离：

  • 需设立独立账户托管机制；

  • 客户资产不可与平台运营资金混用；

  • 客户资产需标记归属（可通过链上或系统账户结构实现）；

  • 在破产清算时，资产应优先归还客户，不得用于偿还平台债务。

推荐附《客户资产隔离系统说明书》+ 破产场景模拟应对文档。

Q684：MiCA是否允许使用DAO形式申请牌照？

答：原则上允许，但需满足如下硬性条件：

  • DAO必须在立陶宛或其他EU国家注册为法人（如UAB）；

  • DAO的治理结构、投票机制、核心成员须透明、可识别；

  • DAO应指定一名法人代表或实体承接法律责任；

  • 若Token治理与平台运营结合紧密，需披露其治理流程与风控。

推荐提交《DAO法人化结构图》+《DAO治理机制说明》+ 法律意见函。

Q685：MiCA是否接受新创平台无历史运营记录申请？

答：接受，但需重点提供如下内容以增强可信度：

  • 完整的商业计划书 + 三年财务预测；

  • 明确的资本来源及储备说明；

  • 团队成员背景材料、以往合规经验；

  • IT系统样机或演示环境；

  • 拟上线Token的架构与用途说明。

推荐引入技术合规顾问预审报告，附模拟运行截图或代码审计报告。

Q686：MiCA是否接受以“白标平台”方式运营的申请？

答：接受，但要求透明披露与合规控制：

  • 申请主体为平台运营者，不得完全依赖白标提供方处理核心系统；

  • 白标系统提供方需签订《IT外包协议》；

  • 平台应保留系统完全访问权、日志审查权、应急切换方案；

  • 仍需满足冷钱包控制、权限审批、风控审核等MiCA技术要求。

建议附《White-Label平台架构图》+ 双方合规分工说明书。

Q687：MiCA是否要求设置“灾难恢复机制”（Disaster Recovery Plan）？

答：是。所有MiCA平台必须制定全面的灾难恢复计划：

  • 包括系统宕机、电力/网络故障、黑客攻击等应急预案；

  • 明确RTO（恢复时间目标）和RPO（数据恢复点目标）；

  • 需设置数据备份机制，异地存储；

  • 每年应进行至少一次模拟演练并保存记录。

推荐提交《DRP灾难恢复制度手册》+ 年度演练报告模板。

Q688：MiCA是否允许“算法稳定币”作为平台流通货币？

答：监管持审慎态度：

  • 若稳定币不由法币支持，而依靠算法机制（如UST模式），BoL可能认为其具高度风险；

  • 平台如采用此类Token支付手续费或结算，应提交完整经济模型、风控机制、法律意见；

  • 不建议以算法稳定币作为客户资产计价或保证金币种。

建议使用MiCA下授权的电子货币代币（EMT）或资产参考代币（ART）作为平台主币。

Q689：MiCA平台是否需建立“Token上架审核委员会”？

答：非强制要求，但极为推荐设立：

  • 该委员会应包括：法律顾问、合规官、技术顾问、RO；

  • 审核内容包括：Token合法性、合规属性、经济模型、项目方背景、审计状态；

  • 审核过程需保留记录，并设立打分机制或拒绝理由存档；

  • 可形成《Token Listing决策备忘录》。

建议附《上币审核制度》+《决策委员会组成人员简表》。

Q690：MiCA平台是否可结合Open Banking或PSD2接口提供欧元充值？

答：可以，若符合如下条件：

  • 合作方为具PSD2许可的支付机构；

  • 用户通过IBAN充值或欧元转账，系统接入开放银行API；

  • 平台应保留资金来源追踪、对账能力；

  • 客户应签署同意授权，平台不得保存网银凭证。

可提供《欧元充值流程图》+《PSD2服务协议副本》+ 法律意见函。

Q691：MiCA平台是否允许非欧盟公民作为最终受益人（UBO）？

答：允许，但需满足以下条件：

  • 受益人必须完成KYC与背景尽调；

  • 若UBO来自高风险第三国（FATF黑名单或灰名单国家），需提供额外合规资料，如资金来源证明；

  • 平台必须确保UBO不会构成监管障碍，BoL对高风险国家UBO可能启动“增强尽职调查”（EDD）程序；

  • 必须提供控股路径结构图，并清楚揭示最终控制人。

推荐附《UBO结构穿透图》+《资金来源合法性声明》+《FATF国家名单核查表》。

Q692：MiCA对高管任职有年龄或学历限制吗？

答：无明确年龄或学历限制，但需满足“胜任能力”标准：

  • 至少应有金融、合规、技术、法律等相关背景；

  • 应能证明其曾在受监管机构或大型金融科技公司担任实质角色；

  • 高管需提供无犯罪记录、破产记录、反洗钱违规记录等；

  • 推荐提供学历、资历证明、工作推荐信。

⚠️ 若申请人有重大不良记录，将可能被BoL或ESMA拒绝。

Q693：MiCA平台是否可以设置“推荐返佣机制”？

答：允许，但需合规设置：

  • 所有推荐行为需透明、公平、无误导性陈述；

  • 推荐佣金应明确披露，并列明计算方式、发放周期；

  • 推荐人如为KOL、媒体、第三方代理，可能需作为CASP子服务申报；

  • 不得向未注册用户或匿名账户发放推荐收益。

建议附《Referral机制白皮书》+《推荐人KYC登记表》+ 佣金支付报告模板。

Q694：MiCA平台是否能直接提供“多语种”客户支持界面？是否有语言合规要求？

答：可提供多语种支持，但需符合如下标准：

  • 官方合规文件（如服务协议、风险披露、白皮书）应至少提供英文版本；

  • 若客户主要为立陶宛本地，应提供立陶宛语支持；

  • 多语种内容不得与官方英文内容存在“实质性出入”；

  • 若客户投诉因翻译误解产生，平台应承担说明与澄清责任。

建议准备《多语种法律一致性对照表》与《合规用语术语表》。

Q695：MiCA平台是否需为客户提供“月结账单”或交易对账单？

答：是。平台应向客户提供定期交易与资金流对账资料：

  • 包括客户的交易记录、资产余额、充值提现明细；

  • 每月、每季度或按客户要求生成电子账单；

  • 必须在账户界面可查、可导出PDF/CSV；

  • 所有数据需保存至少五年。

推荐使用自动账单生成系统，符合MiCA对客户信息披露要求。

Q696：MiCA平台能否在平台内提供“教育内容”或模拟交易？

答：允许，且受到鼓励，但需注意内容中立性与免责声明：

  • 教育内容应客观中立，不构成投资建议；

  • 模拟交易系统应与真实交易系统逻辑一致，但不得误导客户认为其为真实盈利；

  • 教学内容应标示来源，如投资风险披露、交易机制讲解等。

建议准备《教育内容发布合规框架》+《免责声明模板》。

Q697：MiCA是否对“平台命名”有监管限制？如含“银行”、“证券”等字样？

答：是。平台名称不得：

  • 使用“银行”、“信用社”、“证券公司”等可能误导为持有其他金融牌照的字样；

  • 使用“欧盟认可”、“官方”、“监管” 等官方背书性语言；

  • 建议平台名与法律注册主体一致，或在官网上清楚标注运营实体。

BoL保留要求修改名称或标识的权利，建议提供《品牌使用合规说明》。

Q698：MiCA平台是否需要在官网展示持牌信息？

答：是，属于强制性信息披露义务：

  • 须在网站首页或明显位置展示：CASP许可证编号、核准日期、监管机构信息（如BoL）；

  • 建议同时展示《服务条款》《隐私政策》《AML政策》《联系方式》等；

  • 客户如无法验证牌照信息，可申诉至ESMA或BoL。

可制作“信任页”展示合规资质及合作伙伴信息，增加用户信任度。

Q699：MiCA平台是否可以设立“API接口”对接第三方交易工具？

答：可以，但必须满足：

  • 第三方工具应通过认证或API密钥授权；

  • 客户应自行授权、并知悉自动化交易风险；

  • 平台应对API访问频率、权限、撤单机制等设定限制；

  • 若第三方接口涉及自动下单、套利、量化交易，建议纳入合规监控机制。

推荐提供《API使用政策》与《接口访问风险说明书》。

Q700：MiCA是否允许平台进行“链上数据公开审计”？是否有合规价值？

答：是且非常鼓励，属于合规最佳实践：

  • 平台可将托管地址、交易处理逻辑、资产存储路径、冷钱包转账等信息链上公开；

  • 可定期提供Merkle Tree资产证明、链上审计报告；

  • 第三方可验证是否“挪用客户资产”；

  • 可通过ZK方式增强隐私但保留审计可能性。

可提供《链上资产公开框架说明书》+《Merkle Audit API接口文档》。

Q701：MiCA是否强制要求平台支持多签钱包（Multi-sig Wallet）？

答：不强制，但高度推荐。MiCA并未明确要求采用多签钱包，但根据《客户资产保护》章节中提及：

  • 平台应实施权限分层机制，防止私钥单点故障；

  • 多签结构（如2/3、3/5）是当前监管首选方案之一；

  • 应与冷钱包结合，形成离线审批流程；

  • 所有签名人（Signatories）应具名备案，执行审批日志保存 ≥ 5年。

附件建议：多签结构图解 + 权限审批制度 + 离线冷签步骤图。

Q702：MiCA平台如因技术事故导致客户资产受损，是否需全额赔偿？

答：视具体责任划分。MiCA并未规定绝对赔偿义务，但：

  • 若事故因平台技术失误、合规疏忽或安全缺陷，平台可能承担全部或部分赔偿责任；

  • 平台应持有责任保险，用于应对此类事故；

  • 强烈建议设置《赔付机制制度》+ 客户协议中明确相关赔偿流程；

  • 客户有权就争议提请BoL或ESMA审理。

强烈建议设立赔付准备金账户或投保专业技术责任险（如Tech E&O或Cyber Liability）。

Q703：MiCA是否限制平台Token经济模型中含“销毁机制”或“通缩机制”？

答：允许，但需说明机制合理性并透明披露：

  • 所有“销毁”应基于真实收入或手续费来源，不能人为操控；

  • 必须写入白皮书与Token说明书，解释其作用与影响；

  • 若平台回购销毁，视同“间接盈利分配”，应声明资金来源合规；

  • 销毁地址应链上公开、永久冻结。

建议附《Token通缩机制说明图》+ 销毁记录链接。

Q704：MiCA平台是否可以与境外（非欧盟）VASP互转资产？

答：可以，但需履行“转账溯源”（Travel Rule）义务：

  • 出口/入口转账应交换双方VASP信息（包括名称、注册地、客户KYC资料等）；

  • 合作方应为“合规等效VASP”（如受FATF认可管辖）；

  • 建议平台设置Transfer Rule API接口进行实时验证；

  • 若对方VASP拒绝回传信息，平台应中止交易并记录。

附件建议：《跨境转账合规声明》+ VASP名录白名单清单。

Q705：MiCA是否允许设立“内部市场做市商”（Internal Market Maker）？

答：允许，但需区分：

  • 若平台本身作为做市商，需完整披露内部交易对手身份；

  • 做市商交易数据应隔离存储，与客户交易区分；

  • 禁止操纵价格、虚假流动性、欺骗性挂单；

  • 建议引入“做市商管理制度” + 每月提供透明做市报表。

推荐设置：做市商账户标识 + 系统级交易权限管理模块。

Q706：MiCA平台是否可与去中心化协议对接（如Uniswap、Aave等）？

答：可技术接入，但须承担“合规中介义务”：

  • 平台需就接入协议披露其安全性、项目方背景；

  • 须设立“DeFi接口使用协议”，告知用户其并非法定合规交易对手；

  • 所有用户资金流入DeFi协议前需审核是否存在黑名单、违规风险；

  • 接入DeFi不可构成监管套利或隐瞒真实交易。

建议附：DeFi对接框架图 + AML对接清单 + 风控交互流程图。

Q707：MiCA平台是否可开展NFT交易功能？

答：MiCA本身不适用于**“非金融型NFT”**，但：

  • 若NFT具备可分割性、投机性、金融回报预期，可能被视为可转让资产，纳入MiCA范畴；

  • 平台如同时运营NFT，应对其是否属MiCA监管范围作出法律意见说明；

  • 所有NFT交易仍应遵守KYC/AML、客户资产隔离、审计等要求；

  • 不建议通过NFT规避Token监管。

建议附：NFT分类说明 + 司法判断指南（附ESMA或BoL立场文档）。

Q708：MiCA是否要求平台上线前必须完成渗透测试（Penetration Test）？

答：是。MiCA第6.3节明确：

  • 平台上线前需完成至少一次独立第三方渗透测试；

  • 建议涵盖Web端、APP端、API端、钱包系统、冷存储路径；

  • 报告应附漏洞等级评估、修复建议、响应证明；

  • 每年至少复测一次，并保存全部测试档案 ≥ 5年。

附建议：《渗透测试报告模板》+ 年度网络安全测试计划表。

Q709：MiCA是否允许平台进行“预售Token”或“空投营销”？

答：允许，但应划清合规边界：

  • Token预售应披露完整信息文件（Information Document），包括价格机制、认购者权利、风险提示；

  • 空投应避免构成诱导投资或违反GDPR（如未经同意收集邮箱/钱包地址）；

  • 预售/空投不得等同于非法募资、证券发行；

  • 建议平台提供参与说明书、条款协议与退出机制。

附建议：《预售披露文件模板》+《空投活动合规指引》。

Q710：MiCA平台是否可以“Token抵押作为客户信用额度”？

答：视是否构成借贷或担保：

  • 平台如提供“Token抵押 + 可用额度”模型，须建立风控清算机制；

  • 可能构成“借贷服务”，需额外合规意见；

  • 抵押率应根据Token流动性与波动率计算，不建议使用高波动代币作为抵押；

  • 客户需签署《抵押协议》并披露所有风险。

附建议：《抵押额度生成公式》+《强平机制流程图》+ 法律意见函。

Q711：MiCA平台是否可以对用户设立最低充值金额或最低交易金额？

答：可以，属于平台商业决策范围，但需确保：

  • 最低金额设置不得构成不公平歧视，须一致适用于所有客户；

  • 如涉及金融包容性问题，建议提供明确理由（如反洗钱、操作成本、风险控制等）；

  • 建议在《服务条款》或《费用说明》中明示该设置；

  • 若因监管要求（如高风险国家）设置更高门槛，需附合规说明。

建议准备：《账户门槛说明书》+《风险分层与最低交易限制表》。

Q712：MiCA平台是否可以提供“联合账户”功能（Joint Account）？

答：允许，但需合规管理：

  • 联合账户应指定每位实际控制人（Joint Controllers）并完成KYC；

  • 资金授权操作应记录所有成员同意，设置联签或审批机制；

  • AML风险会提升，需加强交易监控与行为建模；

  • 禁止用于混淆真实受益人或进行代持安排。

附件建议：《联合账户管理政策》+《成员授权审批流程图》。

Q713：MiCA是否强制要求平台进行“员工背景调查”？

答：是，尤其对核心岗位（如RO、MLRO、系统管理员）：

  • 入职前应完成无犯罪记录查询、资历验证；

  • 若涉及技术关键权限，应进行道德操守与前雇主评价调查；

  • 每年应对关键岗位员工进行持续信任评估；

  • 建议设立《员工背景审查政策》与存档机制。

附：《关键岗位背景审查清单模板》+《道德声明书》样本。

Q714：MiCA是否要求平台在欧盟境内设有“数据中心”？

答：强烈建议，但不强制：

  • 客户数据应存储在EEA（欧洲经济区）或等效GDPR管辖区；

  • 若使用境外数据中心（如AWS、新加坡），需确保合同包含GDPR适当保障措施（SCC或BCR）；

  • 建议平台提供《数据流向图》与《境外数据托管合规审查报告》。

附：《GDPR跨境数据传输评估报告》+《数据主权说明信》。

Q715：MiCA平台是否必须与银行建立客户隔离账户（Client Segregated Account）？

答：是，为保护客户资金：

  • 客户资金必须与平台自有资金彻底分离；

  • 建议在欧盟受监管银行设立“客户信托账户”或“指定用途账户”；

  • 平台应可随时出具对账证明与资金归属函；

  • 不得擅自挪用客户资金或混用；

附建议：《客户资产分离账户说明书》+ 银行出具的资金托管信。

Q716：MiCA是否允许提供“杠杆交易”或“保证金服务”？

答：MiCA本身并未直接禁止，但监管较为谨慎：

  • 如平台拟提供杠杆功能，应额外申请《投资服务许可证》或适用EMIR相关牌照；

  • 杠杆比例应设限（如不超过3倍），且需充分揭示风险；

  • 客户必须完成《适当性评估》后才可开通；

  • 所有杠杆交易应有强平机制，防止负债滑点。

附：《杠杆交易用户评估表》+《强制平仓规则流程图》。

Q717：MiCA对客户身份识别是否接受“远程KYC”（如视频认证）？

答：接受，但必须满足真实性、完整性和可追溯性：

  • 可采用视频KYC、人脸识别、电子签章等；

  • 所有远程流程应留存操作记录、时间戳、原始影像资料；

  • 若识别失败，应立即触发人工复核流程；

  • 平台应配合BoL及税务部门对KYC数据调取与审计。

建议提供：《远程KYC操作流程图》+《系统取证能力白皮书》。

Q718：MiCA是否允许平台提供“子账户”功能（如主账户下多个子钱包）？

答：允许，适用于机构客户或家族办公室结构：

  • 每个子账户必须独立编号，可配置不同权限；

  • 交易与资金划转应留有清晰轨迹，并可供审计；

  • 若子账户为他人代开，需附上受益人及授权人完整KYC；

  • 禁止以子账户方式规避AML或交易限额。

建议制作：《子账户权限配置表》+《家族结构授权说明书》。

Q719：MiCA平台是否必须保留用户日志和系统访问记录？保存多久？

答：必须保留，且保存期限为不少于5年：

  • 应包括：用户登录记录、交易请求、钱包地址调用、权限更改、审批流程等；

  • 所有日志应不可篡改，可用于合规审计与事件溯源；

  • 日志应定期备份至安全服务器；

  • 高风险事件应单独加密归档（如疑似洗钱行为日志）。

附：《系统日志结构样本》+《五年归档计划说明》。

Q720：MiCA是否允许平台“以Token支付交易手续费”？

答：允许，但需以下设置：

  • 必须明示Token结算方式、汇率来源、转换规则；

  • 手续费结构必须写入服务协议，并保持公开透明；

  • 若用于支付的Token为平台自发行，需防止利益冲突（如动态定价操控）；

  • 建议提供“费用计算器”页面供用户预估成本。

附建议：《Token支付机制说明书》+《手续费计算规则披露文件》。

Q721：MiCA监管下，是否必须公开客户的所有钱包地址？

答：不强制公开所有地址，但平台必须实现内部可追踪性：

  • 客户的每一个钱包地址必须与其实名账户绑定；

  • 平台须确保地址与客户之间的映射在后台可审计；

  • 若平台对外展示客户地址（如排行榜、链上透明度），需获客户同意并隐去敏感信息；

  • 建议设置地址标签系统用于监管溯源，但避免泄露隐私。

附建议：《地址实名绑定结构图》+《钱包地址内部映射存证机制》。

Q722：MiCA是否允许平台对部分资产进行“托管服务外包”？

答：允许，但外包方必须是合规注册机构，且：

  • 平台需对外包方进行尽职调查，并保留文件；

  • 双方签订《资产托管服务合同》，明确责任划分、访问权限、应急措施；

  • 平台仍需对客户资产负最终责任；

  • 所有客户资金变动必须能实时查询与审计。

附件：《托管服务协议模板》+《托管机构审查报告模板》。

Q723：MiCA平台是否可以通过API方式为B端客户提供服务？

答：可以，但平台需对接入方负有监管责任：

  • B端客户需完成KYC与尽职调查；

  • 所有API调用必须有权限验证、行为监控及反滥用机制；

  • 建议设置“访问频率限制 + 白名单机制”；

  • 平台应为API服务制定《开发者政策》和《终端使用限制协议》。

附建议：《B端对接协议模板》+《API调用合规日志结构图》。

Q724：MiCA监管下是否允许“链上撮合”？还是必须“平台内撮合”？

答：MiCA不禁止链上撮合，但：

  • 若使用链上撮合机制，平台仍需履行所有KYC、AML与资金归集责任；

  • 系统需能导出完整的链上交易路径，并与用户身份匹配；

  • 若使用DEX型撮合引擎，需确保其无法绕开监管审查（不可“链上匿名执行”）；

  • 建议仅将链上撮合用于合规白名单资产的透明交易场景。

附建议：《链上撮合合规说明书》+《撮合模式切换逻辑图》。

Q725：MiCA平台是否可以支持“Token换Token”的交易（Swap服务）？

答：允许，需视为“资产间兑换”服务：

  • 必须标明费率、滑点限制、汇率机制及撮合路径；

  • 禁止以Swap形式掩盖未经披露的交易（如代币置换私募）；

  • 客户需清楚确认兑换价格、最终数量及可能成本；

  • 若使用第三方流动性（如DEX），仍需执行交易审查。

附建议：《Token兑换服务协议》+《Swap流程审计图解》。

Q726：MiCA是否要求对所有系统模块进行代码审计？必须第三方执行吗？

答：强烈建议由独立第三方完成完整审计：

  • 审计内容包括：撮合引擎、钱包管理、KYC模块、权限管理、交易日志、安全日志等；

  • 报告应列明漏洞等级、修复进度、审计结论；

  • 若为开源组件，应验证其安全版本与合规授权；

  • 建议每年至少一次全面审计，并结合重大版本上线节点评估。

附建议：《MiCA系统代码审计清单》+《第三方审计报告范本》。

Q727：MiCA是否接受使用“硬件钱包（如Ledger）”作为冷钱包？

答：接受，前提是：

  • 冷钱包必须可控、可监审、可生成签名审计记录；

  • 钱包应设在离线环境中，配合多签结构使用；

  • 所有取出资产操作需具备完整审批轨迹及签名验证；

  • 建议设立“冷热资金转移审批制度”，与私钥托管制度配合执行。

附建议：《冷钱包安全管理制度》+《硬件签名流程操作文档》。

Q728：MiCA平台是否可以将交易历史与报表功能开放给用户导出？

答：必须提供导出功能，属于**数据可携权（Data Portability）**的一部分：

  • 平台应提供清晰的交易记录、对账单、资产明细等下载方式（如CSV、PDF）；

  • 若客户请求交易日志归档，平台应在合理时间内提供；

  • 所有历史记录应保存≥5年，即使客户关闭账户亦适用；

  • 建议在用户后台设置统一“数据导出中心”。

附建议：《用户交易记录导出指引》+《可携权制度说明》。

Q729：MiCA平台是否可设立“VIP等级”或“会员系统”？是否构成歧视？

答：允许，只要机制公开、透明、无违法歧视成分：

  • 不得因种族、国籍、宗教、性别设限；

  • 可以按交易量、资产额、活跃度分层，但需在官网说明积分机制与权益；

  • 若设有“专属客服、手续费折扣、提现通道优先”等，需公平执行并定期审计；

  • 不得以VIP等级影响客户账户的风控设置与合规处理。

附建议：《VIP等级设定方案》+《会员权益政策文件》。

Q730：MiCA是否允许平台对客户收取“托管服务费”？

答：允许，但必须明示费用项目与计算方式：

  • 可采用按日计息、按月固定费用、按存量资产比例等形式；

  • 收费机制应写入用户协议、费用表；

  • 不得在客户未明示知情的前提下直接扣费；

  • 建议托管费用设定不超过合理市场平均水平，并设置上限保障机制。

附建议：《客户资金托管费用明细表》+《收费项目白皮书》。

Q731：MiCA平台是否可以发行“内部积分”或“非上链代币”？是否受MiCA监管？

答：若内部积分不具备转让性、不用于融资或支付，不属于MiCA监管范畴：

  • 可作为平台奖励机制（如交易返利、活动积分）；

  • 不可与加密资产兑换、流通，不得承诺升值或公开转让；

  • 建议在用户协议中明示“积分不具备金融价值、不适用MiCA”。

附件：《积分使用条款》+《非链上资产声明模板》。

Q732：MiCA平台客户账户余额是否需要逐笔对账？

答：需要，且至少每日对账一次：

  • 客户资金、资产、挂单、冻结项必须每日盘点；

  • 平台需生成自动化对账报表，保留审计记录；

  • 建议设置“平台自有账户”与“客户资金池”分离对账机制；

  • 审计师可随时抽查对账准确性。

附件：《客户资产每日对账模板》+《异常处理机制说明书》。

Q733：MiCA平台是否可以限制客户的交易时间段？如仅工作日交易？

答：允许，但需披露规则并保持一致性：

  • 可出于运维、风险控制或人工审核等原因设定时段；

  • 不得歧视特定客户群体；

  • 平台应在服务条款中明示交易窗口时间与例外场景；

  • 强烈建议保留紧急下单渠道用于客户紧急资金提取或止损。

附：《交易时间说明信》+《应急处理SOP》。

Q734：MiCA是否强制平台配置“本地数据审计功能”？

答：强烈建议配置“可本地验证、原始数据不可篡改”的审计结构：

  • 审计模块需记录每笔交易请求、指令响应、撮合日志、签名验证；

  • 应支持监管导出API（如BoL核查、欧盟税务合作）；

  • 所有审计数据应可时间戳封存（如使用Hash或区块链存证）；

  • 推荐每季度内部审计一次，重大更新后复审。

附：《审计系统设计图》+《审计记录格式样本》。

Q735：MiCA平台是否可以使用外包合规顾问（External Compliance Officer）？

答：可以，但仅限非核心角色：

  • MLRO（洗钱报告官）与RO（负责人）需为内部人员或法定代表；

  • 外包顾问可协助完成AML审计、报告撰写、监管答复等；

  • 须签署保密协议与责任分工协议，平台仍为合规总负责人；

  • 建议每季度向董事会提交外部合规工作汇报。

附：《合规外包服务协议模板》+《顾问月度报告模板》。

Q736：MiCA是否强制平台披露“交易对手方”信息？

答：不强制公开披露，但平台需能识别交易对手方身份：

  • 若为P2P撮合，平台需对双边账户完成KYC验证；

  • 若为B端流动性来源（如做市商），需签署《合规声明》并接受定期审查；

  • 对监管机构提出请求时，平台应可提供完整对手方信息路径；

  • 不建议公开交易对手信息以避免泄露交易策略或客户身份。

附：《P2P撮合对手方KYC记录表》+《流动性提供者尽职审查模板》。

Q737：MiCA是否允许平台用户直接导入“外部钱包”资产？是否需KYT追踪？

答：允许导入，但必须执行KYT（Know Your Transaction）审查：

  • 系统应对导入地址进行链上风险评级（如与黑市、赌博、Mixer有关）；

  • 可使用Chainalysis、Elliptic等工具建立自动拦截机制；

  • 客户导入资产必须匹配其KYC信息，避免他人代充；

  • 若高风险地址尝试导入，应直接拒绝并记录可疑行为。

附：《地址KYT审查策略文件》+《客户导入资产行为日志表》。

Q738：MiCA平台是否需要设置“提现冷静期”或“风控暂停期”？

答：建议设置，特别是高风险行为或大额资金异常流动时：

  • 冷静期（Cooling-off）为系统自动冻结提现的时间窗（如6小时内不可提现）；

  • 可结合设备更换、地址变更、频繁下单等行为触发；

  • 应公开政策并允许用户申诉或加急处理；

  • 若客户被风控冻结，需自动生成《冻结原因说明》。

附：《提现限制政策白皮书》+《异常冻结告知模板》。

Q739：MiCA监管是否接受平台设置“预警阈值 + 审批机制”防止系统操作异常？

答：强烈推荐设置：

  • 含自动转账、权限修改、系统参数变更等行为，设预警与审批机制；

  • 系统应设定操作触发量、阈值、频次等；

  • 所有审批动作应留痕（日志、签名、审批人）；

  • 平台应设有突发情况人工复核入口。

附：《风险操作预警机制设计说明》+《系统审批流程图》。

Q740：MiCA平台是否允许设立“应急备用服务器”或“灾难恢复中心”？

答：不仅允许，且为强制合规要求之一：

  • 平台必须具备业务连续性（BCP）与灾难恢复计划（DRP）；

  • 建议至少设立两个数据备份站点，隔地部署；

  • 每年需进行至少一次灾备演练并形成记录；

  • 若发生服务中断，平台需在1小时内启动备份恢复流程。

附：《业务连续性手册模板》+《年度灾备演练报告》。

Q741：MiCA牌照下的“客户适当性评估”是否适用于所有投资型代币？

答：是的。凡属于 MiCA 监管下具有投资属性、价值波动风险的加密资产均须进行适当性评估：

  • 包括：资产参考代币（ARTs）、电子货币代币（EMTs）以及其他具备金融效用的代币；

  • 评估内容应涵盖：客户风险承受能力、经验水平、资产来源、投资偏好；

  • 须设有问卷系统并保存记录 ≥5年；

  • 平台若将风险资产开放给不适当客户，将面临执法风险。

附：《MiCA客户适当性评估问卷模板》+《风险资产匹配引擎说明文档》。

Q742：MiCA是否允许平台运营“返佣计划”或“邀请奖励”？

答：允许，但需防范构成非授权招揽或潜在传销风险：

  • 所有返佣活动须明示规则、申报税务、合规备案；

  • 平台不得鼓励用户招揽不合适客户；

  • 建议设“一级返佣封顶”“实名注册才能返佣”等机制；

  • 必须保留返佣分发、账户结构与行为路径的记录。

附：《MiCA返佣合规手册》+《邀请机制风险识别报告》。

Q743：MiCA平台是否可为用户提供“资产组合推荐”服务？是否构成投资建议？

答：
MiCA对“组合建议”持审慎态度：

  • 若建议基于客户画像并指向特定资产组合，将视为投资建议；

  • 平台需持有相应MiFID II牌照，或由持牌顾问提供；

  • 可改为“算法评分+风险揭示+资产说明”的方式呈现；

  • 禁止带有“保本、保收益、涨幅预测”字眼。

附：《组合展示与投资建议合规分界指引》+《MiCA平台资产推荐模型说明》。

Q744：MiCA监管是否允许平台以“美元计价”而非“欧元”？

答：平台前端可展示多币种报价，但监管报告、会计结算、客户资产披露必须以欧元为基准：

  • EMT（电子货币型代币）若锚定美元，需说明汇率处理机制与风险披露；

  • 所有手续费、报表、储备资产审计均须转换为EUR；

  • 建议设定“EUR主账 + 外币子账”结构。

附：《多币种账户结构图》+《锚定非欧元资产合规指引》。

Q745：MiCA平台是否必须设立独立“内部稽核”职能？

答：是。平台必须建立独立于日常运营部门的稽核机制：

  • 负责审核：系统流程、客户投诉、反洗钱报告、权限变更、业务合规；

  • 稽核负责人可由董事会委任或设立独立审计委员会；

  • 每季度至少一次内部审查并出具报告；

  • 稽核结果应提交董事会并可供监管审阅。

附：《MiCA平台稽核制度模板》+《季度审计报告范式》。

Q746：MiCA平台在发生系统故障时，是否需要向监管报告？

答：是，MiCA要求及时报告所有重大营运事件：

  • 包括：系统崩溃、数据泄露、黑客攻击、交易中断、资金误划等；

  • 应在最迟24小时内提交《重大事件初步报告》；

  • 后续应在10日内补充《完整事故报告》；

  • 同时需向客户通报，并建立赔偿与补救措施。

附：《MiCA系统故障通报SOP》+《事故报告官方模板（英文+中文）》。

Q747：MiCA平台是否可设“交易滑点保护机制”？是否强制？

答：不强制，但强烈建议平台设定滑点容忍范围以保障用户利益：

  • 尤其适用于代币流动性薄弱或大单交易时；

  • 建议设置默认滑点≤1%，用户可自定义；

  • 平台应清晰提示“最终成交价可能与预期存在差异”；

  • 需记录滑点范围与成交价格以供审计。

附：《滑点控制配置图》+《滑点审计记录表模板》。

Q748：MiCA是否对平台广告宣传有具体限制？

答：有明确规范，禁止以下内容：

  • 虚假宣传（保本、收益率承诺、价格预测）；

  • 诱导性语句（如“一夜致富”、“错过即永远错过”）；

  • 需标注清晰风险声明；

  • 广告投放平台及素材内容须可供监管查询、保留≥5年。

附：《MiCA广告审查标准》+《广告素材归档模板》+《投放记录保存表》。

Q749：MiCA平台是否可以与“第三方KYC服务商”合作进行客户验证？

答：可以，但平台需承担最终责任：

  • 合作方必须具备欧盟GDPR合规资质与数据保护能力；

  • 须签署服务协议、责任协议，并保留每次KYC流程的链路记录；

  • 平台应能实时审计外部服务商的流程、数据准确性；

  • 建议保留本地KYC备份系统。

附：《KYC服务委托协议模板》+《合规KYC审计链路图》。

Q750：MiCA平台是否强制实施“双因子认证（2FA）”？

答：强烈建议，尤其适用于以下操作：

  • 登录、提现、交易下单、权限修改；

  • 2FA可采用：短信验证码、OTP应用（如Google Authenticator）、硬件Token；

  • 应设置“2FA失效提醒+异常设备告警”机制；

  • 客户关闭2FA需经过风险确认流程。

附：《MiCA平台账户安全机制白皮书》+《2FA配置操作指引》。

Q751：MiCA平台能否为企业客户提供定制化交易系统接入（API）？

答：可以，但须符合以下合规前提：

  • 接入客户必须完成企业KYC与董事尽职调查；

  • API权限需明确控制范围（仅限查询/挂单/撤单/下单等）；

  • 所有API调用日志必须记录、可回溯 ≥ 5年；

  • 若为代客交易，应落实“受权委托”与客户适当性责任；

  • 防止通过API绕过风控机制或洗钱。

附：《MiCA平台API使用合规指南》+《企业客户API接入协议模板》。

Q752：MiCA监管是否限制平台支持某些高风险国家/地区的用户？

答：MiCA允许平台依据风险等级模型排除高风险司法管辖区客户：

  • 建议采用FATF高风险国家名单、EU黑名单、联合国制裁国家；

  • 可将相关国家IP地址、KYC文件、银行卡信息设置为系统拒绝项；

  • 强烈建议公告客户禁止名单及理由，防止歧视投诉；

  • 合规记录应说明“禁止接收来源+内部审核流程”。

附：《高风险地区客户识别SOP》+《MiCA黑名单适用说明》。

Q753：MiCA监管是否要求“所有客户都必须实名制”？

答：是。无论交易金额、频率、功能，所有平台客户都必须完成实名KYC：

  • 不得设“游客模式”“交易前实名后实名”功能；

  • KYC包含：身份证件、地址证明、自拍照/活体验证；

  • 如为企业用户，还需核实UBO、控股结构；

  • 非实名客户账户应完全锁定所有功能。

附：《个人与企业KYC对照标准表》+《实名流程配置手册》。

Q754：MiCA平台能否提供“托管钱包 + 客户自主管理”的混合模式？

答：可以，但必须明确控制权划分与安全机制：

  • 托管钱包部分由平台统一管理私钥，确保资产安全；

  • 自主管理部分应明确“用户承担私钥责任”，平台免责；

  • 应支持双重备份、权限分层、冷热分离等方式；

  • 若采用“平台签名+用户签名”模式，须说明签名流程。

附：《托管与自主管理结构对比图》+《混合钱包责任说明协议》。

Q755：MiCA是否允许“非欧盟公司”控股MiCA平台？

答：允许，但须进行实质性审查（Substance + Fit & Proper）：

  • 非欧盟母公司需提交控股结构、合规背景、监管记录；

  • 须说明公司治理透明度、税务合规性；

  • 若母公司来自高风险司法区，可能遭附加要求或延长审查期；

  • 强烈建议设立欧盟境内全资子公司作为MiCA牌照持有人。

附：《控股公司穿透结构图》+《境外控股人合规问卷》。

Q756：MiCA平台如何设置“限制未成年人注册”机制？

答：平台应在KYC阶段自动筛查出生日期：

  • 不得接受18岁以下自然人注册；

  • 若客户篡改信息注册，平台仍须保留识别与处罚责任；

  • 建议加入“身份证件识别+活体验证+年龄比对”机制；

  • 对于企业账户，须确保法人/董事年龄合法。

附：《年龄验证机制说明书》+《未成年人账号管控流程图》。

Q757：MiCA监管是否要求平台支持“可下载交易对账单”？

答：是的，客户有权随时导出其完整交易历史：

  • 包含：每笔买入/卖出记录、挂单、撤单、手续费明细；

  • 应支持CSV、PDF等导出格式；

  • 建议设置“按时间段检索 + 按资产分类”功能；

  • 平台应保存客户账单 ≥ 5年，供审计/仲裁/税务使用。

附：《客户对账单格式模板》+《导出功能UX建议表》。

Q758：MiCA平台是否必须为客户设置“资产变动提醒通知”？

答：强烈建议，尤其在以下情形：

  • 大额充值/提现、异常登录、批量交易、权限变更；

  • 可通过短信、邮件、App内推送方式发送；

  • 所有通知内容应保留日志；

  • 可提供客户自定义提醒阈值及停用通知选项。

附：《MiCA平台客户通知机制设计手册》+《风险事件提醒场景清单》。

Q759：MiCA是否强制平台披露“合规官姓名”或MLRO信息？

答：不强制公开披露于官网，但需向监管机关备案：

  • 监管机构应能随时取得MLRO与负责人的联系方式；

  • 客户可通过“合规联系通道”间接与合规团队互动；

  • 平台应设有合规问题咨询通道，如表单、专属邮箱；

  • 建议平台合规官不得同时担任系统管理员或RO。

附：《合规部门职责与对外联系流程图》+《客户合规咨询处理流程》。

Q760：MiCA平台是否可以设立“社区DAO治理结构”？

答：可设立作为咨询或建议机构，但最终运营与合规责任不得转移至DAO：

  • DAO可用于平台改进建议、产品参数、上币投票；

  • 不得控制客户资产、技术权限、风控流程；

  • 若DAO成员可控制资金，需强制纳入适当人审查与监管审批；

  • 建议DAO仅设为“建议性”结构，并设代表负责与平台沟通。

附：《MiCA下DAO功能合规设计图》+《DAO治理章程建议模板》。

Q761：MiCA平台是否可以设立“模拟账户”供用户学习？是否受监管？

答：可以设立模拟账户，但应明确以下边界条件：

  • 模拟账户不可与真实账户交叉，且禁止模拟资金充值/提现；

  • 平台应标注“仅供教学目的、不构成投资建议”；

  • 禁止通过模拟账户进行任何诱导性推广或误导性展示（如：模拟收益排名）；

  • 若提供模拟交易历史，应区分系统撮合与用户实际行为。

附：《模拟账户合规使用声明模板》+《模拟数据使用限制协议》。

Q762：MiCA是否允许平台用户进行“杠杆交易”或“保证金交易”？

答：MiCA 并未直接禁止杠杆交易，但监管强度极高：

  • 平台需具备充分资本金、风险评估机制与强平机制；

  • 杠杆上限建议不超过5倍（部分国家限制在2倍以内）；

  • 所有杠杆产品必须明示风险及可能损失总额；

  • 必须对用户进行适当性测试，通过后方可开通杠杆权限。

附：《杠杆账户开通协议模板》+《爆仓预警及强平机制说明》。

Q763：MiCA牌照申请人必须设在立陶宛本地办公吗？是否可以远程办公？

答：MiCA要求实体运营中心设于立陶宛（或其他欧盟成员国）：

  • 合规官、MLRO必须设于当地，便于监管沟通与突击审查；

  • 其他岗位如客服、技术可远程办公，但需设欧盟数据处理镜像；

  • 办公场所应具备：文件保管空间、监管来访接待、数据隔离设施；

  • 租赁办公地址不可为虚拟办公室（Virtual Office）。

附：《MiCA运营场所最低要求清单》+《实地稽核准备指南》。

Q764：MiCA是否允许平台用户进行“点对点P2P交易”？

答：允许，但平台必须承担撮合方与合规监控方责任：

  • 所有P2P交易前必须完成KYC/KYB；

  • 交易前后应保存链上地址、交易对手、金额等信息；

  • 平台应保留仲裁机制并设“冻结争议资金”的权限；

  • 建议设置每日P2P限额 + 可疑交易自动识别系统。

附：《P2P交易风控模型》+《P2P争议解决SOP》。

Q765：MiCA是否对“平台技术系统架构”有合规性要求？

答：有明确要求，尤其包括以下几个方面：

  • 系统需具备高可用性、数据加密、用户权限分层等；

  • 所有客户指令、数据记录必须备份 ≥5年；

  • 需设冷热钱包分离机制，明确私钥保管方式；

  • 平台应制定《技术架构图》+《权限控制图》，接受监管审查。

附：《MiCA平台IT系统合规模板包》+《内部权限审批流程图》。

Q766：MiCA平台是否可以开设“稳定币托管子账户”？

答：可以，但需满足以下合规前提：

  • 仅限已注册的EMT类稳定币进行托管；

  • 平台应设“托管子账户 + 冻结控制权限”体系；

  • 所托管资产不可用于再投资，须独立会计处理；

  • 所有托管账目应由注册审计师按季度审计。

附：《稳定币托管协议》+《资产隔离结构图》。

Q767：MiCA平台是否需要在平台上披露“技术白皮书”？

答：强烈建议，尤其在代币发行或新功能上线前：

  • 白皮书应披露：系统设计、风控机制、运作逻辑、代码审计情况等；

  • 如平台自营代币（utility token），白皮书须在ECDB数据库登记；

  • 白皮书语言应清晰、透明、避免误导；

  • 建议公开历史版本并留有修改记录。

附：《MiCA合规技术白皮书结构模板》+《更新日志登记格式》。

Q768：MiCA监管是否允许“平台内转账”免手续费？是否限制？

答：允许，但必须符合法律透明与会计记录要求：

  • 平台内用户间转账可设置为0费用；

  • 必须记录每笔转账的发起人、收款人、时间、金额与用途；

  • 不得借“平台内转账”逃避AML/KYC/反恐融资审查；

  • 大额平台内转账应触发风控预警。

附：《平台内转账合规指南》+《内部转账稽核检查表》。

Q769：MiCA平台是否可以支持NFT交易？是否需要额外申请？

答：MiCA本身不直接监管NFT，但存在以下情况时视为受规管资产：

  • NFT本质上为可分割、可交易、具金融效用的“类证券”代币；

  • 若NFT平台附带理财、分润、回购等功能，需纳入MiCA监管；

  • 建议平台设“普通NFT专区”与“受监管NFT专区”加以区隔；

  • 若提供NFT衍生产品，则需额外申请金融工具牌照。

附：《NFT合规分类参考模型》+《NFT交易平台划分模板》。

Q770：MiCA是否要求平台必须提供客户服务（Customer Support）？是否有标准？

答：是，MiCA要求平台提供有效、可追溯、响应及时的客服机制：

  • 客服须覆盖平台营业时间，建议支持至少英语+立陶宛语；

  • 应设有：FAQ中心、邮件支持、在线工单、电话热线等；

  • 所有客服记录应备份 ≥ 5年，可供投诉处理与监管查验；

  • 高风险用户、企业客户应提供专属客服渠道。

附：《MiCA平台客服制度模板》+《客户投诉处理SOP》。

Q771：MiCA是否要求对客户资产实行“1:1准备金”制度？

答：是的。MiCA要求平台对客户资产实行全额准备金制度：

  • 客户资金不可用于平台营运或再投资；

  • 客户资产应与公司资产分离存放，并由银行或合规托管人保管；

  • 每日需结算客户余额与准备金余额是否相符；

  • 建议每季度出具独立审计报告作为佐证。

附：《客户资产准备金日核对模板》+《托管机构对账SOP》。

Q772：MiCA平台是否可以为用户提供“托管保险”？是否为强制？

答：非强制，但属于监管高度鼓励项：

  • 可通过合作保险公司为客户资产提供盗窃、黑客攻击保险；

  • 保险范围应明示是否包括私钥丢失、链上攻击等；

  • 须说明保险限额、免责条款及赔付机制；

  • 建议披露保险公司资质及合作协议摘要。

附：《托管保险合作协议范本》+《客户保险权益披露模板》。

Q773：MiCA是否要求平台设置“灾备机制”以应对系统中断？

答：是，平台必须具备完善的业务连续性与灾难恢复计划（BCP/DRP）：

  • 应包括：数据备份机制、冷备份地点、紧急通讯流程；

  • 灾备服务器应位于欧盟境内，数据加密存储；

  • 每年至少一次全面灾备演练；

  • 重大事故应在4小时内向监管机构报告。

附：《MiCA平台灾备机制标准模板》+《年检灾备演练报告模板》。

Q774：MiCA是否规定平台必须建立反欺诈机制？有哪些要求？

答：是，平台需配备以下反欺诈功能：

  • 异常交易识别算法（如账户被盗行为、秒充秒提）；

  • 登陆设备/行为分析系统；

  • 二次验证（2FA）、密码强度控制、IP异地登录拦截；

  • 对被识别为欺诈客户应自动锁定账户并上报监管。

附：《反欺诈策略与风险识别模型》+《欺诈行为事件上报模板》。

Q775：MiCA是否允许平台对客户交易设定“风控限额”？

答：允许，且被视为审慎风控管理一部分：

  • 可对不同KYC等级客户设定单日交易限额；

  • 高频交易、闪电交易账户可设更严格限额；

  • 用户可申请自定义限额，但须提交书面理由与合规审批；

  • 所有限额调整应有日志、审批记录，并报告MLRO。

附：《用户交易限额配置表》+《限额提升申请表模板》。

Q776：MiCA是否对“币种上线流程”提出具体要求？

答：是的，尤其适用于平台自营代币或平台首次支持的资产：

  • 必须进行《资产尽职调查》（包括法律、技术、安全性）；

  • 若为金融工具类代币，需符合发行人注册要求；

  • 应披露是否为稳定币、资产支持型代币，是否在ESMA登记；

  • 上线流程建议包括：合规审查、董事会审批、公告说明书。

附：《资产上线合规流程图》+《Token Listing评估模板》。

Q777：MiCA是否对“受益人（UBO）结构复杂”的公司客户设额外要求？

答：是。对于控股链路超过3层以上、存在信托/基金控股结构的客户：

  • 须提供完整穿透图、每一层级的KYC与控制人证明；

  • 必须识别最终自然人受益人并存档；

  • 对于匿名信托或境外SPV结构，平台应提出增强尽调（EDD）；

  • 可拒绝无法核实UBO结构的客户入场。

附：《复杂控股结构尽调表》+《UBO穿透验证工具说明》。

Q778：MiCA是否对客户“资金来源”作实质性审查要求？

答：是的。客户KYC必须包括“资金来源合理性”判断：

  • 对大额充值客户，应要求提供银行流水或收入来源证明；

  • 对频繁交易但资金异常者，建议进行反洗钱事件识别；

  • 建议建立“可接受资金来源白名单”：工资、企业盈利、资本利得等；

  • 不得接受匿名钱包、Mixer、Tornado Cash 等高风险来源。

附：《资金来源评估表》+《来源异常识别与上报流程》。

Q779：MiCA平台是否必须为用户提供“交易滑点控制”功能？

答：非强制，但建议具备如下功能以防客户误操作：

  • 限价单应默认“最大滑点阈值”（如：±1%）；

  • 用户可手动调整，但必须明确提醒风险；

  • 滑点控制应体现在交易确认弹窗、订单摘要等界面；

  • 若市场剧烈波动，平台应启动“撮合暂停”或“保护限价”机制。

附：《交易滑点控制策略模板》+《极端行情保护机制图》。

Q780：MiCA是否要求平台对员工进行合规培训？是否需要备案？

答：是。平台必须每年至少组织一次员工合规培训，并留档备案：

  • 内容应涵盖MiCA监管要点、AML/CTF/KYC制度、信息保密等；

  • 负责人需签署《培训参加确认表》，并附课程内容与参与记录；

  • 对关键岗位（合规官、技术官、客服）建议增设季度强化培训；

  • 可委托合规顾问或律师事务所执行培训任务。

附：《员工合规培训计划模板》+《年度合规培训记录表》。

Q781：MiCA平台是否可以通过API提供用户交易接口？是否受限？

答：可以，但API服务必须符合以下MiCA及欧盟数据安全要求：

  • API接口权限应分级管理，如只读/下单/查询资产等；

  • 对接客户（如策略交易客户）需完成KYC/KYB；

  • 必须提供API日志追踪与访问频率限制；

  • API密钥生命周期应可控，可随时吊销或更新；

  • 系统应防范DDOS、重放攻击、Token泄漏等风险。

附：《MiCA平台API安全对接白皮书》+《API访问风控模板》。

Q782：MiCA是否要求平台设立“多语言支持”？必须有哪些语言？

答：MiCA本身未强制多语言要求，但以下为监管建议标准：

  • 至少提供英语 + 立陶宛语服务内容（用户协议、平台规则）；

  • 面向其他欧盟成员国市场的，需覆盖当地语言；

  • 用户端界面、披露文档、警示文字应为用户可理解语言；

  • 客服渠道应有可切换语言或翻译支持。

附：《平台多语言支持清单模板》+《翻译内容合规审核指引》。

Q783：MiCA是否允许平台设置“推荐奖励”机制（Referral）？

答：允许，但必须遵守MiCA对营销活动的合规边界：

  • 推荐奖励不可与具体投资回报直接挂钩；

  • 不得出现“零风险”、“保本”、“稳赚不赔”等宣传用语；

  • 推荐机制应向监管备案，并有完整记录追踪；

  • 高风险客户不得通过推荐机制绕过合规审查。

附：《推荐奖励机制合规设计模板》+《合规营销语录与禁语列表》。

Q784：MiCA是否对员工或董事“代币持仓”有报告义务？

答：是，特别是以下两类人员：

  • 公司董事、管理层、核心开发人员等；

  • 具备内幕信息接触权限人员（含技术后门、智能合约签名者）；

要求：

  • 披露其持仓情况与交易行为；

  • 不得在重要公告前买卖相关代币；

  • 应设“自律锁仓期”与内部审查流程；

  • 建议引入外部审计验证机制。

附：《管理层代币持仓披露表》+《员工持仓管理制度》。

Q785：MiCA是否对“自营交易”作出限制或禁止？

答：MiCA允许有限范围的自营交易，但受下列限制：

  • 平台不得作为对手方与客户进行交易；

  • 自营交易须独立账户执行，不得使用客户资产；

  • 须建立防利益冲突机制，确保撮合公平；

  • 每月报送自营交易明细给监管机构。

附：《平台自营交易行为控制指引》+《隔离交易账户配置示意图》。

Q786：MiCA平台是否可与DeFi协议集成？是否可引导链上交易？

答：如平台为受监管MiCA实体，不得直接提供未经授权金融工具的交易：

  • 可使用经过注册的DeFi桥接服务，但需对接方也符合MiCA要求；

  • 所有链上交互需由平台发起并留存日志，用户不可绕开KYC/KYB；

  • 建议披露DeFi协议代码审计情况与智能合约漏洞风险；

  • 禁止平台引导客户使用未注册DeFi协议进行套利。

附：《合规DeFi集成流程图》+《DeFi协议安全性评估表》。

Q787：MiCA是否要求平台具备“退出机制”以关闭业务或清盘？

答：是，平台必须具备一套完整的有序退出计划（Orderly Wind-Down Plan）：

  • 包括客户资产清退流程、通知安排、账户冻结管理等；

  • 须指定“退出负责人”与外部审计支持方；

  • 所有清退信息应至少提前30天公告；

  • 所有剩余客户资产需结算至用户绑定账户或托管银行账户。

附：《MiCA平台退出机制模板》+《客户清退操作流程SOP》。

Q788：MiCA是否允许提供“量化策略”或“智能跟单”？

答：允许，但策略提供方或平台本身将承担更高合规责任：

  • 策略开发方应完成合规KYC/KYB并签署免责声明；

  • 平台应披露策略历史回报、回撤、风险系数等；

  • 用户选择前需阅读“策略风险揭示书”并签署确认；

  • 不得有“收益承诺”或“平台推荐”误导行为。

附：《量化策略上架合规协议》+《智能跟单风险披露模板》。

Q789：MiCA是否规定客户“最低存款金额”？

答：MiCA不直接设定金额，但平台可根据风险等级自行设限：

  • 建议根据KYC等级设置每日最小存入金额或限额；

  • 防止账户被用于结构化洗钱（如多笔小额）；

  • 特定币种（如稳定币）建议设高于10 EUR的门槛；

  • 可配合反洗钱系统设定“异常低频金额预警机制”。

附：《平台客户存款金额设置建议表》+《结构化资金检测机制》。

Q790：MiCA是否允许平台发布“第三方新闻、评级、分析报告”？

答：允许，但平台应承担信息来源核查责任：

  • 须注明信息来源与发布时间，避免误导；

  • 若涉及推荐或评级，需标明是否存在利益关联；

  • 不得将第三方评级作为客户决策参考的唯一依据；

  • 所有分析报告应通过内容审查机制审核后方可发布。

附：《第三方资讯合规发布审核流程》+《免责声明标准格式模板》。

Q791：MiCA对“虚拟资产钱包服务”中的冷钱包使用有何具体要求？

答：MiCA要求虚拟资产保管服务提供者对冷钱包的使用需确保：

  • 冷钱包应具备**多重签名（Multi-Sig）**机制；

  • 应设立冷热分层使用机制，大额资产不得存于热钱包；

  • 冷钱包密钥保管应有最少2人以上共同控制；

  • 每次从冷钱包出入金必须留档审批记录 + 操作日志；

  • 建议通过专用硬件钱包 + 物理隔离环境运作。

附：《MiCA冷钱包权限控制手册》+《多签密钥分配模板》。

Q792：平台是否必须将所有交易日志备份？保存期限多长？

答：必须保存所有客户交易及系统日志，至少5年：

  • 包括下单、撮合、成交、取消、钱包调拨等全过程；

  • 日志应包括时间戳、客户ID、操作IP、API调用路径；

  • 建议使用不可篡改日志系统或外部审计留存平台；

  • 若涉及AML调查，应扩展保存期限至10年。

附：《交易日志分类存储方案》+《不可篡改日志系统推荐标准》。

Q793：MiCA是否禁止平台设置“隐藏费用”或浮动费率？

答：是，MiCA对费用披露极为严格：

  • 所有手续费、交易费、提现费、网络费等必须明示；

  • 不得设置隐藏费用，如自动转币差价或提币手续费外收；

  • 若为浮动费率，需提供计算方式 + 费率范围说明；

  • 客户下单时应看到最终价格明细确认后方可提交。

附：《费用披露政策模板》+《浮动费率说明模板》。

Q794：MiCA是否允许平台进行“代币质押服务（staking）”？

答：允许，但有以下监管边界要求：

  • 需披露：质押周期、奖励规则、可退机制、风险因素；

  • 若质押为第三方协议，平台应确保协议安全性及KYC合规；

  • 所有收益应以“预期”而非“承诺”表述；

  • 平台应披露是否收取质押佣金，并提供收益历史模拟。

附：《Staking服务说明模板》+《第三方协议风险披露书》。

Q795：MiCA平台是否可以支持NFT相关业务？有何监管规定？

答：MiCA本身不适用于纯艺术/不可替代型NFT，但：

  • 若NFT具有证券化属性（例如收益权、金融合约），将纳入MiCA监管；

  • NFT平台仍需执行KYC/AML，并避免支持非法内容或匿名交易；

  • 不得提供NFT质押贷款等高风险服务，除非额外获得授权；

  • 强烈建议进行NFT项目合法性、来源、创作者身份验证。

附：《NFT项目合规接入审核表》+《NFT运营指引》。

Q796：MiCA是否允许平台使用“代理开户”或“中介开通账户”？

答：禁止使用无KYC的代理开户机制：

  • 客户账户必须由本人开立，平台应核实身份证明与面部识别；

  • 不得接受“代开户”、“团体开户”、“群发链接注册”等做法；

  • 商业介绍人制度可存在，但不得绕开平台主流程KYC/KYB；

  • 所有客户信息应直连平台数据库，由平台统一监管。

附：《反代理开户制度模板》+《中介注册流程合规审查指南》。

Q797：MiCA对平台提供“外汇（Fiat）兑换服务”有何要求？

答：若平台涉及Fiat-to-Crypto兑换，应：

  • 获取立陶宛本地金融服务注册 + 符合欧盟EMD2电子货币规定；

  • 合作银行或支付机构应具备EMI或支付牌照；

  • 客户法币充值记录应对接银行流水 + 身份信息绑定；

  • 所有法币兑换均应适用反洗钱标准，包括来源调查与交易限额。

附：《Fiat兑换服务合规清单》+《银行合作接口协议模板》。

Q798：MiCA是否对“交易撮合规则”设有合规性要求？

答：是，MiCA规定所有平台必须设立透明、公正、非歧视性的撮合机制：

  • 所有订单需按照时间优先 / 价格优先原则处理；

  • 撮合逻辑需有完整披露（不允许暗池撮合或先知撮合）；

  • 不得设“对特定客户优先成交”或“隐藏流动性”机制；

  • 系统应具备撮合日志回溯、异常报警与流量监控功能。

附：《撮合逻辑合规披露书》+《撮合机制监管接口说明》。

Q799：MiCA是否允许平台发行自有平台币？发行条件有哪些？

答：允许，但平台币发行将受到**资产参考代币（ART）或电子货币代币（EMT）**条款限制：

  • 平台须向监管备案并提交白皮书；

  • 平台币不得用作“支付工具”，除非满足EMT授权条件；

  • 所有平台币持仓、流通、销毁须设实时监控与披露制度；

  • 应设平台币使用边界说明，明确非投资建议与非储值工具。

附：《平台币合规发行流程图》+《平台币用途限制声明模板》。

Q800：MiCA是否要求平台设立“监管联系人”或合规窗口？

答：是，每一家MiCA持牌平台必须：

  • 指定1名或以上监管联系人（Regulatory Liaison Officer）；

  • 联系人应为法定代表人或合规官之一；

  • 应提供有效联系方式，并具备英语/立陶宛语沟通能力；

  • 平台官网应设立“合规联系渠道”页面，供用户或监管反馈问题。

附：《监管联系人登记表》+《MiCA持牌企业合规联系页面模板》。

Q801：MiCA是否强制要求平台配备“灾难恢复（DR）计划”？

答：是，MiCA要求所有虚拟资产服务提供者必须具备完整的业务连续性计划（BCP）与灾难恢复机制（DRP），包括但不限于：

  • 系统级灾难应急机制（数据中心备份、CDN容灾）；

  • 人员级应急联系人与操作指引；

  • 事件分级响应流程（中断报告机制）；

  • 每年至少1次灾备演练记录。

附：《MiCA灾难恢复制度模板》+《灾难演练报告范本》。

Q802：是否必须将MiCA持牌实体的所有数据存储在欧盟境内？

答：原则上，是。MiCA要求平台需保证数据合规存储：

  • 所有客户数据、交易日志、KYC资料优先存储于EEA/EU区域数据中心；

  • 如使用非欧盟数据服务商（如AWS新加坡），需符合法规（如GDPR跨境传输标准条款 SCC）；

  • 建议使用GDPR合规云服务+本地镜像备份；

  • 客户有权利请求“数据所在地说明”。

附：《平台数据存储合规声明模板》+《GDPR数据传输协议样本》。

Q803：MiCA是否禁止平台提供杠杆交易（Margin）或合约交易？

答：MiCA对杠杆交易/衍生品持高度审慎立场：

  • 若平台涉及杠杆、期货、永续合约等服务，视同金融工具交易，须额外申请MiFID II相关金融牌照；

  • MiCA本身不授权提供保证金放大服务；

  • 若设杠杆产品，需提供完整的风险披露、风控机制及用户适当性匹配（如专业投资人）；

  • 一般零售向杠杆交易风险极高，监管态度保守。

附：《杠杆交易风险揭示书》+《MiCA + MiFID合规双授权结构图》。

Q804：平台是否需要提供客户“交易对账单”或“账户明细”？

答：必须，且需满足以下MiCA规定：

  • 客户可随时导出其交易历史、充值提现记录、账户余额明细；

  • 交易对账单需包含完整信息：资产种类、时间、数量、币种价格；

  • 应保留至少5年记录，供客户随时查阅或打印；

  • 对账单模板应符合审计要求与监管格式。

附：《MiCA标准客户对账单模板》+《审计可追溯数据结构设计表》。

Q805：MiCA是否强制要求平台设置“注册投资人制度”？

答：MiCA并不强制平台对所有用户执行“投资人分层制度”（如专业/零售），但：

  • 若平台涉及高风险产品（如ART/EMT、某些稳定币、链上金融工具），建议引入投资人分类机制；

  • 平台可依KYC、风险测评结果、交易经验划分；

  • 各类客户享有不同交易权限、上限与产品访问权限；

  • 投资人分类应可更新，客户有申诉和升级机制。

附：《客户分类与风险等级评估表模板》+《MiCA客户访问权限策略示意图》。

Q806：平台是否可以不向客户公开其资金存放方式？

答：不可以。MiCA要求资产保管结构必须高度透明：

  • 客户资产是否保存在第三方托管方，必须明示；

  • 平台是否混合保管客户与公司资产，必须披露；

  • 保管结构需附带法律协议、银行证明、冷钱包说明；

  • 推荐展示“资产存储结构图”并定期更新。

附：《资产保管披露模板》+《客户资产结构展示图（可上链）》。

Q807：MiCA平台是否允许接入“Token Launchpad”或代币发行初期销售平台？

答：允许，但需满足以下严格监管条件：

  • 若为首次发行代币（ICO/IEO/Launchpad），必须向监管提交完整白皮书；

  • 平台需承担承销责任、项目KYC/KYB核查、募资流向追踪；

  • 所有募资必须经受监管银行或监管审计流程；

  • 不得以“首发暴涨”等术语宣传。

附：《Launchpad项目上线合规清单》+《项目方尽调报告模板》。

Q808：MiCA对员工培训有哪些强制性合规要求？

答：平台必须为所有涉及业务/合规/客户服务/技术人员建立持续培训制度：

  • 每年至少1次合规培训（含AML、KYC、STR识别）；

  • 新员工入职30天内需完成MiCA制度通识培训；

  • 需保留培训记录、考试通过记录、更新日志；

  • 推荐使用线上培训平台并形成考核机制。

附：《员工合规培训年度计划模板》+《考试题库样本》。

Q809：MiCA是否允许平台发行“稳定币”？发行条件是什么？

答：MiCA允许平台发行稳定币，但须依照以下两类代币架构：

  • EMT（Electronic Money Token）：稳定币锚定法币，需申请电子货币机构许可（EMI）；

  • ART（Asset-referenced Token）：锚定一篮子资产或多币种，需符合白皮书 + 资本金 + 风控披露等要求；

  • 必须设独立资产托管账户、定期审计、发行说明书；

  • 不得宣传为“官方货币”、“零风险”。

附：《EMT/ART稳定币发行申请流程图》+《稳定币资产储备说明模板》。

Q810：MiCA是否对“客户负面名单”或“拒绝服务机制”有标准？

答：是。MiCA要求每个平台必须维护并更新：

  • 客户黑名单机制（如被监管通报、欺诈账户、洗钱关联）；

  • 高风险地区限制名录（配合FATF、欧盟制裁清单）；

  • 拒绝服务制度：平台有权拒绝开户/交易并说明原因；

  • 所有封号、拒绝交易、冻结账户行为必须备案并保留证据。

附：《MiCA客户黑名单管理制度》+《拒绝服务通知书模板》。

Q811：MiCA是否对平台的“客户资金分账”有强制规定？

答：是，MiCA明文要求平台采取客户资金与公司自有资金完全隔离的机制：

  • 客户资金须存于专用信托账户或独立托管账户；

  • 不能将客户资金用于平台营运、借贷、投资等用途；

  • 必须每天对客户资产进行核对（reconciliation）；

  • 资金隔离证明材料需在申请时提交，并定期向BoL更新。

附：《客户资金分账制度模板》+《每日核对机制流程图》。

Q812：MiCA是否接受使用“虚拟银行账户”或“电子钱包账户”存放客户资金？

答：仅在满足以下条件时可接受：

  • 账户开设机构为受欧盟监管的电子货币机构（如：EMI）；

  • 平台需提供该账户的法律协议、可回溯性机制说明；

  • 客户需可随时查询其资金状态；

  • 推荐优先选择传统银行信托账户作为主资金通道。

附：《电子钱包存放结构图》+《多层资金托管模型建议》。

Q813：MiCA平台是否可以只提供“钱包服务”而不经营交易？

答：可以。MiCA CASP类型中明确允许：

  • 提供“虚拟资产保管与管理服务”而不提供交易；

  • 可作为独立钱包平台，承担KYC、私钥托管、冷热钱包管理等职责；

  • 但仍需申请牌照，并履行客户身份识别与STR义务；

  • 须披露钱包机制结构（是否自托管 / 第三方托管等）。

附：《钱包服务专营CASP申请结构图》+《冷钱包权限控制模板》。

Q814：MiCA是否规定了冷钱包必须多签或物理隔离？

答：MiCA对冷钱包控制机制未强制统一模式，但要求满足**“安全性、可审计性、操作分权”**三项原则：

  • 推荐冷钱包采用多重签名（Multi-sig）或MPC架构；

  • 需隔离私钥生成与签名权限；

  • 应设置操作日志、审批流程与权限清单；

  • 热/冷钱包切换机制需备案。

附：《冷钱包控制权配置模板》+《密钥持有者角色责任清单》。

Q815：MiCA是否强制设立内部合规稽核职能？

答：是的。MiCA明确要求CASP平台配备内部合规监督与稽核职能：

  • 合规职能需定期审查平台是否执行AML/KYC/客户资产管理/IT安控等机制；

  • 可由专职人员或聘请独立审计单位；

  • 稽核报告建议每半年生成一次，并向董事会汇报；

  • 稽核职责建议列入组织结构图中。

附：《内部合规稽核工作制度模板》+《稽核发现问题整改流程表》。

Q816：MiCA平台是否可以允许客户使用匿名交易？

答：不允许。MiCA及立陶宛BoL要求：

  • 平台所有客户必须完成KYC/身份识别流程；

  • 不得允许“无需开户即交易”、“一次性匿名访问”等形式；

  • 应设置身份识别与交易权限绑定机制；

  • 高风险客户应加强尽调（EDD）。

附：《KYC等级划分表》+《拒绝匿名交易机制设计图》。

Q817：MiCA是否要求平台定期向监管报告？有哪些报表义务？

答：是。MiCA合规平台需履行定期监管申报义务，包括：

  • 年度合规报告（Compliance Report）；

  • 客户资产托管情况报告；

  • STR申报统计表；

  • 交易量、用户增长、投诉数据等季度报告；

  • 系统安全事件记录（如适用）。

附：《MiCA监管报表申报清单》+《BoL年度报告模板》。

Q818：MiCA是否对“非同质化代币（NFT）”有监管要求？

答：MiCA将大多数NFT排除于CASP范围，但：

  • 若NFT具备分割交易属性、具证券/收益权结构、批量生成，可能仍被视为虚拟资产；

  • MiCA不会监管单一纯艺术型NFT；

  • 若NFT与DeFi金融用途捆绑（如NFT抵押借贷、收益转让），须申请CASP；

  • 建议保留NFT分类法律意见函。

附：《NFT合规边界认定标准》+《NFT发行适用MiCA判断表》。

Q819：MiCA是否要求公开平台所有Token的“白名单”？

答：是。MiCA平台需：

  • 明示所有可交易/存储/管理的Token清单；

  • 每个Token须说明：基础链、合约地址、发行方式、法律属性、是否STO；

  • 若平台自行上架代币，需履行“资产尽调程序”并保留记录；

  • 客户须可查阅完整代币信息与风险披露。

附：《Token上架审核表》+《代币白名单发布标准模板》。

Q820：MiCA申请是否必须提交商业计划书？内容应包括哪些？

答：必须，商业计划书为MiCA申请核心材料之一，建议涵盖：

  1. 公司概况与股权结构；

  2. 主要负责人履历、合规架构；

  3. 拟申请CASP种类与服务模式；

  4. 技术系统结构图与冷/热钱包机制；

  5. 资本金安排与三年财务预测；

  6. 客户流程图（开户、交易、提款等）；

  7. 法律合规机制说明（含AML/KYC/投诉等）；

  8. 增长规划与合规维护机制。

附：《MiCA商业计划书标准模板（中英双语）》。

Q821：MiCA平台是否可以与多个支付服务商（PSP）合作处理出入金？

答：可以，且强烈建议平台对接多个PSP以降低单点风险，但需确保：

  • 每个PSP具备欧盟支付机构或EMI资质；

  • 客户入金路径清晰，不可混用不同PSP账户；

  • 出入金路径与客户实名信息绑定；

  • 与每个PSP签署正式协议并保留尽职调查报告。

附：《PSP对接尽调清单模板》+《多PSP出入金结构图》。

Q822：MiCA平台是否可以接受USDT作为客户入金币种？

答：可以，但监管机构对USDT接受程度较为审慎，建议：

  • 平台须评估USDT托管结构、审计频率、发行稳定性；

  • 应配合设置“风险级别币种限制机制”（如限额或分组）；

  • 建议配合USDT白名单账户进行托管与流转；

  • 尽可能同步支持更合规稳定的资产（如EURe、USDC）。

附：《稳定币风险评估表》+《MiCA允许的稳定币币种白名单》。

Q823：MiCA平台是否可以开展“杠杆交易”或“借贷服务”？

答：MiCA原始框架不涵盖杠杆交易和加密借贷业务，但如需开展，需注意：

  • 若提供杠杆交易，须额外申请MiFID II投资服务牌照；

  • 借贷行为将被纳入未来欧盟FIDA（金融数据法）或新监管法规中；

  • 暂不建议MiCA平台直接提供借贷或杠杆，如要开展，需独立子公司+分牌照合规。

附：《杠杆交易监管适用指引》+《合规拆分结构建议图》。

Q824：MiCA是否强制平台披露Token发行人的实际控制人（UBO）？

答：是。平台在上架或提供代币相关服务前，须识别并存档以下信息：

  • 发行方法人信息（注册地、法律编号、控股结构）；

  • 实际控制人或UBO身份及受益百分比；

  • Token发行结构（是否中心化、合约是否可升级）；

  • 与平台是否存在直接关联关系（如双重身份、持股等）。

附：《Token发行方尽职调查模板》+《UBO身份识别表》。

Q825：MiCA平台是否可以为客户提供“统一交易账户”用于多币种交易？

答：可以。平台可采用统一交易账户（multi-asset account）模式，前提是：

  • 帐户中不同币种资产需独立记录、可审计；

  • 资产估值需实时换算为欧元并可查阅；

  • 禁止在后台进行“币种切换”无实际交易的转化行为；

  • 每次交易必须生成明确交易对手与撮合信息。

附：《统一交易账户资产记录模板》+《资产估值报告格式》。

Q826：MiCA平台的客户资产如遭盗窃，平台是否负全责？

答：平台须承担托管失责责任，除非能证明：

  • 非平台系统问题导致；

  • 客户自身原因（如泄露私钥）；

  • 平台已尽合理技术防护义务（可提供安全审计）；

建议配合购买加密资产托管保险（Crypto Custody Insurance）作为保障。

附：《资产丢失责任判定流程图》+《托管保险推荐方案》。

Q827：MiCA对平台的IT人员、开发人员是否有资质要求？

答：MiCA无具体学历/证书要求，但对“胜任能力”有原则要求：

  • 平台应保留IT/系统开发人员的简历与任职说明；

  • 须具备相关区块链安全、系统设计背景；

  • 推荐至少一名核心技术负责人具有欧盟信息安全相关经验；

  • 如系统关键部分外包，须对供应商进行评估并签署合规协议。

附：《技术人员资质档案模板》+《开发人员尽职调查表》。

Q828：MiCA是否允许平台为客户提供“交易策略推荐”或“投顾功能”？

答：MiCA本身不涵盖投资顾问服务条款。如平台提供该类功能：

  • 须额外申请MiFID II下的“投资建议服务”牌照；

  • 否则仅可提供“不构成建议”的市场信息展示；

  • 不得以“推荐某币”、“预测涨跌”等名义诱导交易；

  • 须在所有界面标注“非投资建议”声明。

附：《免责声明模板》+《MiFID投顾服务适用说明》。

Q829：MiCA是否允许平台持有客户“法币资产”？是否需牌照外延？

答：MiCA允许平台代客户持有等值法币资产（如银行托管账户余额），但：

  • 不可擅自动用法币，仅供客户充值提现用途；

  • 应与EMI机构/银行合作，并签署三方监管账户协议；

  • 建议申请附加金融服务或与第三方法币托管商合作；

  • 所有法币收支应匹配客户姓名与账户信息。

附：《客户法币资金流入流出管理制度》+《银行合作协议模板》。

Q830：MiCA平台是否可以接受DAO组织的项目代币上架？

答：可以，但需特别审查DAO的治理结构、控制机制及责任识别：

  • DAO应具备注册法人身份或法律责任实体；

  • 须识别DAO多签控制人（实际控制权）；

  • 智能合约是否可升级/冻结；

  • 建议要求DAO出具法律意见函说明其合规性。

附：《DAO治理结构识别表》+《DAO代币上架法律意见书范本》。

Q831：MiCA是否允许平台提供“自动化交易机器人”（Trading Bots）服务？

答：允许，但需履行信息披露与风险提示义务：

  • 平台提供交易机器人的行为将被视为算法服务供应方；

  • 应明确说明策略模型类型、适用市场、最大回撤等参数；

  • 用户应签署《自动交易协议书》，并设置限额与止损；

  • 若机器人涉及外部接入API，需限制调用频率、设定权限边界。

附：《交易机器人服务协议模板》+《策略授权风险提示书》。

Q832：MiCA是否要求平台对智能合约进行安全审计？必须第三方审计吗？

答：强烈建议，特别是平台运营依赖智能合约（如DEX、托管、多签机制）：

  • 智能合约应至少由一个第三方安全公司出具完整审计报告；

  • 报告应包含代码评估、已知漏洞识别、测试覆盖率等；

  • 合约如后续更新，须重新审计；

  • 审计摘要应公开披露至用户界面或白皮书中。

附：《合约审计结果摘要模板》+《审计流程报告格式指引》。

Q833：MiCA是否支持将平台关键系统托管在云服务商？是否需境内托管？

答：支持，但需满足以下条件：

  • 云服务商应为欧盟或等效数据保护标准国家（如ISO27001认证）；

  • 所有客户数据与资产数据应加密传输并可备份；

  • 平台须与云服务商签署数据保护协议（DPA）；

  • 若核心业务系统部署在第三国，需额外说明监管接入接口机制。

附：《DPA合规协议范本》+《云托管风险评估表》。

Q834：MiCA是否规定平台每日应进行数据备份？是否需异地备份？

答：是的，平台必须建立完整的数据备份机制，包括：

  • 至少每日1次全量备份 + 实时增量备份机制；

  • 备份数据需至少保留6个月，重要数据达5年以上；

  • 异地灾备建议采用不同地区/服务商分开存储；

  • 所有备份操作需记录日志，并可供审计。

附：《平台备份策略流程图》+《备份执行记录模板》。

Q835：MiCA平台是否可以设定KYC等级差异化服务？例如不做视频核身者限交易？

答：可以，MiCA允许KYC差异化分级，建议结构为：

  • L1级客户：邮箱/手机+基础身份验证 → 限额交易，仅浏览；

  • L2级客户：身份文件+地址证明 → 可进行法币入金；

  • L3级客户：视频核身+源资金证明 → 可使用全部功能+高频交易；

  • 每一级别的服务范围、风险提示应公开透明并获得用户确认。

附：《KYC等级差异服务清单》+《限额规则配置模板》。

Q836：MiCA是否规定平台对用户账户进行行为评分（如风险画像建模）？

答：非强制性条文，但监管鼓励平台采用行为风险模型：

  • 建议建立基于交易频率、资金来源、设备指纹的风险评分系统；

  • 风险高的账户应自动触发MLRO审查机制；

  • 评分模型应每季度复审与校正；

  • 模型输出结果不应直接限制交易，而应作为辅助决策。

附：《客户风险评分规则手册》+《模型输出解释说明模板》。

Q837：MiCA平台是否允许接入DEX流动性池或DeFi协议？

答：高度敏感。MiCA尚未正式纳管DeFi协议，若平台计划接入：

  • 须进行项目源头、代码开源性、黑客历史、社区治理评估；

  • 建议仅作为展示行情或做市流动性对接，不涉客户资产注入；

  • 若平台撮合来自DEX，应清晰披露流动性来源及交易对手；

  • 不得诱导用户进行链上无KYC交互。

附：《DEX接入风险评估表》+《链上协议合规白皮书模板》。

Q838：MiCA是否要求平台设置客户支持部门？是否有响应时间要求？

答：是。平台需建立客户支持机制，包含：

  • 客服支持渠道（至少1项实时支持，如Chat或电话）；

  • 所有投诉应在15个工作日内回复并在35日内解决；

  • 投诉记录需保留5年以上，供监管审查；

  • 建议设置《客户支持SOP》，分类处理常见问题。

附：《客户服务响应时间对照表》+《投诉处理记录模板》。

Q839：MiCA平台是否允许客户开设多个账户？

答：MiCA不鼓励客户多账户操作，平台建议：

  • 每位自然人/法人客户仅限一个主账户；

  • 若因业务需求须开设子账户（如法人财务分账），应书面申请；

  • 系统应限制重复身份证件、邮箱、设备注册；

  • 多账户操作存在高风险（如洗钱、套利），平台应强制监控。

附：《账户实名审查政策》+《账户重复监控报告格式》。

Q840：MiCA平台是否可以开展“打新Token”（IEO / Launchpad）业务？

答：可开展，但须满足以下条件：

  • Launchpad发币项目应满足MiCA资产披露要求（白皮书、法律架构、技术审计）；

  • 所有参与者应完成KYC/KYB；

  • 平台不得对项目价格做出保底、回购、承诺收益等误导性宣传；

  • 募集资金流入路径、归属方式应明示。

附：《MiCA下IEO操作流程图》+《Launchpad项目合规核查清单》。

Q841：MiCA平台是否允许客户通过第三方代理人（Agent）开户与操作？

答：允许，但监管非常严格：

  • 所有代理人必须完成KYC/KYB并提供授权委托书；

  • 平台应验证代理关系的真实性（如签署扫描件+电话确认）；

  • 不得接受匿名代理账户或通过链上混币工具接入的代理；

  • 若代理人为专业财务顾问或家族办公室，应评估其受监管状态。

附：《代理开户合规指引模板》+《代理KYC表格（自然人/法人）》。

Q842：MiCA是否规定平台应建立“利益冲突管理政策”？需要哪些内容？

答：是的，利益冲突管理是合规重点之一，应涵盖：

  • 平台自营资产交易与客户撮合之间的隔离；

  • 上币与IEO项目筛选过程中的透明性（如评估委员会机制）；

  • 员工持有项目Token的披露机制；

  • MLRO / RO不得同时参与客户管理与运营决策。

附：《利益冲突管理制度模板》+《内部申报制度表格》。

Q843：MiCA是否允许平台运营自营Token？是否可与客户同场交易？

答：MiCA允许运营平台Token（如：BNB、HT、OKB），但：

  • 必须在白皮书中说明平台持有比例、发行机制、使用场景；

  • 平台不得对自营Token价格进行人为干预或与客户竞争撮合；

  • RO/员工禁止内幕交易平台Token，需定期申报其交易情况；

  • 平台持有的自营Token应存于独立地址并接受审计。

建议提交：《平台Token自律规则》《Token内控管理制度》。

Q844：MiCA是否允许“委托理财”或“复制交易”功能？

答：允许，但需满足以下前提：

  • 投资顾问或策略提供者必须具备MiFID许可或等效资质；

  • 客户应签署明确授权协议；

  • 所有交易记录应可查询、可撤销（具客户控制权）；

  • 不得有保底收益、利润分成、未披露的佣金机制。

附：《复制交易授权模板》+《第三方策略提供者尽调清单》。

Q845：MiCA是否要求平台上币前进行项目尽职调查（Token Due Diligence）？

答：是。平台必须在Token上线前完成尽调并保存审查记录：

  • 核查Token项目的法律结构、核心团队、技术白皮书；

  • 必须识别是否具有证券性质或MiCA分类下的其他特征；

  • 如有预挖、私募、中心化控制等，应附说明和风险提示；

  • 尽调应保留文档、内部评审流程、会议纪要等备查。

附：《上币项目尽调模板》+《Token合规审查评分表》。

Q846：MiCA平台是否可以针对不同地区设定业务限制（如禁止美国用户）？

答：可以，MiCA不强制“全球开放”，平台有权设置地理访问限制：

  • 应通过IP地址、手机号、KYC国籍自动识别并设限；

  • 禁止区域应包含在客户协议与风险提示中；

  • 若接受非欧盟客户，应说明适用法律与争议解决机制；

  • 建议不接受FATF高风险地区客户或设额外审查机制。

附：《受限地区用户接入政策》+《IP+KYC国别拦截方案》。

Q847：MiCA是否要求披露冷钱包管理机制？是否有冷/热钱包分离比例建议？

答：是。平台必须说明资产托管方式：

  • 建议不低于85%-90%资产储存于冷钱包；

  • 冷钱包应至少具备多签/多级权限分离机制；

  • 热钱包限额应设为每日交易流动需求的两倍以下；

  • 冷钱包权限分配应有RO、MLRO和董事会交叉参与。

附：《冷钱包管理政策模板》+《冷/热钱包资产比例控制图》。

Q848：MiCA是否允许平台自营流动性池参与撮合？

答：允许，但需特别披露：

  • 平台需说明是否存在自营流动性参与买卖行为；

  • 所有自营交易应标签化，并与客户订单分离；

  • 自营池不得对客户价格造成操控性干预；

  • 建议每日向BoL申报自营与客户交易占比。

附：《流动性撮合自营规则》+《市场行为监控报告模板》。

Q849：MiCA是否要求披露所有费用结构？包括隐性费用？

答：是。MiCA规定所有费用必须提前清晰披露并取得客户确认：

  • 应包括交易费、提现费、托管费、上币费、滑点补偿机制等；

  • 禁止隐藏费用（如浮动汇率差、未明示的Gas费）；

  • 所有费用应在客户中心、确认页、条款页展示；

  • 费用变动必须提前通知，建议设置用户“确认后生效”机制。

附：《平台费用总览模板》+《费用变更通知标准格式》。

Q850：MiCA是否允许平台提供线下客户服务（如KYC面谈、客服中心）？是否加分？

答：允许，且被视为优质合规加分项：

  • 客户如可选择线下核身或现场咨询，有助提升信任；

  • 如设立合规办事处，须告知监管其业务范围；

  • 应配置保密措施（如KYC文件只读终端、隔音室）；

  • 可定期向BoL提交线下服务报告与客户满意度统计。

附：《线下客户支持说明书》+《现场KYC面谈指引》。

Q851：MiCA平台是否可以运营“非托管钱包”业务？

答：可以，但需严格区分非托管服务与受监管业务：

  • 若平台提供非托管钱包（如：用户私钥全权掌控），则不受MiCA约束；

  • 但若同时提供交易、兑换、撮合等服务，仍需MiCA授权；

  • 必须向客户清晰披露“平台无权访问私钥”、“不提供资产保障”；

  • 建议设置风险提示界面并附免责声明。

附：《非托管钱包业务边界说明模板》+《免责声明范本》。

Q852：MiCA是否要求平台设立“客户适当性评估模型”？

答：是的，特别适用于提供交易建议、投顾服务、结构性产品的平台：

  • 应建立问卷系统对客户的风险承受力、经验、目标进行评估；

  • 根据评估等级限制其参与高风险交易；

  • 投资建议必须基于客户档案、资产配置比例等；

  • 客户有权重新评估，平台需记录每次更改。

附：《适当性评估模型Excel模板》+《MiCA适当性匹配策略说明》。

Q853：MiCA是否允许平台收集和分析客户行为数据？是否受限？

答：允许，但受GDPR约束：

  • 可分析用户交易习惯、点击路径、偏好设置等以优化服务；

  • 须取得用户同意，并明确告知用途（营销/风险控制等）；

  • 不得将用户数据出售或未经授权外泄；

  • 建议设立“数据访问请求入口”供客户查阅与删除数据。

附：《用户行为数据管理政策》+《数据隐私合规声明模板》。

Q854：MiCA平台若因技术问题发生资产损失，平台是否需赔偿？

答：一般情况需承担责任：

  • 若资产损失系因平台技术失误（如：撮合系统故障、冷钱包丢失），应赔偿；

  • 可通过商业保险对冲赔偿风险；

  • 若属不可抗力（如全球链瘫痪），应提前说明免责机制；

  • 建议所有用户协议中写明故障响应与赔偿规则。

附：《技术故障应对机制说明》+《资产损失赔偿机制模板》。

Q855：MiCA是否允许“多平台共用合规系统”？（如同一集团内共享KYC/AML系统）

答：允许，但需具备以下条件：

  • 平台之间必须存在明确控制关系（同集团或受托管理）；

  • 共享系统应具备用户隔离与权限管控功能；

  • 每个平台对自身用户仍需承担独立责任；

  • 所有系统共用协议必须向BoL备案说明。

附：《集团共享系统合规备忘录》+《多平台KYC系统接口图解》。

Q856：MiCA是否允许客户通过API访问平台账户？如何监管？

答：允许，且是金融科技集成的常规方式，但需管控风险：

  • 每一API Key应与实名客户绑定；

  • 必须设置访问权限粒度（如仅读、下单、提现）；

  • 所有API调用应具备风控阈值，如：请求频率、异地登录拦截；

  • 应在后台可视化审计API行为日志。

附：《客户API接入风险管理制度》+《API使用说明书（用户版）》。

Q857：MiCA是否规定平台应定期进行合规稽核或外部审计？

答：是的，平台需每年至少进行一次内部合规稽核，且：

  • 建议委托独立第三方审计机构进行系统性检查；

  • 内容应涵盖AML、客户资产安全、KYC、信息披露、IT安全等；

  • 审计结果应提交董事会并存档备查；

  • 重大缺陷应设整改时限并报告BoL。

附：《年度合规稽核报告结构模板》+《外部审计合同模板》。

Q858：MiCA是否规定平台可接受哪些支付方式进行客户充值？

答：MiCA未强制限定支付方式，但建议：

  • 首选通过受监管金融机构转账（如：银行、电汇、SEPA）；

  • 可接受经验证的电子钱包（如Skrill、Revolut）；

  • 不鼓励直接使用第三方代收（可能引发洗钱疑虑）；

  • 所有入金渠道必须具备客户身份对接机制。

附：《充值渠道合规白名单表》+《入金路径追踪模板》。

Q859：MiCA是否允许平台提供衍生品（如期货、杠杆合约）服务？

答：不在MiCA框架内监管，属于MiFID II/MAR等衍生金融产品管辖：

  • 若提供此类产品，平台需额外申请MiFID投资服务牌照；

  • 须满足资本金、交易对手资格、风险披露等高标准要求；

  • 否则视为越界经营，存在被处罚或吊销MiCA许可的风险；

  • 建议明确信息披露“不提供衍生品服务”。

附：《MiCA与MiFID业务边界说明》+《跨牌照业务隔离政策》。

Q860：MiCA平台是否必须提供交易后“结算确认书”？格式如何？

答：是，平台应为客户提供交易确认函，至少包括以下内容：

  • 成交时间、交易对、价格、数量、手续费；

  • 交易类型（现货/限价/市价）、撮合对手类型（客户/自营）；

  • 订单编号与区块哈希（如适用）；

  • 建议提供PDF格式或链上存证可验证记录。

附：《交易结算确认书模板》+《链上确认存证流程图》。

Q861：MiCA是否允许平台同时运营“场外OTC交易”服务？

答：允许，但须满足以下条件：

  • OTC交易需纳入交易服务范围并获BoL备案；

  • 客户身份必须完成KYC与适当性评估；

  • 所有交易应有交易记录与双方确认机制；

  • 平台需设立《OTC风险披露》与《交易确认函》制度；

  • 推荐保留交易录音、通讯记录及报价快照。

建议使用《OTC交易全流程合规模板包》。

Q862：MiCA是否允许平台为用户提供法币账户管理？

答：MiCA许可并不自动包含电子货币账户服务：

  • 若平台提供多币种法币账户、余额展示、支付指令等服务，需额外申请**EMI（电子货币机构）**牌照；

  • 可通过第三方受监管EMI合作实现白标账户功能；

  • 客户资金必须明确隔离，平台不得挪用；

  • 合作方应在欧盟内持牌，并与客户签署服务协议。

附：《平台-EMI合作协议模板》与《账户资金隔离流程图》。

Q863：MiCA是否禁止平台与链上DEX进行互联互通？

答：未明确禁止，但监管要求如下：

  • 平台如调用DEX进行订单撮合、流动性路由，需向客户披露操作逻辑与风险；

  • 不得借由DEX操作逃避KYC与资产审查；

  • 所有DEX交易需记录完整交易路径（如钱包地址、时间戳、交易哈希）；

  • 若涉及客户资产调拨，应设立授权流程与可回滚机制。

附：《链上交易桥接合规结构图》与《DEX互操作规则范本》。

Q864：MiCA平台是否可以使用“白标签系统”搭建子平台？

答：可以，但需满足：

  • 主平台（Licensor）必须获得MiCA CASP许可；

  • 子平台（Licensee）不得独立开展合规义务豁免；

  • 所有客户数据、交易记录必须归入主平台合规审计；

  • 建议每一白标商签署《运营约束条款》并完成KYC链路控制。

建议建立《白标签系统监管报备指引》和《合规责任分担说明》。

Q865：MiCA是否对平台Token上架制定“禁止清单”？

答：MiCA并未设“禁止Token名单”，但平台必须确保：

  • Token非证券类（除非额外取得MiFID授权）；

  • Token非匿名币（如Monero/XMR等在多国被限制）；

  • 非高风险项目（如无公开治理、暴涨暴跌、代投）；

  • 不得列出涉及金融诈骗、洗钱、黑市用途Token。

可依据ESMA/EBA建议制定《Token筛选白名单》与《动态禁投清单》。

Q866：MiCA是否允许平台提供“算法稳定币”交易？

答：MiCA区分“e-money token”（EMT）与“asset-referenced token”（ART）：

  • 若算法稳定币无法锚定现实资产或货币单位，可能不符合ART定义；

  • 若设计为基于供需机制或币本位算法调节（如Terra USD），面临更高风险监管；

  • 通常此类稳定币不可作为支付Token或储值Token上架；

  • 建议谨慎审查算法机制与市场稳定性。

推荐提交《算法稳定币风险报告》与《Token稳定性模型白皮书》。

Q867：MiCA对“用户提现”是否有时间限制要求？

答：有，但未设统一强制时间标准：

  • 要求平台必须在合理时间内完成客户提现；

  • 不得因市场波动、交易对手延迟提现；

  • 如设提现限额或冻结期，必须提前书面披露；

  • 建议设置T+0或T+1提现机制，并向BoL说明流程。

附：《客户资产提现流程图》与《提现风险披露模板》。

Q868：MiCA是否允许平台经营子品牌或子网站？

答：允许，但监管要求包括：

  • 所有子品牌必须受主牌照监管；

  • 子品牌不得对客户产生误导（如隐瞒母公司关系）；

  • 子网站收集信息必须使用主平台合规工具；

  • 推荐平台统一披露备案、联系方式、风险声明。

建议建立《MiCA合规品牌架构图》和《子品牌域名备案说明书》。

Q869：MiCA平台若为用户提供Staking服务，是否需额外许可？

答：是否需额外许可取决于Staking模式：

  • Custodial Staking（托管质押）：用户资金交由平台管理，通常被视为受监管活动；

  • Non-Custodial Staking（非托管质押）：用户自行操作，平台仅提供接口，一般无额外牌照要求；

  • 若Staking收益结构与金融产品类似（固定收益、返利承诺），则需额外说明；

  • 所有Staking项目应向BoL备案，并提供白皮书与风险披露。

附：《Staking服务分类说明》+《收益模型与合规判断表》。

Q870：MiCA平台是否允许代币化债券或Tokenized Bond交易？

答：不允许在MiCA框架内直接运营证券型代币交易平台：

  • Tokenized Bond 属于《MiFID II》监管范围，须取得证券交易许可；

  • MiCA平台若间接提供此类服务，将被认定为超范围经营；

  • 可通过与持牌证券公司合作实现Tokenized债券交易接口；

  • 建议设立业务隔离机制与投资者适当性审查流程。

建议附《证券型代币业务边界说明》与《合作交易通道协议模板》。

Q871：MiCA监管下，平台是否可以收取“Gas费”或矿工费差价？

答：可以收取，但必须合规披露：

  • 若平台为用户执行链上操作，可代收链上Gas费用；

  • 严禁隐性差价，如Gas费成本为$1却收$5；

  • 建议清晰标注“链上费用 + 平台处理费”；

  • 应提供交易明细（例如：链上Tx哈希 + 扣费截图）。

建议在用户协议中增设《链上手续费与处理机制说明》。

Q872：MiCA平台是否可以提供“推荐返佣”或代理制度？

答：可以，但需符合营销合规要求：

  • 推荐人须实名注册并接受KYC；

  • 推荐奖励应明确金额、适用范围；

  • 禁止“传销”式层级返佣或收益拆分；

  • BoL可能要求提供《推荐人名单》及活动执行记录。

附：可用模板《推荐机制风险说明书》与《反滥用激励行为制度》。

Q873：MiCA平台是否可以支持NFT交易或上架？

答：MiCA 暂不适用于纯NFT项目，但需注意以下情况：

  • 若NFT具金融属性或可拆分性（如fractional NFT），可能被重新分类为加密资产；

  • 若NFT平台还提供钱包服务、支付服务，则可能须持MiCA牌照；

  • 若NFT为GameFi组合或可用于流动性挖矿，应纳入风险评估范围；

  • 建议项目方提供NFT不可替代性说明、用途界定及估值机制。

推荐附《NFT产品法律意见书》和《数字艺术风险披露说明》。

Q874：MiCA是否强制要求进行“压力测试”或“灾难演练”？

答：强烈建议执行但非强制义务：

  • BoL鼓励平台定期进行“灾难恢复演练”（Disaster Recovery Test）；

  • 内容包括系统宕机、黑客攻击、私钥丢失等场景；

  • 测试报告应记录处理流程、响应时间、人员响应情况；

  • 可纳入年度合规报告一并呈报。

建议建立《应急预案响应手册》与《灾难恢复执行报告模板》。

Q875：平台是否可以自行发行平台币（Utility Token）？

答：可以，但须说明用途与限制：

  • 平台币不可用于承诺回购、分红、固定升值等；

  • 必须区分平台使用权（如手续费折扣、VIP权益）与证券型权益；

  • 建议披露《Token发行说明书》（Lightpaper）并注册交易白名单；

  • 若Token流通规模大，建议考虑是否触发ART分类并提前咨询BoL。

推荐附《平台币Token法务分析报告》与《Token生命周期管理制度》。

Q876：MiCA是否要求设立内部合规审计机制？

答：是，平台应具备以下要素：

  • 独立审计角色（可为外聘）；

  • 每年至少1次合规内审（含KYC流程、交易抽样、系统权限等）；

  • 审计报告需提交董事会并存档备查；

  • 应纳入AML年检机制中统一呈报。

附：《合规审计清单模板》与《合规内审报告结构范本》。

Q877：平台是否可以开放“新币申购”或“Launchpad”功能？

答：可以，但极为敏感：

  • 所有项目需提交《项目背景说明书》与《反诈骗声明》；

  • 必须完成项目方KYC与背景调查；

  • 必须提供全流程资金监管机制（如限额、限时锁仓）；

  • 不得诱导用户以投机心理参与。

附：《Launchpad合规结构图》与《项目筛选评分表》。

Q878：MiCA是否允许设立API交易或开放程序化接口？

答：允许，前提是：

  • 客户需申请并签署《API使用协议》；

  • 所有API调用记录需保存（含IP地址、调用频率）；

  • 平台需设立接口权限层级（如只读、交易、资产转账）；

  • 建议防止“恶意程序撮合或抢跑”策略。

建议制定《API风控控制方案》和《交易接口访问规范》。

Q879：MiCA是否允许平台内支持多语言服务？是否有限制？

答：允许，但需保持合规一致性：

  • 英文、立陶宛文为官方推荐语种；

  • 若提供中文、法语、德语等，应确保内容与原版一致；

  • 不可出现信息不一致、翻译误导；

  • 建议定期审阅语言版本，并留存比对记录。

建议附：《多语种审查机制与差错处理流程》。

Q880：MiCA是否要求披露平台的“系统供应商”或“技术外包方”？

答：如系统开发非自营，需披露外包情况：

  • 向BoL申报时，应提供《技术外包协议》与《数据控制说明》；

  • 外包方需接受数据安全审查与反洗钱要求；

  • 不得由匿名或无实际运营的第三方持有核心代码控制权；

  • 建议签订《应急切换机制协议》，防止供应商突然中断。

建议附：《技术系统架构外包责任图》。

Q881：MiCA对“转板退市”是否有监管要求？平台能否主动下架代币？

答：可以主动下架，但需遵循透明流程：

  • 下架原因应包括项目风险变更、交易量过低、合规问题等；

  • 平台应提前通知客户（建议至少7个工作日前）；

  • 必须提供退出方案（如资产兑换、提现通道）；

  • 应留存下架评估与董事会批准记录。

推荐建立《代币退市评估机制》与《平台Token清退流程图》。

Q882：MiCA平台是否可以与国外未持牌交易所共享订单簿或流动性？

答：不推荐，存在高度合规风险：

  • 若国外交易所无MiCA牌照或不在EEA地区，涉及非授权跨境业务；

  • 所有订单撮合、结算行为应在MiCA平台内部完成；

  • 若确需外部流动性引入，应签署清晰的《Broker模式协议》，平台仅作为代理撮合方；

  • 不得将客户资产流向境外监管盲区。

建议附《订单流共享风险分析报告》与《撮合代理结构图》。

Q883：MiCA是否允许平台提供“模拟交易”功能？

答：允许，需作出明显声明并进行区分：

  • 所有模拟交易页面须标明“非真实资产交易”；

  • 模拟系统不可与真实系统混用后台；

  • 若涉及API等测试接口，应设置独立Sandbox环境；

  • 可用于培训与用户教育，平台不得引导用户误认为可获真实收益。

附：《模拟交易免责声明模板》与《仿真交易系统设计指引》。

Q884：MiCA监管下是否可通过“预加载平台余额”开展充值？

答：仅在具备EMI授权或通过受监管EMI合作方实现下，方可提供充值功能：

  • 客户充值不应视为平台“代管”行为，必须由受监管金融机构控制；

  • 平台应避免形成“类支付”账户体系（如客户直接充值至平台总账）；

  • 推荐使用**“EMI白标方案”**进行隔离处理。

附：《充值功能合规路径图》与《EMI余额托管模型说明》。

Q885：MiCA是否支持用户使用冷钱包直接登录或授权交易？

答：技术上可行，但监管要求包括：

  • 冷钱包接入必须符合KYC识别标准（即便非平台钱包）；

  • 每笔交易应有“指令留痕”与“身份确认”机制；

  • 平台需确保非托管钱包行为不成为逃避反洗钱审查路径；

  • 建议通过MetaMask/WalletConnect等集成，并记录设备指纹等交互数据。

附：《非托管钱包连接合规标准表》。

Q886：MiCA是否规定用户留存期、客户记录保存期？

答：是，明确记录保存义务：

  • 客户识别资料（KYC）至少保存5年；

  • 交易记录、风险评估、客户沟通档案应保存5年以上；

  • 若涉潜在调查或法院争议，保存期可延长至10年；

  • 建议配合数据加密、多地异地备份。

建议附《数据保存周期制度》与《合规备份策略表》。

Q887：MiCA平台如何处理“黑名单国家”或受制裁用户？

答：平台须建立制裁名单筛查系统（如联合国、OFAC、欧盟）：

  • 不得允许来自受制裁国家IP地址/居住地的用户注册；

  • 应建立自动拦截机制 + 人工审核双重系统；

  • 客户若触发制裁名单应立即冻结账户并上报监管；

  • 建议引入工具（如Dow Jones、World-Check等）定期批量筛查。

附：《制裁名单自动筛查方案》和《账户冻结与报告流程》。

Q888：MiCA平台是否可以进行“双重挂牌”与双市场同步上市？

答：若平台计划在多个MiCA持牌交易所同步上线某代币，需注意：

  • 所有参与市场均应完成各自合规Token评估；

  • 平台间不得“合谋炒作”或“拉盘行为”；

  • 应披露市场行为协调内容及价格同步机制；

  • 推荐引入“第三方公正评估”机制防止操纵行为。

建议附《多市场同步上市说明书》和《反操纵风险自评表》。

Q889：MiCA平台是否允许为客户提供“定投”或自动策略产品？

答：可以，前提是充分风险披露 + 操作透明：

  • 所有“定期购买”类产品必须明确频率、额度、对象资产；

  • 客户需主动选择，不得默认启用；

  • 应有暂停、终止、修改机制；

  • 禁止使用定投进行“营销诱导式预测收益”。

推荐附《自动化投资服务条款模板》和《客户同意确认书》。

Q890：MiCA是否允许在平台中开展DAO治理机制（链上投票等）？

答：平台可搭建DAO机制，但必须明确法律主体关系：

  • DAO投票结果不能直接影响平台监管责任结构；

  • 所有DAO成员须完成KYC识别（如享有分红或治理权）；

  • DAO资金应由合规实体托管；

  • 应披露《DAO法律框架书》和治理规则。

附：《DAO架构图 + 治理风险说明书》。

Q891：MiCA是否要求平台披露“客户资产与公司资产隔离”机制？

答：是，平台必须向监管机构与客户清晰披露：

  • 客户资产应保存在独立账户或独立链上钱包中；

  • 公司运营资金不得与客户资产混用；

  • 应具备“资产分离机制证明材料”，如银行开设“Client Account”、链上标签化管理等；

  • 客户可随时核对其资产归属。

推荐附：《资产隔离操作流程图》与《客户资产托管白皮书》。

Q892：MiCA是否限制平台对客户进行杠杆服务（如：保证金、借贷）？

答：MiCA目前不直接授权杠杆类服务：

  • 涉及杠杆/借贷业务的CASP，应申请额外金融牌照（如欧盟信贷机构许可）；

  • 若平台通过“质押借币”间接提供杠杆，BoL可能要求“金融活动声明”；

  • 强烈建议清晰划分纯交易平台与借贷平台功能。

附：《杠杆型服务合规边界分析书》与《CASP豁免判断手册》。

Q893：平台在MiCA监管框架内是否可以开展空投（Airdrop）活动？

答：可行，但应符合下列要求：

  • 空投Token不得具“投资回报诱导”性质；

  • 需披露发行方背景、空投条件与时间表；

  • 推荐设置KYC门槛，防止机器人滥领；

  • 若空投资产可能演变为ART或EMT，应提前向监管备案。

推荐附：《Airdrop政策披露模板》和《空投活动法律合规风险说明》。

Q894：MiCA是否要求平台配合实施“双录机制”（双向录音录像）？

答：MiCA未强制实施“双录”，但部分客户互动（如投诉处理、风险告知、语音交易）建议：

  • 对高净值客户、机构客户的交易电话建议录音；

  • 平台客服、合规部、AML部门应保留沟通记录；

  • 文字或语音记录应留存≥5年；

  • 如未来发生争议或调查，有利于公司自证合规行为。

附：《客户沟通留痕制度手册》和《双录适用场景说明书》。

Q895：MiCA监管下平台是否必须公开合规负责人的姓名或联系方式？

答：平台需披露合规联络渠道，但负责人可仅使用职务名义：

  • 网站建议设立“合规投诉入口”与“反洗钱举报通道”；

  • 披露如“合规部门 – compliance@yourcompany.eu”；

  • 可设立专人负责客户风险沟通，但无须全面公开身份信息。

推荐附：《客户联络机制政策》与《信息披露矩阵表》。

Q896：MiCA是否允许平台通过社交媒体进行营销推广？

答：允许，但需遵循以下规定：

  • 所有营销内容应真实、完整、无误导；

  • 应避免使用“快速致富”、“稳赚不赔”等语言；

  • 建议事前对营销图文、视频进行合规审查存档；

  • 应设置可追溯的链接，确保用户可查阅完整披露文件。

附：《社交媒体内容合规检查清单》和《数字营销规范制度》。

Q897：MiCA是否要求平台设置“退出机制”或客户自愿终止账户的功能？

答：是的，平台应允许客户随时申请终止服务并注销账户：

  • 应设置在线退出申请通道；

  • 账户资金需在规定时间内予以清算与返还；

  • 客户历史记录应按法规保存，不可删除；

  • 不得因客户退出设置强制等待期或惩罚性条款。

推荐附：《MiCA客户终止服务流程图》和《退出机制政策范本》。

Q898：MiCA是否允许平台为用户提供“资产评级”或加密项目评分？

答：可以，但需特别注明评级标准为“参考信息”而非投资建议：

  • 不得使用“官方评级”、“权威推荐”等词语误导；

  • 应注明评级主体、计算方法、更新周期；

  • 建议配合第三方审计或评分逻辑公开说明；

  • 不得故意贬低或抬高特定项目。

附：《项目评级合规披露指引》和《风险提示附注模板》。

Q899：MiCA是否允许平台开展链下（Off-chain）资产挂钩的Token发行？

答：允许，但须满足资产真实性 + 担保审计机制：

  • 若挂钩黄金、房地产、碳积分等，应提供“链下资产持证凭证”；

  • 必须引入独立审计方进行周期性核查；

  • 若Token具备稳定价值属性，可能被MiCA视为“ART”；

  • 强烈建议制定《链下资产担保与披露制度》。

推荐附：《链下挂钩资产映射报告》和《资产担保托管证明文件》。

Q900：MiCA平台在遭受黑客攻击后如何合规响应？是否有强制报告机制？

答：必须在72小时内向BoL报告重大事件：

  • 报告内容应包括事件起因、受影响范围、初步处理情况；

  • 平台应建立《重大事件应对机制》（含技术响应+客户通知）；

  • 建议同时向客户发送通告，并提供补偿机制说明（若有）；

  • 若涉及客户资产外泄，应配合BoL进一步调查。

附：《重大事件应急预案模板》和《BoL重大事件报告表单》。

Q901：MiCA平台是否可以为项目方提供“代上币”或“代运营”服务？

答：可以，但需规范操作流程并防范利益冲突：

  • 平台不得“承诺上线”或“按费用排名上币”；

  • 项目方须完成KYC，并提交合法来源说明；

  • 所有代运营内容（如推广、技术接入）需签署正式协议；

  • 平台应设置“项目评审委员会”独立审查其合规性。

推荐附：《项目上线合规评估制度》与《上币流程操作图》。

Q902：MiCA监管框架是否允许平台开展稳定币质押服务？

答：原则允许，但涉及多重监管：

  • 若质押服务产生收益分配或利息承诺，可能被重新界定为存款/证券；

  • 必须披露资金用途、质押逻辑、收益来源及退出机制；

  • 建议将稳定币质押产品纳入“金融产品说明文件”下申报；

  • 应避免“承诺固定年化收益”字眼。

附：《稳定币质押产品合规白皮书》与《投资风险揭示书》。

Q903：MiCA平台是否可以将客户资产转入第三方DeFi协议以获取收益？

答：高度敏感，一般不建议：

  • 客户资产若被转移至不可控的DeFi协议，存在监管穿透失败的风险；

  • 若平台作为“代理执行者”操作，需提前取得客户明示授权；

  • 建议客户自行绑定钱包参与DeFi，平台仅提供接口展示；

  • 强烈推荐附加《DeFi使用风险警示与免责协议》。

推荐附：《DeFi交互流程图》与《第三方合约审计报告存档制度》。

Q904：MiCA是否对交易对的组合方式（如BTC/ETH、BTC/USD）有监管限制？

答：MiCA本身不限制交易对种类，但需注意：

  • 如交易对涉及法币，应确保法币流通路径合法（即EMI等受监管支付通道）；

  • 若交易对为Token/Token，建议注明其法律分类与风险级别；

  • 所有交易对均需由平台审批，不可由用户自由添加；

  • 建议每季度对所有交易对进行风险复评并记录。

附：《交易对上线标准手册》与《资产配对风险评分卡》。

Q905：MiCA是否要求平台保存链上操作或交易的“截图或Tx记录”？

答：是，所有客户交易必须保存完整可追溯链上记录：

  • 包括交易Hash、时间戳、地址对、资产变动信息；

  • 建议平台为客户提供“下载PDF格式交易证明”功能；

  • 可选保留链上Tx截图，但更推荐直接提供Explorer链接；

  • 建议采用“不可篡改数据归档系统”（如IPFS+哈希对照）作为证据。

附：《链上交互审计留存机制白皮书》与《Tx记录结构化存储说明书》。

Q906：MiCA平台是否可以采用“多签钱包 + 冷热分层”的资金结构？

答：完全符合监管鼓励方向：

  • 热钱包日限额控制、冷钱包多签备份、权限分层必须；

  • 建议设置“3-5”多签门限 + 日清点机制；

  • 应具备冷钱包物理隔离与地理分布存储说明；

  • 建议将私钥保管流程纳入“关键运营流程”提交BoL备查。

推荐附：《多重签名结构图》与《资金存管机制制度文件》。

Q907：MiCA是否允许平台设立“收益型NFT”或“权益型Token”？

答：如该NFT或Token具有如下特征，则可能被视为证券型加密资产：

  • 可分红、具“权利证明”性质；

  • 提供收益承诺或对价回报机制；

  • 在此情况下，平台必须向BoL申报相关资质；

  • 建议提前提交法律意见书，说明其不构成金融工具。

附：《权益型Token法律分析模板》和《收益类Token披露样式》。

Q908：MiCA是否允许设立“Token清退机制”或“Token封存机制”？

答：平台可在以下情况下设立清退机制：

  • 项目方失联、违法、破产；

  • Token长期无交易量或价格操纵；

  • 清退流程应提前公告，保留用户兑换/提币通道；

  • Token封存应提交BoL事后报告，说明清退合理性与客户补偿机制。

附：《Token清退决策流程图》与《封存资产客户告知模板》。

Q909：MiCA是否对技术服务商（如KYC供应商、托管商）有资质要求？

答：有明确要求：

  • 所有合作供应商必须通过合规审查并签署《外部服务协议》；

  • KYC供应商需具备ISO 27001或等同级别数据安全认证；

  • 第三方托管商需具备EU监管认可资质；

  • 所有技术服务应建立“替代计划”与“服务中断应急方案”。

附：《外包服务供应商审查清单》与《应急切换技术机制文档》。

Q910：MiCA是否允许平台支持“跨链资产管理”？例如支持Solana、Polygon等非EVM链？

答：允许，但需解决以下问题：

  • 平台需展示支持的链类型、桥接机制、安全审计情况；

  • 非EVM链资产必须确保平台具备存储、转账、归集与展示能力；

  • 跨链机制（如桥协议）应具有完整技术审计与数据同步机制；

  • BoL可能要求列明各链资产的独立资产报告与风控措施。

附：《跨链资产支持策略文档》与《多链资产同步与存证机制图解》。

Q911：MiCA申请人是否可在申请阶段即开始团队扩张和市场推广？

答：允许内部准备和团队建设，但不得公开提供服务或进行误导性营销：

  • 可启动招聘、技术开发、内测准备；

  • 不得在官网或公开场合声称“已获MiCA牌照”或误导用户；

  • 所有市场推广应明确说明：“本平台正在申请MiCA牌照，尚未提供受监管服务”。

建议配合《营销语句审查机制》与《品牌宣传合规声明模板》。

Q912：MiCA对Token白皮书内容的监管有哪些具体要求？

答：MiCA要求Token发行前必须提交并公开合规白皮书，内容须涵盖：

  • 项目描述与团队介绍；

  • 风险披露（如价格波动、技术失效、法律风险）；

  • 代币功能、发行机制、分配计划；

  • 投资者权利、限制、流通方式；

  • 法律意见书摘要（是否构成金融工具）。

建议附：《白皮书模板（MiCA格式）》及 《Token合规披露框架指引》。

Q913：平台董事是否可以兼职担任合规官（CCO）或MLRO？

答：MiCA并不禁止，但应确保独立性和职责分离：

  • CCO/MLRO可由董事担任，但不得同时担任CEO或财务主管；

  • 推荐设置“监督机制”防止利益冲突；

  • 若合规/反洗钱职责未独立，BoL将提高审查等级。

附：《双角色合规制度模板》及《职责冲突回避政策》。

Q914：MiCA平台是否可以限制客户使用某些资产或交易类型？

答：可以，平台有权设置“资产黑名单”、“交易限制条件”：

  • 高风险国家/代币/交易对可禁用或限额；

  • 应有《资产甄选与风险评级政策》支撑；

  • 应定期评估限制逻辑的合理性并留档。

附：《高风险资产处置策略》与《禁止交易清单更新制度》。

Q915：MiCA是否要求客户分层管理？（如零售、高净值、机构）

答：是。MiCA要求平台进行“客户适当性评估”与分类管理：

  • 客户初次开户须填写适当性问卷；

  • 客户类型将影响其可接触的产品、杠杆比例、信息披露级别；

  • 建议配合建立“分层风控逻辑”与“KYC评分系统”。

附：《客户适当性分类标准》与《问卷模板（附打分机制）》。

Q916：MiCA是否强制要求平台建立中文、俄文等多语言支持？

答：不是强制要求，但若平台面向非英语区客户，应提供其母语支持：

  • 客户界面需具备其母语（如立陶宛语、中文、俄文）；

  • 白皮书、合同、风险披露文件建议同步翻译；

  • 平台需对翻译准确性负责。

推荐附：《多语种披露策略》与《官方翻译责任制度》。

Q917：MiCA是否允许通过“合伙制”结构运营平台，而非公司制？

答：MiCA明确仅接受注册法人实体（公司制），合伙制、自然人运营结构不被接受：

  • 申请主体须为立陶宛注册的有限责任公司（UAB）或股份公司；

  • 须在立陶宛拥有注册办公室与本地董事；

  • 合伙人身份可作为股东存在，但不得直接持牌。

附：《申请主体法人资格检查清单》与《非公司制申请不予受理说明》。

Q918：MiCA是否对“社交媒体营销”有监管要求？

答：是的，尤其是影响客户投资判断的信息：

  • 所有营销内容（含X、Telegram、微博）须经合规审查；

  • 不得承诺回报、暗示保本、歪曲产品特征；

  • 建议建立“社交媒体传播内容登记簿”与“预审核机制”。

附：《MiCA营销合规白名单术语表》与《违规传播纠正流程》。

Q919：平台Token是否可用于“平台内手续费抵扣”？

答：可作为功能用途，但必须有合理说明与机制披露：

  • 须在白皮书中明确说明“代币用于手续费抵扣”的适用范围、比例、波动风险；

  • 不得强制要求客户使用平台Token支付；

  • 建议平台设定最高抵扣比例，避免误导投资性质。

附：《平台Token实用性使用说明》与《费用抵扣规则披露模板》。

Q920：MiCA平台是否可以持有客户提供的质押资产用于项目融资？

答：禁止平台擅自挪用客户质押资产作融资用途：

  • 客户质押资产应明确归属、独立保管；

  • 平台不得将其用于流动性注入、项目投资或对外担保；

  • 若客户同意授权挪用，需有明确的协议、回购机制与风险揭示。

附：《客户资产隔离协议模板》与《质押资产用途限制制度》。

Q921：MiCA是否允许平台根据客户交易频率或资产规模进行费率差异化？

答：允许，但必须公开、透明并符合“公平对待客户”原则：

  • 可设立不同交易费率等级（如VIP、高净值客户专属）；

  • 差异化条件（资产≥x万欧元或月交易额≥x笔）须明示；

  • 不得出现隐藏费用、模糊定义或排他性承诺。

附：《费率等级设置指引》与《交易成本披露模板》。

Q922：MiCA监管下是否允许平台使用“推荐返佣”模式招揽客户？

答：允许，但平台需确保：

  • 推荐机制公开透明，不可涉及虚假引导或夸大收益；

  • 被推荐人知情并自愿注册，平台保存推荐关系记录；

  • 推荐报酬不得构成“销售误导”、“承诺回报”等违规情形。

推荐配套：《推荐制度合规披露模板》和《利益冲突登记制度》。

Q923：MiCA是否允许平台为项目方提供Launchpad（代币发行）服务？

答：允许，但须视项目性质判断是否构成“资产参考代币（ART）”或“电子货币代币（EMT）”：

  • 平台应对项目方进行合规尽调（白皮书、法意见书、风险披露）；

  • 若构成MiCA监管Token，需项目方另行持牌或配合平台申报；

  • 平台须制定《Launchpad风控机制》与《项目甄选机制》。

附：《Token发售前审查清单》与《二级市场上线流程规范》。

Q924：平台未获得MiCA牌照前是否可以接收客户充值或提供测试服务？

答：不能正式接收客户资金或提供对外服务，但可以：

  • 搭建测试环境进行内部演示或邀请受限范围内白名单测试；

  • 不得开展公开交易、充值提现或收取服务费；

  • 不得使用“测试中”包装名义绕过MiCA许可。

推荐附：《MiCA前置测试账户合规指引》与《测试活动范围限制清单》。

Q925：MiCA是否强制规定平台运营团队需居住在立陶宛？

答：不强制大部分团队在立陶宛，但以下岗位须本地化或常驻欧盟：

  • 至少1名执行董事需具备立陶宛居留或工作居留签证；

  • 合规负责人（CCO）、MLRO建议具备可随时赴监管沟通能力；

  • 若平台采用远程运营模式，须提交“远程治理报告”说明控制机制。

附：《董事驻地证明模板》与《远程管理合规结构图》。

Q926：MiCA是否允许平台将合规、AML工作外包？

答：允许部分职能外包，但需满足以下条件：

  • 委托方对外包服务结果仍承担最终责任；

  • 外包机构须具备专业资质与良好履历；

  • 平台应提交《服务协议 + 外包活动通知书》至BoL备案。

推荐附：《AML外包职责说明书》与《合规外包控制政策》。

Q927：MiCA平台是否可设立“二级市场交易场所”供项目方Token自由挂牌？

答：可行，但须承担交易所运营责任：

  • 项目方Token需经平台合规审查与风险披露；

  • 平台须披露上线标准、信息更新机制与风险警示规则；

  • 不得出现“项目方付费买上线权”等交易所与项目方勾连行为。

附：《Token上线申请表》与《二级市场项目评分机制》。

Q928：MiCA是否允许平台用户互相转账/转币？是否构成支付行为？

答：允许在平台内进行点对点转账，但须：

  • 明确区分平台内转账与支付行为（如商户收款等）；

  • 若平台提供跨客户账户的资产转移，仍需设定内部风控限额；

  • 若超出“交易所”业务范畴，可能需取得PSP或EMI牌照。

附：《客户转账合规规则说明书》与《非支付行为披露政策》。

Q929：MiCA是否允许平台将部分关键系统部署在非欧盟国家？

答：原则上，核心系统与客户数据应优先部署在欧盟境内，但有例外：

  • 非欧盟部署需满足“等效监管保护机制”；

  • 平台应提供数据访问、灾备恢复、监管可审计接口；

  • 所有非欧盟系统需报BoL说明并获取批准。

附：《IT系统部署声明模板》与《跨境系统控制审查手册》。

Q930：平台是否可与非持牌MiCA项目方开展合作？（如钱包、DApp）

答：可以，但平台须明确划分责任边界：

  • 需签订合作协议，注明对客户责任的区隔；

  • 非持牌项目不得使用平台名义或代平台作出投资建议；

  • 如合作方涉嫌非法募资，平台须立即中止合作并告知客户。

附：《第三方项目合作风险排查表》与《对外合作标准协议模板》。

Q931：MiCA监管是否要求平台披露关键算法或撮合机制？

答：不要求公开算法源码，但需满足“透明可审计”要求：

  • 平台须向监管机构（BoL）说明撮合机制、订单优先级、撮合逻辑；

  • 须具备日志留痕、算法参数可追溯、误差容忍说明机制；

  • 若使用AI撮合、预测机制，建议附上“算法偏差风险披露”。

附：《撮合系统逻辑结构说明书》与《算法变更备案模板》。

Q932：平台是否可以设立“收益宝”、“活期账户”等类理财产品？

答：如该产品涉及收益承诺或资金池集中管理，须持MiCA + 特定附加牌照（如投资机构或EMI）：

  • 传统MiCA交易所仅可提供“交易撮合、托管、兑换”；

  • 提供收益类产品（如质押挖矿、活期收益宝）需额外合规；

  • 必须进行产品性质分类并披露是否属于“金融工具”或“投资产品”。

附：《收益类产品设计合规审核表》与《非金融工具声明模板》。

Q933：是否必须为客户提供“冷钱包”或“离线托管”选项？

答：MiCA并未强制提供冷钱包服务，但平台应对托管安全机制做充分披露：

  • 若使用冷钱包，应说明多签方案、钥匙保管方案、冷热钱包切换机制；

  • 若不支持客户自选冷钱包，平台应披露客户资产存储方式及风险；

  • 建议支持“导出私钥”或“绑定外部钱包地址”功能作为替代。

附：《资产托管模式披露声明》与《冷钱包权限层级控制图》。

Q934：平台是否可设置“强平机制”或“自动风控止损”系统？

答：允许，但须设定机制规则、客户授权协议与风控披露：

  • 平台应提前告知强平条件（如维持保证金比率<25%）；

  • 执行强平前应尽量提供风险预警通知；

  • 所有强平记录须留档、可追溯并提供客户查询通道。

附：《强平机制用户协议条款》与《自动止损执行制度》。

Q935：MiCA是否限制平台提供杠杆交易或衍生品（如期权、合约）？

答：MiCA本身不适用于衍生品类加密资产（此类产品由MiFID II监管）：

  • 若平台计划提供期货、合约、杠杆CFD，需额外申请金融工具类牌照（如立陶宛IFM牌照）；

  • MiCA适用于原生加密资产（不构成金融工具），不包含杠杆衍生产品；

  • 建议建立“产品适用监管分类体系”用于区分不同监管路线。

附：《交易产品监管分类表》与《杠杆产品合规路线图》。

Q936：MiCA对NFT平台是否有明确监管指引？

答：MiCA明示：“不可替代性”是豁免监管的关键判断标准：

  • 若NFT代表唯一艺术品、收藏品或特定实物资产 → 视为非MiCA监管范畴；

  • 若NFT可分割流通、具证券属性、批量发行（如游戏装备） → 可能触发MiCA监管；

  • 平台应对每类NFT产品评估其“金融属性”并留存法律意见。

附：《NFT合规分类分析表》与《豁免意见书样本（附律师签章）》。

Q937：MiCA是否要求对员工进行定期合规培训？频次有无要求？

答：是，平台应建立员工合规培训机制，BoL建议每年至少一次全面性培训：

  • 新员工入职应完成KYC/AML及MiCA监管基础培训；

  • 高管/RO/MLRO需每年更新其监管知识并记录考核情况；

  • 平台应建立《培训记录表》《培训考试档案》《外聘讲师登记表》。

附：《年度合规培训计划模板》与《员工培训签到档案》。

Q938：MiCA是否要求设立“内部审计”功能？可以外包吗？

答：是。MiCA对中大型平台要求建立“独立审计机制”，可由内部设岗或外聘审计机构完成：

  • 平台每年至少一次全面内部合规审计；

  • 内审报告需向董事会汇报，并在BoL年审时提交；

  • 可聘请第三方审计公司，但需签署保密协议并对质量负责。

附：《内部审计执行报告模板》与《外包审计协议标准样本》。

Q939：平台是否可以设立“模拟交易区”供客户测试操作？

答：可以，并鼓励设立“模拟账户”以提升客户适当性判断：

  • 模拟账户不得与真实资产混合，不得误导用户认为为真实交易；

  • 模拟结果不得用于对外营销或收益承诺；

  • 建议设立单独子系统或沙盒环境区分生产系统。

附：《模拟账户使用说明书》与《客户培训合规制度》。

Q940：MiCA是否支持平台与传统金融机构共享客户数据（如银行KYC结果）？

答：支持在法律许可范围内进行客户身份验证共享，但必须符合：

  • GDPR规定 + 客户知情同意前提；

  • 平台与银行、第三方KYC供应商间签订数据交换协议；

  • 客户应可拒绝或撤回授权共享。

附：《KYC数据共享授权书模板》与《客户隐私权告知说明》。

Q941：MiCA是否允许平台通过DAO架构运营？

答：MiCA未禁止DAO（去中心化自治组织）参与平台架构，但平台必须具备明确的法律实体以承担监管责任：

  • DAO可作为治理机制存在，但不应替代注册公司主体；

  • 所有责任人（如董事、RO、MLRO）仍须具名担责；

  • 若DAO投票涉及重大事项（如更换RO），平台应建立“DAO治理合规机制”。

附：《DAO参与机制合规控制模板》与《RO不可替代权责保留声明》。

Q942：MiCA对代币发行的“信息披露书”有什么最低要求？

答：MiCA要求对“拟流通的加密资产”提交《Crypto-Asset Whitepaper》，包含：

  • 发行人信息、资金用途、代币功能；

  • 投资者权利义务、技术标准、安全风险；

  • 若代币可转让、具价值存储功能，BoL会加强审查；

  • 须以英文+立陶宛文版本递交，格式参照欧盟官方模板。

附：《加密资产白皮书编制结构表》与《信息披露合规核对清单》。

Q943：MiCA是否对交易平台的流动性提供商有合规要求？

答：有。平台若设有流动性做市方，需：

  • 披露做市商身份、合作协议与交易对；

  • 确保做市行为符合“市场公平性”与“客户最佳执行”原则；

  • 禁止自营账户对客户账户进行不公平撮合。

附：《流动性提供商协议模板》与《平台做市合规管理政策》。

Q944：MiCA是否要求交易所进行“异常波动监测”？

答：是。平台应设立市场监控机制，及时识别：

  • 非常规价格波动（如30分钟内价格涨跌超±10%）；

  • 非理性大单、刷单、拉高出货等行为；

  • 异常情况应自动触发“暂停交易”、“风控审查”或向BoL报告。

附：《市场监控系统规则说明书》与《异常交易事件报告表》。

Q945：平台是否必须支持加密资产之间的兑换（Token-to-Token）？

答：不强制，但如提供Token间兑换功能，须：

  • 明确每对交易对的撮合逻辑、汇率参考机制；

  • 风控系统需考虑汇率波动风险与价格偏差限制；

  • 应披露所有兑换手续费、滑点及价格来源。

附：《加密资产兑换合规规则》与《价格偏离风控监控参数表》。

Q946：MiCA是否允许客户使用“稳定币”进行充值？是否有币种限制？

答：允许，但须确保稳定币：

  • 在欧盟合法流通，且由已获MiCA电子货币类授权的机构发行；

  • 有足额法币储备披露，稳定机制需透明可审计；

  • BoL倾向支持EUR稳定币（如EURe、EURCV）优先使用。

附：《稳定币接入标准评估表》与《储备验证声明模板》。

Q947：是否可以以“技术平台服务商”身份仅提供白标系统给第三方？

答：若平台仅提供技术系统、钱包、KYC服务，但不直接面向终端客户，可不申请MiCA牌照，但须满足：

  • 客户（即运营平台）持有MiCA牌照或在申请中；

  • 双方应签署责任划分协议；

  • BoL可能仍要求技术服务方提交合规评估文件（尤其托管类服务）。

附：《白标系统服务合规说明》与《服务责任界定合同模板》。

Q948：MiCA是否允许通过API接入第三方钱包或外部交易所？

答：允许，但需满足以下条件：

  • 所接入方须合法合规，具备牌照或在审状态；

  • 平台须对接入API功能范围、数据传输、资产安全性进行全面评估；

  • BoL可能要求提供接口文档、安全审计记录与数据流向图。

附：《API接入合规审查表》与《数据流合规图》。

Q949：平台是否可以与DeFi协议对接，如Uniswap、Aave等？

答：高度敏感，BoL尚未正式支持平台直接与DeFi协议交互。若涉及：

  • 须进行“协议尽职调查”、风险评估与客户披露；

  • 不得将客户资产投入DeFi协议中进行收益；

  • 如有集成，平台须承担全部损失责任并设赔偿机制。

附：《DeFi接入风险披露书》与《客户不可撤回授权限制条款》。

Q950：MiCA是否允许向非欧盟客户提供服务？是否必须KYC？

答：MiCA适用于平台是否在欧盟设立经营主体，而非客户所在地：

  • 平台向非EU客户提供服务，仍需对客户进行KYC、反洗钱审核；

  • 建议通过IP识别、电话验证等技术手段识别客户地区；

  • 若特定国家为高风险地区（如FATF灰名单国），需限制其注册权利。

附：《非欧盟客户接入合规政策》与《国家风险等级划分表》。

Q951：MiCA下，平台是否可以提供“孖展交易”或杠杆功能？

答：MiCA 并不直接禁止杠杆交易，但要求平台满足高等级合规责任与风控要求：

  • 必须向客户明示风险（包含爆仓机制、强平规则等）；

  • 所提供杠杆比率需符合BoL规定（通常≤5倍）；

  • 杠杆客户需完成适当性评估及追加担保品机制配置。

附：《杠杆交易客户适当性评估表》与《追加保证金政策说明书》。

Q952：是否可以向客户提供“资产保值承诺”或“最低收益保证”？

答：严格禁止。MiCA 明确规定：

  • 不得承诺客户本金安全或任何形式的最低回报；

  • 禁止使用“保证收益”、“保本”、“无风险”等营销术语；

  • 若平台出现此类行为，将被视为严重违规并吊销牌照。

附：《禁止用语清单》与《宣传材料事前合规审查制度》。

Q953：MiCA对NFT交易平台是否适用？NFT业务是否需要持牌？

答：MiCA 不直接监管“唯一性、不可分割”NFT，但：

  • 若NFT被**拆分交易（Fractional NFT）**或具“金融性收益回报”，可能被归类为可转让资产；

  • 若NFT具稳定价值锚定（如稳定币艺术品），或通过平台集中撮合交易，则仍需平台持MiCA牌照；

  • BoL鼓励NFT平台提交“适用性说明函”。

附：《NFT平台自我评估模板》与《是否适用MiCA评估表》。

Q954：MiCA是否允许平台为项目方提供代币质押服务（Staking）？

答：允许，但需分类监管：

  • 如为“技术层面Staking”（不涉及资金池管理），平台应披露技术机制、安全保障措施；

  • 若平台对客户资产集中质押并派息，需持有MiCA托管类许可并符合法定托管责任；

  • 若收益率与客户资金成比例，可能构成“集体投资产品”，触发AIFMD或UCITS监管。

附：《Staking服务分类说明表》与《资产托管/收益分配责任模板》。

Q955：MiCA是否允许用户使用信用卡或Apple Pay充值？有何限制？

答：允许，但需注意：

  • 所有充值渠道必须通过合规支付机构或受监管银行中介；

  • 平台应保存资金来源凭证，严禁使用匿名支付方式；

  • 不得直接收集客户信用卡信息，须由受监管支付网关代收处理。

附：《充值方式披露模板》与《信用卡反洗钱风控机制说明》。

Q956：平台若同时提供虚拟资产交易与法币结算，是否需双牌照？

答：是的：

  • MiCA 监管虚拟资产服务；

  • 若涉及法币账户、电子钱包、收款结算等行为，需另行取得EMI电子货币机构或PSP支付机构牌照；

  • 也可通过与第三方受牌机构合作，以“代理方式”完成结算。

附：《双牌照持有结构图》与《MiCA+EMI联合业务说明书》。

Q957：MiCA是否允许Token在平台内部用于支付交易手续费或奖励？

答：允许，但：

  • 平台必须明确Token的“用途属性”，是否构成可转让加密资产；

  • 所有使用逻辑需公开披露，如“交易折扣”、“返佣机制”；

  • 平台应设上限控制机制，防止变相融资与通胀失控。

附：《平台内Token使用说明书》与《Token经济模型风控评估表》。

Q958：是否可以将客户交易行为记录用于数据销售或精准营销？

答：禁止未经客户授权使用客户数据进行商业变现：

  • 所有行为数据、资金流向、投资偏好等信息属“敏感数据”；

  • 平台需征得客户“明示同意”，并披露数据用途、保存期限及第三方转移政策；

  • 严格遵守《GDPR欧盟通用数据保护条例》。

附：《客户数据使用授权书模板》与《平台数据隐私政策范本》。

Q959：MiCA是否允许平台运营多语言版本？是否必须提供立陶宛语？

答：平台可提供多语言版本（如英文、中文、德文等），但须满足：

  • 所有关键法律条款、客户协议、风险揭示书需具备立陶宛语版本；

  • 向监管机构提交的材料通常使用英文+立陶宛语；

  • 建议聘请认证翻译机构出具“准确翻译声明”。

附：《平台内容多语言披露标准》与《合规翻译声明模板》。

Q960：平台发生安全事件（如数据泄露、黑客攻击）时应如何应对？

答：必须在72小时内向BoL通报并向用户披露，包括：

  • 事件概况、影响评估、初步处理措施；

  • 是否涉及客户资金、是否有资产损失；

  • 后续修复计划与赔偿机制说明。

附：《数据泄露事件应急通报模板》与《黑客攻击事件报告结构》。

Q961：MiCA是否要求平台具备多签名（multi-sig）或MPC结构？

答：MiCA未强制技术方案标准，但强烈建议平台在托管架构中采取多层防护措施：

  • 鼓励采用多签名机制（multi-signature）或门限签名（MPC）；

  • 风控模型应包括权限隔离、角色审批流程、冷热钱包物理隔离等；

  • 平台需向BoL提交系统架构图、签名策略说明与灾难恢复方案。

附：《冷钱包权限控制流程图》与《签名安全策略白皮书》。

Q962：若客户遗失钱包私钥，平台是否有责任找回资产？

答：MiCA要求托管型平台为客户资产承担托管责任：

  • 若平台提供钱包托管（custodian），则有资产追回义务；

  • 若为自托管钱包（self-custody），平台应说明“不承担找回责任”并取得客户书面确认；

  • 推荐通过**多签+恢复密钥机制（recovery key）**保障客户资产安全。

附：《钱包托管责任划分协议模板》与《客户免责声明范本》。

Q963：MiCA是否允许平台为客户提供交易信号或投资建议？

答：此类服务可能涉及**受规管投资建议（investment advice）或投资管理（portfolio management）**行为：

  • 如属于“为个别客户提供个性化投资建议”，将触发《MiFID II》合规要求；

  • 建议此类业务分拆为独立法团并另行持牌；

  • 所有“机器人策略推荐”亦应注明“不构成投资建议”。

附：《交易信号服务合规披露模板》与《MiFID适用性自查清单》。

Q964：平台可以将客户资产用于自营投资或收益管理吗？

答：严格禁止。MiCA明令托管资产不得用于以下行为：

  • 平台自营交易；

  • 为他人提供质押、借贷、衍生交易抵押；

  • 担任清算对手方或引入循环交易结构。

所有客户资产应100%可提取，每日与平台运营资金分离。

附：《客户资金隔离存证函模板》与《托管资金用途限制协议》。

Q965：MiCA是否支持加密资产跨平台转移？平台是否必须开放转出功能？

答：MiCA推崇客户资产可转移性，平台必须支持客户资产转出：

  • 若平台限制转出，必须提供正当理由（如司法冻结、黑名单地址）；

  • 转出流程应包括双因子验证、AML审查、风控拦截机制；

  • 禁止平台设置“锁仓期”或“强制兑换规则”。

附：《客户资产自由转出政策》与《拒绝转出风险披露书》。

Q966：MiCA对“OTC场外大宗交易”是否有限制或牌照区别？

答：允许提供OTC服务，但平台须：

  • 保留每笔OTC交易的完整对话记录与定价依据；

  • 披露撮合方身份、是否存在关联交易；

  • 客户签署《独立报价接受书》，明确风险。

若交易对手为平台自营账户，需追加审查。

附：《OTC交易对话与定价存档制度》与《平台关联交易披露模板》。

Q967：MiCA平台是否可以发行自己的平台币？是否视作金融工具？

答：可以发行平台币（如积分Token或支付Token），但须评估其是否构成：

  • 资产参考型Token（ART）；

  • 电子货币型Token（EMT）；

  • 或具证券性质（如回购安排、分红机制）→ 此时将触发Prospectus Regulation与MiFID II监管。

平台应先行提交“Token法律意见书”与“Token模型审查表”。

附：《平台币合规分类评估表》与《发行人Token披露模板》。

Q968：MiCA是否允许平台使用第三方KYC服务商进行客户识别？

答：允许外包，但平台对最终KYC结果负全责：

  • 第三方KYC供应商需通过BoL或欧盟认可；

  • 平台应保留所有KYC过程记录与KYC供应商的SLA（服务协议）；

  • 平台不得外包“客户风险评估”与“黑名单决策”流程。

附：《KYC外包服务协议范本》与《客户身份验证流程图》。

Q969：MiCA是否适用于智能合约执行的自动交易？是否存在限制？

答：允许自动执行的智能合约交易，但平台必须：

  • 明确智能合约逻辑、版本控制与审计状态；

  • 在合同中披露“自动执行不可撤销”与“交易前无人工确认”风险；

  • 所有智能合约应在链上存证，并提交审计报告。

附：《智能合约审计报告模板》与《用户同意书范本（自动执行）》。

Q970：平台是否可设置“子账户”、“分账户”或“内部划账”功能？

答：可设子账户（如主账户下多策略账户），但应遵循以下要求：

  • 每一子账户资金、风险需可独立识别；

  • 子账户间划转行为需经过授权验证并进行交易审计；

  • 不得利用“子账户”绕开KYC、AML规定。

附：《平台子账户管理规范》与《内部划账流程控制文档》。

Q971：MiCA是否要求披露平台主要技术供应商（如托管方、系统商）？

答：是的。MiCA监管当局（如BoL）要求申请机构在系统合规文件中：

  • 明确列示所有技术合作方（如核心撮合系统、钱包托管系统）；

  • 提交服务合同副本（包括技术服务协议、运维协议）；

  • 声明对关键功能模块保留控制权（即便技术外包）；

  • 对于非欧盟服务商，需解释风险缓解措施（如应急迁移机制、主控端设在立陶宛）。

附：技术合作方清单模板 + 第三方依赖声明样式

Q972：MiCA是否要求披露项目Token或平台币的分配计划？

答：是的，若项目拟发行任何具有价值属性的Token（包括平台积分型Token），需提交：

  • Token Allocation Plan（代币分配计划）；

  • Tokenomics Whitepaper（经济模型说明书）；

  • 声明平台方不得通过“隐藏分配”或“预挖矿”行为规避监管；

  • 若代币具备收益分配功能，可能被界定为MiFID下的金融工具。

建议附上：代币总量、团队占比、锁仓期计划、解锁时间表。

Q973：MiCA是否允许平台在官网上同步运营“社区DAO”模块？

答：允许运营社区DAO论坛、投票模块，但须注意：

  • 不得将DAO结构用于实际控制平台营运（MiCA要求法团具备控制）；

  • DAO发起的投票结果不得具备合约强制执行力；

  • 所有DAO互动模块必须独立于客户账户系统与钱包托管模块。

推荐设独立子域名 + 风险声明，避免BoL认为公司结构“失控”。

Q974：申请MiCA牌照是否可将部分合规责任外包？例如AML审查？

答：可以外包部分工作（如KYC采集、AML初筛），但以下责任不可外包：

  • 最终客户评级与账户开设批准；

  • STR（可疑交易报告）提交责任；

  • RO / MLRO 的职责决策权；

  • 持续监控客户交易行为与账户活动。

建议设置内部MLRO监管框架，并签署《合规服务外包风险共担协议》。

Q975：是否可以设立“海外子公司”或“SPV”来运营技术开发部分？

答：可以，但需满足以下MiCA合规要求：

  • 核心牌照主体（即CASP持牌实体）必须保有最终数据与控制权；

  • 海外子公司不得持有客户资产或账户操作权限；

  • 与SPV之间的合同、技术接口、数据同步机制需提交给BoL备案。

附：技术外包结构示意图 + 控制权声明信。

Q976：MiCA是否要求每位客户必须完成视频面签（Liveness Check）？

答：非强制，但建议作为增强型KYC的组成部分：

  • 通常仅对高风险客户或高净值用户执行；

  • 可采用AI视频识别 + 背景验证（如Sumsub、Onfido方案）；

  • 必须将视频数据安全存储并留存 ≥ 5年。

若不实施视频验证，需解释客户身份核实强度是否足够。

Q977：MiCA是否对“钱包地址白名单机制”提出强制性要求？

答：不是强制性，但作为风控建议措施被广泛采纳：

  • 客户可预设提币地址（白名单）；

  • 非白名单地址转出需通过额外验证（如Email+OTP+人脸识别）；

  • 平台须保留地址绑定、解绑、验证的全过程日志。

建议撰写《钱包地址白名单制度》作为客户安全提示材料。

Q978：MiCA是否允许平台为客户提供“杠杆交易”、“保证金账户”服务？

答：允许提供，但此类服务被视为高风险交易，需满足以下条件：

  • 客户必须完成高风险产品适当性测试；

  • 平台应提交《杠杆交易风险评估报告》；

  • 明确杠杆比率限制、自动减仓机制、强平逻辑；

  • 若引入撮合对手方或流动性提供商（LP），需进行利益冲突申报。

建议在交易协议中设置“杠杆比例最大限制”条款。

Q979：平台是否可在MiCA框架下设置“推荐返佣”或“邀请奖励”机制？

答：可设置，但需确保：

  • 不构成非法拉客、夸大收益或误导性宣传；

  • 所有返佣金额、计算方式必须在协议中明确；

  • 所有邀请行为须留有路径溯源（IP、设备ID、时间戳）；

  • 若涉及跨境用户，需留意各国反传销法规（如法国、德国限制）。

建议附：《推荐奖励机制披露说明》与《反拉人协议确认书》。

Q980：MiCA是否要求平台保存客户通信记录？如客服聊天、邮件？

答：是的，MiCA合规要求平台保存所有与客户沟通相关的文档，包括：

  • 客服聊天记录、用户投诉处理记录；

  • 投诉/争议流程记录与决策说明；

  • 邮件、公告、FAQ等版本更新历史；

  • 必须保留 ≥ 5年，重要事件 ≥ 7年。

推荐设立合规归档系统（可选：Zendesk、Freshdesk、Salesforce记录归档功能）。

Q981：MiCA是否要求平台支持“交易撤回”机制？客户下单后是否可取消？

答：MiCA未强制要求提供撤单机制，但需满足以下几点：

  • 若支持限价单或挂单交易，应允许客户主动撤回挂单；

  • 对已成交的订单，不可单方面撤回或篡改；

  • 平台必须披露交易不可逆原则，并在用户协议中列明处理逻辑；

  • 出现系统错误（如价格异常），平台可保留异常交易回滚权，但必须有审计记录。

建议附：交易流程说明 + 撤单规则文件 + 异常订单管理机制。

Q982：MiCA是否对“数字资产转入”有审查义务？客户充值前是否须核验来源？

答：是的，特别是在以下情况下：

  • 来自高风险国家的钱包地址；

  • 关联地址曾涉及制裁、暗网、诈骗等；

  • 多次小额交易拆分转入（疑似结构化交易）；

  • 与平台既有账户行为模式不一致。

平台应设定初次充值地址背景审查流程（可接入Chainalysis、Elliptic等）并可疑则冻结审查。

Q983：是否可以将MiCA平台的“客服中心”设在海外？是否必须设立本地办公室？

答：MiCA未强制客服团队必须设于本地，但要求：

  • 客户服务至少支持欧盟官方语言之一（如英文、立陶宛语）；

  • 必须提供明确的联络通道（电话、电邮、Web工单）；

  • 若平台无实体办事处，须设立**“监管通信联络代表人”**于立陶宛，用于应对BoL联系与客户投诉转达。

推荐设1名驻立陶宛客服经理或授权代理人。

Q984：MiCA是否允许设立“法人账户”或“企业客户”交易权限？

答：允许，但需满足：

  • 企业账户须完成法人KYC（包含UBO尽调）；

  • 所有操作人须完成授权证明及KYC；

  • 企业账户不得规避交易限额或AML筛查；

  • 建议企业账户默认绑定固定IP或多签钱包。

建议附：企业开户文件清单 + 法人授权模板 + 企业账户风控规则。

Q985：MiCA是否强制要求客户接入“二次身份验证”（2FA）？

答：MiCA建议但不强制，BoL鼓励平台实施2FA策略以增强账户安全：

  • 可采用短信、邮箱OTP、Google Authenticator等；

  • 高风险操作（如提币、API调用）建议强制开启2FA；

  • 平台需对未启用2FA客户设限（如提款额度限制、提示风控）。

推荐文件：《2FA政策指引》、《未启用账户限制政策》。

Q986：MiCA平台是否可以为用户提供“资产利息”或“存币生息”产品？

答：在MiCA框架下，提供收益性存币产品需小心规避下列风险：

  • 若收益与平台业绩相关，可能构成“证券类产品”；

  • 若使用资产再投资或用于借贷，则受限于《欧盟借贷指令》；

  • 须提交“收益机制披露文件”并纳入风险说明中。

若涉及收益分享，建议取得客户书面同意 + 提交监管说明信。

Q987：MiCA是否允许“交易机器人”或“API高频接口”对接？

答：允许，但须合规管理：

  • 提供API服务的CASP平台必须建立访问权限控制；

  • 高频交易用户应签署特殊风险协议；

  • 平台应对机器人行为进行频控（如最大每秒请求数）及反操纵监测。

建议配套：API使用条款、交易机器人KYC登记表。

Q988：MiCA是否允许平台拒绝某些客户开户？可否列设“黑名单国家”？

答：可以，平台有权拒绝服务于高风险客户或地区，前提是：

  • 拒绝标准必须公开透明并非歧视性；

  • 黑名单应依据FATF、欧盟制裁清单、BoL官方风险国名单；

  • 建议设立《客户接入评估政策》（Client Acceptance Policy）。

附：高风险司法辖区名单样本 + 风控拒绝模板信函。

Q989：MiCA是否允许平台为用户发放“稳定币”或类似可兑付Token？

答：仅在取得EMI许可或ART/EMT牌照后方可发行稳定币：

  • 若平台拟作为发行人提供“赎回型Token”，必须额外申请EMT（E-money Token）许可；

  • 仅作为中介（如兑入、兑出）时，需配合已有授权发行人操作；

  • 稳定币运营须符合《MiCA稳定币细则》。

建议：稳定币与CASP业务应独立公司运营，避免交叉风险。

Q990：MiCA是否对平台网站的内容呈现方式提出要求？是否须特设“监管信息页”？

答：是的，平台官网必须至少包含：

  • 法律实体信息、注册地址、牌照编号；

  • 客户投诉处理机制介绍；

  • 投资风险披露声明；

  • 适当性声明（特别是高风险产品页面）；

  • 如适用，设立“监管合规中心”页面（Regulatory Information Center）。

附：《MiCA官网内容合规检查清单》。

Q991：MiCA是否允许平台为客户生成子账户或虚拟子钱包？是否属于混合钱包？

答：允许使用子账户结构，但必须满足：

  • 每个子账户必须与客户身份一一对应；

  • 资金不得在后台混合使用，需具备分账管理功能；

  • 不得使用虚拟子账户进行风险隔离规避客户保护义务；

  • 建议平台使用“独立子钱包地址 + 多签验证机制”。

推荐配套：子账户管理制度、钱包结构图、分账审计报告样本。

Q992：MiCA是否允许平台在“境外司法管辖区”提供服务？例如向香港、东南亚用户开放注册？

答：MiCA对服务范围不设强制限制，但若：

  • 平台主要用户为非欧盟居民；

  • 营运推广面向非欧盟国家；

  • 服务结构、语言界面优先匹配非欧盟市场；

则BoL可能认定平台缺乏“实质性欧盟服务重心（EU substance）”，可能不批准或撤销已发牌照。

如服务海外客户，建议设立多层结构并在境外设控股子公司、划分营运主体。

Q993：MiCA是否允许平台自建链或私有链系统？是否必须基于公开主链？

答：允许使用私链、自建链或联盟链，条件包括：

  • 需披露链的技术标准、共识机制、安全机制；

  • 若资产可在公开市场流通，需提供链与主链间的映射机制；

  • 平台不得私自修改链记录用于交易数据掩盖。

建议准备：链技术白皮书、安全性说明、链审计报告。

Q994：MiCA平台是否需设立独立“法律顾问”或“合规顾问”？是否强制本地？

答：非强制，但强烈建议配置：

  • 法律顾问：支持牌照申请、合同草拟、结构合规；

  • 合规顾问：协助建立AML/KYC制度、STR报告机制；

  • 本地顾问具备语言与监管沟通优势，更受BoL青睐。

建议提交：顾问协议复印件、顾问履历、法律/合规外包协议。

Q995：MiCA是否允许持牌平台设立“白标解决方案”或“二级运营平台”？

答：允许，但需：

  • 所有实际运营平台必须归属于持牌主体直接监管；

  • 白标业务不得规避责任或用户KYC/AML义务；

  • 建议对白标业务设立独立客户识别与合规界面。

强烈建议出具法律结构说明信（White Label Legal Mapping Letter）。

Q996：MiCA是否规定必须设置“公司治理架构图”？是否需提交董事会章程？

答：是，BoL通常要求：

  • 提交公司治理结构图（包含各职能部门、人员配置）；

  • 提供董事会章程、会议频率、议题范围；

  • 建议定期召开董事会并保留会议纪要。

推荐模板：Board Charter、Governance Policy、会议纪要样式。

Q997：MiCA是否允许平台将托管钱包外包？是否必须自建钱包系统？

答：允许外包钱包服务，但前提是：

  • 外包方必须是MiCA许可的托管商或具监管资质；

  • 外包协议须涵盖数据主权、系统访问控制、责任分配等；

  • 自建系统需通过审计、安全测试及权限控制审核。

附：钱包外包合规协议模板、安全接口文档。

Q998：平台是否可以同时申请MiCA CASP与EMI双重牌照？可否合并运营？

答：可以，MiCA与EMI并不冲突，但须满足：

  • 两类牌照分别满足注册资本金与监管要求；

  • 如拟合并营运平台，则必须系统权限分层、资金账户隔离；

  • 建议分别申请独立法律实体运营，如CASP公司 + EMI公司。

成功案例：爱沙尼亚Swaps.io、法国Flowdesk等。

Q999：BoL是否接受股东或核心人员为“隐私保护型基金”或“匿名信托结构”？

答：不接受。MiCA要求穿透所有最终受益人（UBO）至自然人层级：

  • 信托结构必须提供受托人身份证明与受益人全套KYC；

  • 私募基金须披露出资结构、投资人名单及管理人信息；

  • 不接受匿名架构、不明资金来源或模糊受益权控制关系。

附：UBO结构图模板 + KYC问卷样本。

Q1000：最终获批MiCA牌照后，是否可进行宣传？宣传时应注意哪些措辞？

答：
可宣传，但需合规：

  • 文案中应准确使用“CASP license issued by BoL under MiCA Regulation”；

  • 不得虚构服务范围、监管豁免、保本承诺；

  • 宣传材料建议附监管编号与官方网址验证链接。

推荐文案模板：

“Company XYZ is a licensed Crypto Asset Service Provider (CASP) under the MiCA Regulation, authorized by the Bank of Lithuania (License No. xxxxxx).”

Q1001：MiCA是否要求加密平台披露Token的源代码或审计报告？

答：是的，具体要求如下：

  • 如平台自行发行或托管特定代币（尤其是ART、EMT），必须披露其：

    • 智能合约源代码；

    • 安全审计报告；

    • 编码语言版本说明；

  • 该源代码必须可由监管机构、审计机构验证，不可加密隐藏；

  • 若使用开源协议，需指明Fork版本与自定义模块。

建议配合提供：GitHub仓库链接 + 第三方审计机构的报告摘要。

Q1002：MiCA是否允许平台支持“自动交易机器人”或“策略交易”？

答：允许，但必须合规控制：

  • 客户授权的自动交易程序（API bot）必须可识别行为来源；

  • 不得绕过交易指令确认机制；

  • 平台需设定“风险警示+权限管理+交易审计”三重机制。

平台应建立《自动化交易策略接入政策》并提供SDK/API权限控制清单。

Q1003：MiCA是否对“稳定币抵押结构”有专门监管条款？

答：有特别要求，尤其针对EMT类别：

  • 所有用于发行电子货币代币（EMT）的抵押资产须：

    • 存放于监管认可的金融机构；

    • 每日对账并每月审计；

    • 不得用于高风险投资（如股票、加密资产）。

建议发行方提前准备《储备资产结构说明书》与托管账户证明。

Q1004：是否可以委托第三方提供AML/KYC服务？是否影响平台责任？

答：可以委托，但责任仍归平台主体承担。

  • 可委托服务商（如Sumsub、Onfido、IDnow）完成KYC初步流程；

  • 平台需设立内部复核与监控机制；

  • 所有数据与决策权必须保留在CASP持牌机构内部。

推荐签署《KYC外包责任协议》并设定“最低复核频率 + 回溯审查机制”。

Q1005：MiCA是否允许平台发行非同质化代币（NFT）？需要单独申报吗？

答：可以发行NFT，但MiCA对其监管边界仍有争议：

  • 若NFT具备投资属性或拆分交易功能（如NFT基金份额），将被视为可转让加密资产；

  • 仅具收藏价值的NFT（如数字艺术、单件化物品）不属于MiCA监管范围；

  • 若NFT具有“支付、流通、投资、质押”等功能，应申请相应授权。

建议平台提供《NFT性质自评报告》并附《交易与转让功能说明》。

Q1006：MiCA牌照下是否可以支持Flash Loan（闪电贷）类功能？

答：高度敏感，建议避免或进行风险隔离。

  • Flash Loan若被用于快速套利、价格操纵、合同攻击，将严重影响平台信誉；

  • 如确需支持，需：

    • 设立交易限制；

    • 提供清晰的审计日志；

    • 禁止与核心资产组合功能叠加使用。

推荐独立建立“高风险功能审查委员会”并定期报告至BoL。

Q1007：平台是否可为客户提供“杠杆功能”或“衍生品交易”？MiCA是否允许？

答：MiCA不涵盖杠杆/衍生品的全面许可。

  • 杠杆或合约类产品属于MiFID II监管范畴；

  • 若涉及CFD、期货、期权等产品，必须申请MiFID授权；

  • MiCA牌照仅适用于现货类加密资产及其配套服务。

建议通过独立子公司或合规子结构在欧盟其他成员国申请衍生品牌照。

Q1008：平台是否必须对员工进行定期合规培训？如何记录？

答：必须进行，并设定年度培训计划。

  • 至少每年组织一次针对MiCA条文、AML/KYC更新、技术安全等内容的全员培训；

  • 培训需留存签到记录、培训材料、测验问卷；

  • 可使用线上LMS（Learning Management System）系统进行电子归档。

附：《年度合规培训清单模板 + 员工培训签到表样式》。

Q1009：平台的“冷钱包”与“热钱包”资金比例有监管建议吗？

答：MiCA未强制设定比例，但BoL有推荐实践：

  • 热钱包不宜超过总托管资产的20%；

  • 冷钱包须多签控制 + 离线保管 + 定期换密；

  • 建议设置三级钱包控制机制（热 / 冷 / 备用）+月度审计制度。

建议递交《钱包资产管理策略说明书 + 密钥管理制度》。

Q1010：MiCA是否强制平台提供“交易失败赔偿机制”或“技术纠错机制”？

答：强烈建议设立赔偿政策与技术救济机制。

  • 若因平台故障、系统错误造成用户损失，平台应承担赔偿责任；

  • 建议提前设立：

    • 客户服务响应时限；

    • 投诉处理机制；

    • 内部容灾模拟演练制度。

建议准备：《系统出错应急机制 + 客户赔偿处理流程图》。

Q1011：MiCA是否允许平台支持“可编程支付”或“智能合约定时触发”机制？

答：允许，但须具备监管可解释性与执行可控性：

  • 支持可编程支付（如基于智能合约定时支付、分阶段支付）需确保：

    • 客户知情并明确授权；

    • 智能合约逻辑公开、可审计；

    • 可随时暂停或终止，防止技术风险无限扩大；

  • 推荐建立《合约执行白名单机制》，限定合约来源。

附：可编程支付合规模型范例 + 监管声明模板。

Q1012：MiCA是否要求平台每日生成内部审计报告？如有，格式为何？

答：并无强制每日审计要求，但推荐如下实践：

  • 关键交易行为（如客户充值、提现、资产转账）应至少每日生成一份内部操作日志；

  • 若平台为托管型CASP，建议设置“每日合规核对清单”（Daily Compliance Checklist）；

  • 格式建议包含：

    • 时间戳；

    • 操作员；

    • 交易摘要；

    • 系统反馈/告警记录。

推荐结合内部SOP制度生成半自动审计报告。

Q1013：MiCA是否对平台营运使用的域名有特别规定？可否使用非本国后缀？

答：MiCA无域名强制要求，但需保障以下几点：

  • 域名须与持牌机构有注册绑定关系；

  • 域名信息须于BoL备案（含Whois资料）；

  • 非.eu / .lt域名可使用，但建议有清晰的重定向机制至欧盟境内官网；

  • 禁止使用匿名注册服务或隐藏注册人身份的服务。

域名使用策略建议附入《平台披露与透明性政策》中。

Q1014：MiCA牌照是否允许“预注册客户”在获批前先行开户登记？

答：理论允许“待激活式客户注册”，但不能激活使用。

  • 可开放客户预约或身份预登记模块；

  • 不得提供充值、交易、提币等功能；

  • 须明确声明“该服务尚未获得MiCA许可，待通知方可使用”。

附推荐模板：《客户注册免责声明文本》。

Q1015：平台是否可以接受DAO（去中心化自治组织）作为客户或合作方？

答：可以接受，但需特别审查其法律地位：

  • DAO作为客户，需有明确法人结构（如通过注册实体控股）；

  • 平台需审查DAO的治理结构、投票机制、控制人；

  • 若DAO为发行方，必须符合MiCA对白皮书与责任人的所有披露要求。

建议提供：《DAO结构穿透报告 + 实际控制人识别说明》。

Q1016：是否需要将交易平台接口(API)文档提交监管备案？

答：若平台支持API对接（如给券商/第三方钱包），需提交API说明文档作为技术附件。

  • 包括接口功能描述、安全控制措施、调用频率限制、权限区分；

  • 强烈建议设立API审查流程并形成正式《API接入政策》。

可一并递交《第三方技术接入风险评估表》。

Q1017：MiCA平台是否可设有“运营总监（COO）”或“首席风控官（CRO）”等职位？是否需强制上报？

答：可以设立，不强制上报，除非其涉及核心职能管理。

  • 若该人员为董事会成员、MLRO、RO或合规负责人，则需上报；

  • COO/CRO可作为运营支持职能；

  • 若实际参与客户资金、系统授权管理等，则建议备案其简历与责任范围。

建议列明非关键高管的《角色职责说明书》，供BoL现场检查参考。

Q1018：MiCA是否允许平台提供“Token兑换功能”但不涉及订单簿撮合？

答：可以，此类通常被归类为“经纪服务”或“交易便利服务”。

  • 不需设置订单簿；

  • 须以平台定价（如以中间价+手续费）直接向客户报价；

  • 须保留完整交易对账与撮合记录，防止价格操纵风险。

附推荐文件：《报价机制设计说明 + 客户告知机制》。

Q1019：MiCA牌照是否允许平台上线后修改已获批的客户服务条款或收费结构？

答：允许修改，但需提前更新披露并向BoL备案。

  • 所有客户相关文档（包括条款、费用结构）变更：

    • 须提前7–30日通知客户；

    • 同步更新官网披露；

    • 向BoL提交更新备案函。

建议每季度自审服务条款更新状况。

Q1020：MiCA平台是否可以设立“多语言客户服务团队”？是否必须使用立陶宛语？

答：平台服务语言可多语种，但须保障以下内容至少提供立陶宛语或英语版本：

  • 客户注册协议；

  • 披露文档；

  • 风险声明与合规通知；

  • 投诉流程说明。

客户服务建议配备英语 + 当地语种客服，提升合规体验。

Q1021：MiCA是否允许平台代客户管理其交易策略？例如设置自动挂单规则？

答：MiCA允许提供“交易辅助工具”，但不得进行“资产管理”性质的服务，除非另持牌：

  • 客户可以授权平台执行预设交易逻辑（如止盈止损、定时挂单等）；

  • 平台不得主动代客户进行组合配置、调仓决策等行为；

  • 所有自动交易功能必须：

    • 明确由客户设置；

    • 可由客户随时撤销；

    • 提供风险提示。

建议披露《自动交易功能使用说明书 + 风险披露模板》。

Q1022：MiCA申请人是否可以是“特殊目的实体（SPV）”？

答：监管原则上不鼓励使用SPV作为CASP实体，但以下条件下可被接受：

  • SPV有实际业务经营、实质性人员配置；

  • 股东与控制人清晰透明；

  • 注册地、办公地、主要营运地一致；

  • 不可用于“分离监管风险”或“规避财务责任”。

如使用SPV，建议提供《SPV功能说明函 + 控股集团合规结构图》。

Q1023：是否可以以区块链公链身份申请MiCA牌照？如DAO链、Layer1基金会？

答：链本身不可申请牌照，但若设有独立法律实体运营节点服务、托管服务等，则可申请成为CASP。

  • 需由注册法人作为申请主体；

  • 公链治理结构须穿透披露；

  • 若是基金会型结构，建议附基金会章程及实际控制人声明。

案例参考：某Layer1链通过其欧洲基金会法人在立陶宛申请MiCA交易牌照。

Q1024：是否可以为客户提供代币质押（staking）服务？

答：可以，MiCA允许提供Staking服务，前提是：

  • 明确为“非集体投资”行为；

  • 客户须同意质押条款并签署相关协议；

  • 质押资产与平台资产严格隔离；

  • 披露质押风险、锁仓期限、退出机制。

强烈建议制定《Staking服务协议 + 风险揭示书》。

Q1025：MiCA是否要求平台支持可读性无障碍政策（如残障人士可访问界面）？

答：MiCA未明文要求，但根据欧盟《数字服务法（DSA）》与《通用服务指引》，建议采纳以下标准：

  • 网站应符合WCAG 2.1无障碍标准；

  • 应提供：

    • 高对比度模式；

    • 屏幕阅读器适配；

    • 简体语言版本。

可将网站可访问性说明加入《平台使用条款》附录。

Q1026：MiCA监管机构是否有定期监管回访机制？多长时间一次？

答：有，BoL监管下的CASP主体将接受以下持续监管安排：

  • 每年一次远程或现场合规检查；

  • 可随机抽查财务审计报告、交易记录、客户投诉处理；

  • 特定风险类别（如虚拟资产衍生品交易平台）可能半年一次专项检查。

建议设立《监管回访应对指南》与专责团队。

Q1027：是否需要设立内部“授权人管理机制”（Power of Attorney）？

答：不强制，但强烈推荐设立：

  • 用于管理关键操作授权（如交易审批、提款审批、客户信息修改）；

  • 建立《权限审批矩阵表》及《操作日志备份政策》；

  • 防范内部人员越权操作或不当授权。

BoL在检查中高度重视权限边界与签名控制机制。

Q1028：MiCA牌照是否要求平台披露“客户服务响应时间标准”？

答：是的，客户服务响应机制属“营运披露”范畴。

  • 平台需公布：

    • 客户服务时间；

    • 投诉处理流程与时间；

    • 邮件/电话/工单响应时限（建议≤48小时）；

  • BoL可能会查验是否落实，并查看客户投诉记录。

附推荐模板：《客户服务标准白皮书》。

Q1029：MiCA平台可否允许使用多币种支付手续费（如USDT、ETH等）？

答：允许，但需遵循费用一致性与风险控制原则：

  • 平台可接受多币种支付；

  • 需清晰列出每币种折算汇率及更新频率；

  • 披露手续费折算可能引发的波动风险。

建议附上《手续费支付币种选择及汇率说明文档》。

Q1030：是否可使用“非合规国家”银行作为公司收款账户（如俄罗斯、伊朗）？

答：严禁使用受欧盟制裁或高风险国家的银行账户。

  • 公司银行账户须设于欧盟认可金融机构；

  • 否则可能视为违反反洗钱法与制裁条例；

  • 建议使用立陶宛、爱沙尼亚、德国等合规金融机构。

可附《银行账户合规声明》及开户合同复印件。

Q1031：平台是否必须提供“教育内容”或“新手引导”模块？

答：MiCA不强制要求，但建议平台提供投资者教育内容，体现其“适当性责任”。包括但不限于：

  • 风险揭示动画、图文解释；

  • 模拟交易功能；

  • 教学视频和术语词典；

  • 合规披露页跳转说明。

BoL鼓励平台展示“投资者赋能”机制，增强用户信任。

Q1032：MiCA是否允许使用外包KYC/AML服务商（如Sumsub、IDnow等）？

答：允许外包，但需满足以下监管条件：

  • 签署正式的服务外包协议；

  • 平台对最终KYC结果仍承担“最终责任”；

  • 外包商须接受平台年度审查；

  • 所有客户身份资料保留至少5年，并可随时调取。

建议提交《KYC外包责任声明 + 合同样本》。

Q1033：若发生平台客户资产被盗事件，MiCA牌照持有人是否需强制赔偿？

答：MiCA要求平台设立“客户资产保护”机制。若平台自身保管失误造成损失，原则上需承担赔偿责任：

  • 建议设立风险准备金或商业保险；

  • 客户资产托管建议使用冷钱包+多签；

  • 若事件因不可抗力发生，平台需提交事故报告与赔偿说明。

否则BoL可能吊销牌照或启动处罚程序。

Q1034：MiCA平台是否可以兼营NFT市场？

答：可视具体NFT业务类型决定：

  • 若NFT具备唯一性且非证券性质，MiCA监管较宽松；

  • 若NFT被“碎片化”、“金融化”或带有分红/收益分配等，则可能被界定为“加密证券”或需MiCA披露；

  • 建议平台单独设立NFT专页并附上功能分类说明。

可提前获取法律意见函确认合规边界。

Q1035：平台客户投诉是否需要统一登记？有没有最低回应标准？

答：MiCA要求设立“投诉登记与处理机制”，包括以下要点：

  • 设立客户投诉登记台账；

  • 回应时间不得超过15个工作日；

  • 若延迟回复，需说明理由并提交阶段性处理结果；

  • BoL可能要求查阅投诉处理台账记录。

推荐建立《客户投诉登记台账模板 + 定期汇总报告制度》。

Q1036：MiCA是否限制高频交易（HFT）或算法交易？

答：MiCA不禁止高频或算法交易，但须履行风险披露与系统防护责任：

  • 提前披露交易规则与撮合逻辑；

  • 限制交易频率过高、恶意刷单等行为；

  • 配置风控阈值、延迟撮合机制；

  • 提供《算法交易风险披露书》。

高频用户须额外进行“适当性评估”以确保理解风险。

Q1037：MiCA是否可接受持牌后公司跨国架构调整（如迁册至卢森堡）？

答：不可随意迁移主体注册地。若公司希望跨境迁册，需重新申请新辖区的MiCA批准，流程等同初次申请。

  • 不可在无BoL许可情况下注销立陶宛公司并转让业务；

  • 建议以集团方式开设新法人，由新法人重新申请。

否则原牌照将失效，BoL有权吊销许可并通知ESMA数据库。

Q1038：MiCA是否规定冷钱包密钥的备份方式？

答：MiCA要求冷钱包密钥必须：

  • 最少2/3签名控制（推荐多签）；

  • 备份至少保留2套密钥，分别存放于不同物理地点；

  • 加密备份应由受监管的托管服务商协助存放或平台内部安全团队管理。

强烈建议制定《冷钱包密钥管理制度 + 应急恢复流程图》。

Q1039：若公司项目因融资未完成导致业务暂停，MiCA牌照如何处理？

答：BoL允许公司“暂缓启动营运”，但须正式申请业务延期：

  • 提交《营运延期申请函》说明原因及预计启动时间；

  • 延期期间仍须履行报告义务（如年度报告、合规声明）；

  • 超过6个月未恢复营运，BoL有权注销牌照。

不建议盲目申请，如确实资金紧张可提交阶段性商业调整说明。

Q1040：MiCA是否要求平台设置“境外客户筛查系统”？如何处理禁止国家注册？

答：是，平台必须防止来自“高风险/受制裁国家”的客户注册。应配置以下机制：

  • 基于IP、手机号、文件识别进行地理区域限制；

  • 对受FATF或欧盟黑名单国家客户拒绝服务；

  • 若用户绕过限制注册，平台需能识别并中止服务。

建议设置“黑名单国家实时更新机制 + 定期审计记录”。

Q1041：MiCA是否要求每位客户开户前必须签署投资协议？

答：MiCA虽未强制“投资协议”，但要求平台确保客户知悉以下条款并同意：

  • 风险揭示声明（Risk Disclosure）；

  • 服务条款与客户协议（Terms of Use + Client Agreement）；

  • 客户资产存放与托管规则；

  • 交易费用、滑点、清算机制说明。

建议以电子方式获取确认，并留存操作日志作监管留档。

Q1042：MiCA平台是否允许设置“推荐返佣机制”？如何合规设置邀请奖励？

答：允许设置推荐计划，但需注意以下合规边界：

  • 不得进行误导性广告（如“稳赚”、“保本”等）；

  • 推荐人不得提供投资建议（否则构成MiFID II下投资服务）；

  • 奖励机制应公开透明，平台需负起税务申报与合规责任。

可使用“用户邀请码系统 + 不得引导投资行为”的设计结构。

Q1043：平台内设有“理财宝箱”“定期理财”等结构是否会违反MiCA规则？

答：可能涉及“集体投资计划（CIS）”或“利息诱导”，应谨慎：

  • 若本金+利息承诺明确，或回报来源不清晰，可能被视为证券类服务；

  • 应避免使用固定回报、保本收益、兑付承诺等语言；

  • 若需设计此类产品，建议另持牌照并提前提交“金融产品说明书”。

高风险结构建议不纳入MiCA初始申请，待获批后单独申请豁免或延展。

Q1044：MiCA平台是否允许客户使用“非实名钱包地址”进行存取？

答：不允许。所有客户入金地址与出金地址必须KYC绑定，满足“Travel Rule”的信息披露：

  • 若客户使用非平台钱包充值，需先完成KYC验证与归属确认；

  • 提现地址亦须归属于已验证客户本人；

  • 所有链上交易需保留交易链信息与审计轨迹。

平台应配置链上分析工具（如Chainalysis、TRM）进行地址归属验证。

Q1045：MiCA对董事会成员的居住地有要求吗？必须是立陶宛本地人？

答：MiCA并不强制董事为立陶宛居民，但至少一名高管或核心负责人应为立陶宛常驻人士或具有欧盟常驻地址，以确保：

  • 实质性管理（mind & management）留在当地；

  • 能与监管沟通、配合现场审查；

  • 有能力出席监管会议、配合信访投诉处理。

若无本地驻点人员，BoL可能要求设立本地代表或服务地址。

Q1046：平台是否可以只提供“加密钱包”，不涉及交易撮合业务？

答：可以，仅申请“CASP第1类服务”（保管加密资产与钱包服务）即可，相关要求如下：

  • 资本金至少€125,000；

  • 系统须通过冷钱包+多签控制；

  • 平台前端仅展示钱包余额与转账功能，不得有撮合系统。

纯钱包类项目在前期更容易申请，后期可再扩展交易业务。

Q1047：MiCA平台是否允许客户之间进行点对点P2P交易？

答：允许，但需满足以下监管合规要求：

  • 平台仍需履行KYC/AML责任；

  • 平台不得故意规避监管（即使不撮合也要监控交易流向）；

  • 需设定合理的风控额度与监控机制（防洗钱）；

  • 须披露P2P交易风险。

建议为P2P区独立开发KYC、风控模块，满足BoL监管要求。

Q1048：MiCA是否禁止向俄罗斯、伊朗等国家客户开放账户？

答：是，平台需设有“受限国家清单”，参考以下国际黑名单来源：

  • 欧盟制裁名单；

  • FATF高风险管辖名单；

  • OFAC SDN名单（美国）；

  • 联合国安全理事会制裁列表。

所有系统应配置 IP过滤、文件识别、风险客户拦截等功能。

Q1049：MiCA是否要求平台建立“月度合规报告”机制？是否有格式模板？

答：MiCA建议持牌机构设定周期性合规报告机制，BoL通常建议为：

  • 月度合规动态总结；

  • KYC/客户数量变化统计；

  • STR提交记录；

  • 新增或取消服务类别变更说明；

  • 内部稽核执行情况。

可参考《MiCA合规官月报模板》《AML/KYC动态监测表》。

Q1050：公司若未来不再经营MiCA业务，如何注销？会不会影响集团其他公司？

答：MiCA允许“主动注销”，需按如下流程处理：

  • 提交《牌照注销申请书》+ 清盘计划；

  • 提供客户资产清算、客户通知、退出机制安排；

  • 提交最终运营总结报告；

  • 获BoL确认后方可注销，并更新欧盟监管数据库（ESMA）。

若为集团公司，不影响其他地区牌照，但建议同步进行合规说明。

Q1051：MiCA CASP平台是否可允许客户交易 NFT？MiCA是否监管NFT？

答：MiCA本身并不直接监管非金融性质的NFT**，但若满足以下情况，可能被归类为“可转让证券类加密资产”：

  • NFT具有流通性（可在二级市场持续交易）；

  • NFT代表某种金融权益（如分红、利息、投票权）；

  • NFT为项目融资用途。

建议平台对NFT业务进行分类：

  • 纯艺术/收藏NFT：不在MiCA监管范畴；

  • 金融化NFT（如Fractional NFT）：需纳入监管，可能需申请MiFID II牌照。

Q1052：MiCA平台能否提供“质押（Staking）收益服务”？需要什么条件？

答：可提供质押服务，但须符合以下要求：

  • 质押机制必须透明、非保本、可溯源；

  • 平台不承担固定收益承诺；

  • 必须进行“质押协议披露”，明示风险；

  • 建议附加第三方链上验证或节点托管方资料。

若平台自行提供收益保障或再分配收益，可能被视为“集体投资工具”，触发额外监管义务。

Q1053：MiCA CASP是否可以支持稳定币（如USDC、USDT）交易？

答：可以，但稳定币（ART / EMT）在MiCA下属法案中具有专门监管要求：

  • 交易平台需验证稳定币发行方是否持MiCA认可牌照；

  • 稳定币不得用作清算资产时规避资金保护要求；

  • 若平台自己发行稳定币，还需单独申请EMT/ART发行人资格。

建议平台仅作为流通方支持USDT/USDC，不直接涉入发行环节。

Q1054：MiCA平台是否允许提供“杠杆交易”或“加密资产衍生品”？

答：MiCA不涵盖加密资产衍生品（如期货、期权），此类产品须纳入MiFID II**监管范畴。除非另持有相关牌照，否则平台不得：

  • 提供杠杆、合约交易；

  • 提供代币化衍生品交易市场；

  • 推广含杠杆属性产品。

若平台经营类似产品，必须向BoL说明“服务不属于MiCA框架”并附法律意见函。

Q1055：MiCA是否规定客户最低年龄限制？是否可允许18岁以下使用？

答：MiCA强调“客户适当性原则”，并未直接设定统一年龄门槛，但多数欧盟国家：

  • 要求最低开户年龄为18岁；

  • 若客户为未成年人，须提供监护人授权文件；

  • 建议在平台KYC模块中集成年龄验证机制（如身份证OCR + 实名比对）。

BoL在审查KYC时，会重点关注是否存在青少年客户群体的风险。

Q1056：MiCA是否禁止平台员工使用内部账户进行交易？

答：MiCA未禁止员工交易，但需设立“员工账户合规管理制度”**，包括：

  • 所有员工交易需事先报备或延时执行；

  • 高管与合规人员应限制交易；

  • 不得利用内幕信息或系统漏洞获利。

建议设定员工交易黑名单机制，并由合规官定期审计交易记录。

Q1057：平台如何识别客户是否为“受制裁人士”或“政治公众人物（PEP）”？

答：需配置自动筛查系统，建议集成以下数据库：

  • Dow Jones Watchlist、WorldCheck、Refinitiv；

  • 联合国安理会制裁名单；

  • 欧盟+美国OFAC制裁数据库；

  • 本国政府黑名单（立陶宛BoL或其他FATF会员国公布名单）；

系统须实现“持续监控 + 实时报警”，并留存筛查记录 ≥ 5年。

Q1058：MiCA平台是否可以允许客户通过信用卡充值？是否有限制？

答：允许，但须满足：

  • 信用卡充值需通过持牌支付机构/PSP进行；

  • 平台需对资金来源进行反洗钱筛查；

  • 严禁接受第三方信用卡或非实名支付方式；

  • 建议设定每日限额，并出具交易风险披露。

若频繁接收信用卡入金，平台将被视为“资金通道”，可能触发EMI/MiFID附加监管义务。

Q1059：平台若开展“联合营销”或“与其他平台共享用户数据”是否违反MiCA？

答：MiCA与GDPR联合适用，若共享客户数据，需获得客户明确授权，并确保以下内容：

  • 提供详细的“隐私政策”与“数据使用声明”；

  • 合作方也须具备等效的数据保护水平；

  • 用户可随时申请“删除其数据”或“拒绝数据使用”；

  • 平台不得强制捆绑服务。

如无充分数据处理协议，平台可能遭欧盟GDPR罚款（上限为全球营收4%）。

Q1060：MiCA平台是否允许客户自行创建代币并上市交易？

答：允许，但需平台具备完整的“Token Listing 审核机制”，包括：

  • 核实代币合规性（非证券类、非金融工具）；

  • 收集项目方披露文档（白皮书、团队信息、合规声明）；

  • 设立“Token风险等级评估表”；

  • 建议保留法律尽调报告，规避平台责任。

所有新上市代币必须纳入持续监管机制，BoL可随时调阅项目备案资料。

Q1061：MiCA平台是否需要设置“合规委员会”或内部监管小组？

答：MiCA虽未强制要求设立“合规委员会”，但推荐中大型平台设立以下治理结构：

  • 合规小组（Compliance Committee）：负责内部政策制定、违规事件调查；

  • AML/KYC责任官员汇报机制：直接向董事会报告合规风险；

  • 定期会议与记录归档制度：每季度审阅风险及监管更新。

BoL在评估平台治理结构时，会审查此类合规治理是否真实运作、记录完整。

Q1062：如果平台总部在香港，仅在立陶宛设子公司申请MiCA牌照，是否可行？

答：可以，但需满足以下条件：

  • 立陶宛实体为实际营运公司，具备实质性办公场地与团队；

  • 关键人员（RO/MLRO）驻立陶宛办公，并能接受BoL约谈；

  • 提供完整的“跨境母子公司关系披露”；

  • 母公司不能操控平台所有核心功能（如交易撮合、钱包权限等）；

避免“名义设立”情形，否则可能被视为规避监管，导致牌照驳回。

Q1063：MiCA是否允许平台客户同时拥有多个账户？如何设置规则？

答：允许，但平台需确保以下机制健全：

  • 每个客户账户需独立编号，避免交叉混用；

  • 实施KYC统一验证与关联账户识别（IP/银行卡/证件/邮箱等）；

  • 防止一人多账户用于“分散交易额度”或“洗钱”；

  • 应在《客户协议》中披露账户数量规则。

如监管机构发现客户一人多账户逃避监管义务，平台将被问责。

Q1064：客户使用Trezor、Ledger等外部钱包地址是否合规？平台如何处理？

答：允许客户使用自托管冷钱包，但平台必须建立以下规则：

  • 外部地址需登记并完成KYC绑定；

  • 所有转出需通过“链上监测工具”验证是否为合法地址；

  • 高风险地址（如TOR、混币器、黑市交易平台）需自动阻断；

  • 建议部署TRM Labs、Chainalysis或Crystal等合规工具。

平台仍需对“资金流动全路径”具备可审计追踪能力。

Q1065：MiCA平台是否可以允许“第三方开发者”接入API调用？需注意什么？

答：允许，但属于“技术集成授权场景”，平台需：

  • 与开发者签署《技术接入与数据保密协议》；

  • 明确开发者不得获取客户身份信息与交易指令；

  • 审查其是否利用API进行“套利、刷量、操控”等活动；

  • 建议设定API调用频率上限 + 审计日志。

第三方接入必须经内部技术审查，并备案其目的与接口权限。

Q1066：MiCA平台是否需要披露客户资金使用方式？如何进行资金透明化？

答：是的。平台必须保障客户资金的“分离存放 + 专户托管”，并向客户提供以下信息：

  • 所有资金托管银行名称与账户结构；

  • 客户每日可查询其持有资产的余额与变动；

  • 平台不得挪用客户资金进行自营操作或借贷；

  • 建议每季度向客户公布资金审计结果摘要。

如发现挪用、混用客户资金，将直接触发吊销牌照风险。

Q1067：MiCA是否禁止平台将加密资产用于“再质押”（Rehypothecation）或抵押借贷？

答：MiCA不完全禁止，但此类操作需经过严格申报：

  • 若平台将客户资产用于再质押，必须获得客户明确同意；

  • 提供风险披露 + 资产损失免责说明；

  • 平台需设有清算保护机制；

  • 建议设独立结构操作（如设SPV进行借贷/质押）。

若无充分风险控制，该行为可能构成违规挪用客户资产。

Q1068：MiCA平台是否可以提供“OTC大宗交易”服务？是否有附加要求？

答：可提供OTC服务，但需符合以下条件：

  • 平台须保留交易双方KYC/KYB资料；

  • 所有OTC交易必须链上记录，并留有合同备查；

  • 必须设立OTC交易限额与风险披露机制；

  • 建议设置AML自动筛查系统识别OTC异常交易。

大宗交易不能成为洗钱通道或掩盖真实交易结构。

Q1069：平台如何应对客户索赔？MiCA是否规定赔付保障制度？

答：MiCA未强制平台建立赔付基金，但平台应设有：

  • 《客户纠纷解决政策》；

  • 内部赔偿申请流程（15日内回复 + 登记追踪）；

  • 拟定合理的风险免责与强制赔偿条款；

  • 推荐建立“平台责任保险”或“交易所赔付储备金”。

BoL在核查平台时，会查看赔偿制度是否真实运行、赔付是否及时。

Q1070：MiCA平台是否允许进行“平台币”发行与交易？有何要求？

答：可以，但平台币需满足以下合规要求：

  • 不得承诺保值、分红、回购等金融属性；

  • 应提交《平台币白皮书》 + 披露《利益冲突管理制度》；

  • 如平台币作为交易手续费抵扣工具，需定期说明其逻辑；

  • 平台币若可在多平台交易，BoL可能要求履行额外披露义务。

所有平台币发行应事先提交申报与法律意见函。

Q1071：MiCA平台提供“质押Staking服务”是否必须持有CASP牌照？

答：必须。提供Staking服务属于“虚拟资产服务”，须持MiCA下的CASP牌照，且需履行以下义务：

  • 用户知情同意与风险披露；

  • 收益生成机制须完全透明（链上逻辑可验证）；

  • 平台不得承诺固定收益率或保底本金；

  • Staking所涉及的资产，需进行独立账户托管与链上记录。

如平台将Staking资金用于其他投资或未设风险隔离机制，将构成重大合规违规行为。

Q1072：MiCA是否允许“匿名币（如ZEC/XMR）”上线交易？合规条件有哪些？

答：MiCA未完全禁止匿名币，但要求平台对“隐私币”上线设定更高标准：

  • 必须可链上审计交易来源与目的（例如通过ViewKey机制）；

  • KYC/AML信息必须与用户交易绑定且可溯源；

  • 建议使用屏蔽机制（如仅允许提现至同名实名地址）；

  • 部分国家监管机构对匿名币明文限制，应查询监管公告。

若无法证明交易溯源或KYC控制有效，平台上线匿名币可能被BoL强制下架。

Q1073：MiCA是否允许平台托管非加密资产（如法币、证券型资产）？

答：MiCA的监管范围为加密资产服务提供商（CASP），对托管其他资产不作管辖；但：

  • 若托管法币资金，需持有相应电子货币或支付机构牌照；

  • 若托管证券型代币（Security Token），需遵守欧盟MiFID II规管。

若平台涉及跨资产类别托管，建议设立独立法人结构或子公司分隔业务线。

Q1074：MiCA平台是否允许“二级市场平台交易员自营做市”？如何防范操控行为？

答：允许平台设立自营做市商（Market Maker），但必须：

  • 明确披露做市账户身份及其权限；

  • 禁止做市行为与普通用户账户产生利益冲突（如提前知情）；

  • 实施交易行为审计与冲突识别机制；

  • 设立独立风控模型限制做市影响力。

平台需向BoL报备所有自营交易行为及监控系统，防范市场操纵。

Q1075：MiCA是否允许平台客户使用“信用卡”直接购买加密资产？是否受限制？

答：允许，但平台需满足如下条件：

  • 合作银行或支付机构具备支付服务许可证；

  • 所有法币转加密资产需绑定客户身份；

  • 若客户使用他人卡片、预付卡等工具，平台应主动识别与拦截；

  • 所有信用卡充值应受限于风险等级和额度设定。

平台应部署支付行为风控模型，识别盗刷、洗钱、欺诈交易风险。

Q1076：平台客户发生资产被盗、地址泄露，平台承担什么责任？MiCA有要求吗？

答：MiCA要求平台具备客户资产安全保障制度，如发生资产损失，责任认定依以下原则：

  • 若为平台系统或员工疏忽导致，平台全责；

  • 若为客户自身泄密（如助记词泄露），平台可免责，但需提供事后协助与记录；

  • 建议平台签署《数字资产托管责任协议》，明确免责与赔偿边界；

  • 可引入“第三方保险”机制覆盖热钱包存储损失风险。

BoL将要求平台建立“事件响应机制”并记录所有客户申诉与应对方案。

Q1077：MiCA对平台“审计报告”的提交频率及内容有何规定？

答：根据MiCA规范，平台需至少每年提交一次财务审计与合规审计报告，主要内容包括：

  • 客户资产余额核对 + 存储结构说明；

  • 冷热钱包管理机制评估；

  • 关键控制权限审查（签名权限、审批流程等）；

  • 交易行为记录抽查、KYC一致性检查、AML警报处理回顾；

  • 审计报告需由合格审计机构或注册审计人出具。

建议平台设“季度内部审计机制”，以提前发现问题。

Q1078：MiCA平台是否需要支持多语种（如英文+立陶宛文）服务界面？

答：强烈建议支持至少英文与立陶宛文双语界面。尤其涉及以下环节：

  • 用户注册页面、KYC资料提交；

  • 用户协议与隐私政策；

  • 交易界面与风险披露说明；

  • 客户支持（如客服邮件、在线答复）；

如平台仅提供英文界面，可能被视为未充分保护立陶宛用户权益。

Q1079：MiCA牌照下的冷钱包必须“完全离线”吗？如何定义合规的冷钱包？

答：MiCA未强制“完全离线”，但冷钱包应具备以下合规属性：

  • 不连接互联网，操作需多重签名或硬件签名；

  • 钱包私钥分片存储 + 审批机制 + 物理隔离；

  • 所有操作记录留存，可供BoL审计；

  • 使用知名厂商（如Ledger Vault、Fireblocks）更具可信度。

如冷钱包存在“伪离线”风险（如可远程控制），将被视为监管隐患。

Q1080：平台是否必须为所有操作保留操作日志？日志存储周期多长？

答：必须。MiCA要求平台保留完整审计与操作日志，内容包括：

  • 用户登录、修改、交易、提现等行为日志；

  • 内部员工操作日志（含系统后台）；

  • 钱包操作记录、签名行为、资金流动日志；

  • 日志需保存不少于5年，且必须可导出供BoL审计；

建议日志存储使用不可篡改机制（如区块链辅助存证或WORM存储）。

Q1081：平台是否允许客户通过API进行交易？是否需要额外合规措施？

答：允许，但平台须满足以下MiCA框架下的合规控制：

  • API接入用户需完成KYC/KYB认证，并记录其授权用途；

  • 限制交易频率和请求速率，防止DDoS与恶意套利；

  • 所有API操作记录应写入审计日志，供监管检查；

  • 若API用户为算法交易者或交易机器人，平台需识别其行为模式并加设风控门槛。

建议设置API密钥管理机制（如权限分层、过期控制、IP白名单等）。

Q1082：MiCA是否允许提供“返佣计划”或“邀请奖励”？合规边界如何控制？

答：允许，但必须满足反洗钱与广告规管双重要求：

  • 返佣对象需为真实完成KYC的自然人或法人；

  • 奖励不能构成误导性收益诱导，须披露其本质为“推广奖励”；

  • 不得引导“伪装身份开户”、多账户注册等操作；

  • 推荐人奖励金额应设置封顶机制，避免滥用。

所有返佣/邀请活动须在平台规则中写明，并向BoL备案重要推广活动内容。

Q1083：是否可以在MiCA框架下运营子品牌/白标平台？有何监管风险？

答：允许设立子品牌，但必须符合以下条件：

  • 所有交易与合规责任仍由持牌CASP承担；

  • 白标合作方不得对客户宣称具备“独立监管地位”；

  • 所有系统、钱包、用户数据必须集中受控，不能“多账套多权限割裂”；

  • 建议签署《白标合作协议》，将AML/KYC职责明确列入，并提交监管报告。

如合作方实质控制客户、资产或系统但未持牌，BoL可能认定为“非法营运”。

Q1084：MiCA CASP是否可以同时开展NFT交易业务？监管范围如何界定？

答：可以，但NFT需视其性质确定监管分类：

  • 若NFT具备“可分割性、可交易性、大规模发行性”——可能被认定为可转让加密资产（Fungible），纳入MiCA监管；

  • 若NFT确为“唯一性+不可分割”的数字收藏品，当前MiCA监管豁免；

  • 平台需设独立业务模块处理NFT，避免与主流可转让加密资产混用。

建议披露NFT交易不受MiCA保护，用户承担自行判断风险。

Q1085：平台上线新币前是否需要单独向监管审批？流程是什么？

答：MiCA允许平台自主上线资产，但要求以下步骤：

  1. 完成虚拟资产分类评估报告（Token Classification Assessment）；

  2. 编制资产风险披露文件（Token Listing Disclosure）；

  3. 内部风险合规审查流程通过，由RO与MLRO签字；

  4. 保存上线记录文件 ≥5年，随时可供BoL审查。

若上线资产构成电子货币、证券型资产或MiCAR定义中的ASPs（Asset-referenced Tokens）则需先向监管备案或注册。

Q1086：平台是否需要对客户交易行为进行行为评分或风险等级评估？

答：MiCA未强制评分模型，但鼓励平台引入如下机制：

  • 为每一用户建立“风险画像”（基于KYC+交易行为）；

  • 自动化标记异常行为模式（如交易时间分布、频率、链上行为）；

  • 评估模型应定期更新，并可人工干预核实；

  • 高风险客户应提升监控频率、冻结阈值或限额。

风险评估模型有助于防范合规事件，也有利于后续监管汇报。

Q1087：MiCA监管下是否允许“闪电贷（Flash Loan）”功能？

答：不鼓励提供闪电贷功能，原因如下：

  • 存在高度金融操控与市场滥用风险；

  • 监管认为闪电贷往往涉及绕过传统信用评估机制；

  • 若平台开放类似功能，需事先向BoL递交专项合规风险评估文件；

  • 建议设置“交易延迟、提现锁定机制”等防范链上套利滥用。

未申报的链上高风险机制一旦出事，BoL将直接追究平台责任。

Q1088：平台是否需要展示“授权标识”或监管编号？如何展示？

答：是。MiCA要求平台在官网/APP界面明显位置展示以下信息：

  • 法定持牌公司名称与注册编号；

  • 受监管主体国家与监管机构名称（如：立陶宛BoL）；

  • 监管牌照类型（如：MiCA CASP）；

  • 有效监管编号（Registration No.）与查询网址链接。

未展示者将被视为误导性运营或违反透明义务。

Q1089：平台可否支持用户导入第三方钱包？是否强制使用托管钱包？

答：MiCA未强制托管，平台可支持“自托管钱包接入”作为取款地址，但需满足：

  • 该地址必须为实名绑定地址；

  • 出金前验证链上签名以确认控制权归用户；

  • 第三方钱包地址需保存KYC匹配记录 ≥5年；

  • 平台需设置“地址白名单 + 出金延时 + 风险识别模型”。

自托管用户仍受MiCA约束，不可绕过AML规则。

Q1090：平台若出现“系统停机”“交易拥堵”是否需要向监管报告？

答：是。MiCA要求如下：

  • 系统性服务中断 ≥1小时，应向BoL提交临时报告；

  • 重大数据丢失、资产调拨异常、交易撮合错误，应于24小时内申报；

  • 需在15个工作日内补充事件分析与防范措施文件；

  • 建议平台建立“应急事件登记册”并设立MLRO专责处理。

监管对技术运营合规性也有明确审查与问责机制。

Q1091：MiCA CASP是否必须强制对客户资金进行银行级隔离？

答：是。MiCA明文要求：

  • 客户资金（Fiat）必须存放于独立隔离账户，通常在持牌银行开设；

  • 平台不得将客户资金与运营资金混合使用；

  • 客户资金账户不得用于平台融资、质押或抵押用途；

  • 平台需每日核对客户余额与银行账户资金匹配表，并保留纪录 ≥5年；

  • 可选设置“信托账户结构”以增强合规性和透明性。

建议在运营结构图中明确隔离账户架构及银行开户证明。

Q1092：MiCA是否允许使用稳定币进行交易结算？是否有限定币种？

答：允许，但有明确限制与指引：

  • 稳定币（如USDT、USDC）如为资产支持型代币（ART）或电子货币型代币（EMT），须在MiCA框架下由注册实体发行；

  • 非欧盟MiCA发行人所发稳定币，如无牌照支持，仅可作为过渡使用或测试用途；

  • 平台须定期披露结算资产稳定性与储备机制；

  • 高频、大规模结算仍建议优先使用欧元或银行内结算网络。

不得擅自接入未经MiCA注册的第三方稳定币，平台须评估币种法律状态。

Q1093：平台是否可为客户提供“杠杆交易”或“保证金账户”？

答：杠杆类产品高度敏感，MiCA目前并未全面涵盖杠杆或衍生品类交易：

  • 若平台计划推出杠杆服务，应视为金融工具衍生交易（under MiFID II），须申请欧盟投资公司牌照；

  • 若客户保证金设定为基于虚拟资产质押，还可能触发加密资产借贷监管条款；

  • 建议暂不在MiCA框架下直接提供杠杆产品，或仅做为模拟服务开放。

一旦涉及风险杠杆结构，BoL有权暂停服务并要求转由受MiFID监管的主体承接。

Q1094：是否可以与第三方支付机构合作进行法币充值/提现？是否需要申报？

答：可以合作，但平台应对第三方支付机构进行“合规尽调”：

  • 第三方支付机构必须为**欧盟境内持牌支付服务提供商（PSP）**或电子货币机构（EMI）；

  • 合作内容包括：KYC责任划分、资金流路径、客户投诉机制；

  • 与第三方签署《责任分配协议》并归档；

  • BoL可随时查核该类合作流程，平台须保留所有交易日志及对账记录。

与未持牌支付机构合作将被视为违反客户资金保障要求。

Q1095：平台客户资产是否必须100%托管在冷钱包中？如何界定合规比例？

答：不强制100%冷钱包托管，但MiCA与BoL建议如下：

  • 超过客户总资产70%需存储在冷钱包（offline air-gapped）；

  • 冷钱包私钥应采用多重签名（Multi-signature）或MPC机制；

  • 热钱包应设置风险限额（日限、时限、单笔限额）；

  • 冷钱包每日同步核账机制必须保留完整日志。

可引入第三方托管服务商（如BitGo、Ledger Enterprise）并要求其出具资产托管责任声明。

Q1096：MiCA对“链上交易可溯源性”有何要求？平台需建立何种审计机制？

答：MiCA要求平台具备交易活动的完整链上记录与审计路径：

  • 所有链上交易需保留TxID、时间戳、对应客户账号及资产信息；

  • 平台需接入区块链浏览器API或自建链上日志同步服务；

  • 每季度需对链上资产变动进行合规稽核，并存档报告；

  • 对涉及高风险地区或混币服务的链上地址，必须记录审查和风控措施。

可接入Chainalysis、Elliptic等审计服务以提升审查可信度。

Q1097：平台是否可发放自己的平台币（Utility Token）？是否要在MiCA下注册？

答：如平台币具备以下特征，将被视为MiCA监管对象：

  • 可用于交易抵扣、手续费优惠、持仓分红；

  • 在多个平台流通，或具备二级市场交易流动性；

  • 具备代币增值模型、分红回购模型等。

如上述情况存在，平台币须纳入MiCA框架，并注册为可转让加密资产或ART/EMT，需编制白皮书并报BoL备案。

不得以“仅内部使用”为名逃避MiCA监管义务。

Q1098：平台可以使用非欧盟国家（如新加坡、香港）的合规服务商吗？

答：可使用，但必须满足以下条件：

  • 服务内容不得触及欧盟监管责任核心事项（如客户KYC审核、风险评级决策）；

  • 若服务商参与关键职能（如AML监控系统维护），平台需设立本地应急方案并向BoL备案；

  • 所有数据处理须符合GDPR及立陶宛本地数据保护要求。

建议使用非欧盟服务商时与欧盟本地合规顾问双重把关，并签署服务级别协议（SLA）。

Q1099：是否可以提供Crypto-to-Crypto交易对（如BTC/ETH、USDT/SOL）？是否受限制？

答：允许提供Crypto-to-Crypto对，但MiCA规定：

  • 涉及的加密资产必须为MiCA框架内认可的资产；

  • 若任一币种为非MiCA注册的ART或EMT，应明确“不可作为支付手段或账户记账单位”；

  • 交易对应披露资产特性与波动性风险；

  • 平台应持续监测对手币种的合规变动（如某币被禁用）。

Crypto对的价格波动性更高，建议设置合理限价机制与止损工具。

Q1100：平台是否必须配置本地数据中心或本地服务器？可否使用云服务？

答：MiCA并未强制数据本地化，但BoL有以下合规建议：

  • 核心用户数据与私钥资料应设立“欧盟境内备份节点”；

  • 若使用云服务，必须选择通过ISO27001、SOC2等认证的服务商（如AWS欧洲区、Azure EU等）；

  • 数据跨境传输须符合GDPR与BoL数据出境指引；

  • 出现数据泄露、宕机、备份失败等情况，需在72小时内报送BoL事件通报。

高敏感数据建议多地冗余备份，私钥严禁传输至非加密路径或第三国数据中心。

Q1101：MiCA牌照持有者是否可以委托第三方运营客户服务中心或客服？

答：可以，但需符合以下要求：

  • 委托方需为欧盟境内实体，具备专业客户服务运营资质；

  • 客服须接受平台内部培训，并遵守BoL信息披露与客户保护规定；

  • 客户服务内容仅限非敏感操作（如一般咨询、非身份验证类问题）；

  • 平台应保留所有通话/通讯记录 ≥ 5 年，以备监管查核；

  • 客服不得擅自进行交易指令、密码重设或客户KYC核准。

建议客服中心服务合同中明确数据处理范围、安全义务及监管应对机制。

Q1102：MiCA牌照申请人是否必须有董事会？董事结构有哪些合规建议？

答：BoL未强制董事会结构，但MiCA合规建议包括：

  • 建议至少设置两名董事，其中一人必须为立陶宛或欧盟常驻居民；

  • 董事须具备5年以上金融/法律/科技管理经验；

  • 董事会职责须在章程中清晰列明（如风险控制、财务审查、内部稽核等）；

  • 所有会议纪要、决议需按季度报备或备查。

多董事架构将提高审批通过率，降低“关键人依赖”风险。

Q1103：平台在提供交易服务的同时是否可以提供“加密资产借贷”服务？

答：可提供，但需单独设立子业务线并满足以下合规条件：

  • 借贷产品需编制产品白皮书，说明年化利率、抵押方式、清算机制等；

  • 所涉代币若为ART/EMT，则受双重监管；

  • 平台需配置独立的风险评估与授信部门；

  • 必须设立风险准备金池、明确违约处理机制；

  • 客户同意书需明确资产再出借可能导致的损失风险。

MiCA下的加密资产借贷仍属“灰色地带”，建议设独立法律意见并逐步推进。

Q1104：MiCA平台是否允许客户使用匿名钱包接收资产？

答：不允许匿名钱包接入平台系统。MiCA及TFR联合要求：

  • 所有入金钱包（包括冷钱包）必须完成KYC识别；

  • 平台需验证该地址是否与客户身份匹配，可要求签名验证；

  • 对于来自外部非托管钱包（unhosted wallets），需存证该钱包地址关联信息；

  • 可使用“Travel Rule”合规方案传输地址信息至对方平台。

匿名地址的资产入账将触发STR（可疑交易报告）义务。

Q1105：MiCA是否允许平台通过DAO（去中心化自治组织）模式进行治理？

答：MiCA许可一定程度的DAO参与，但需满足“可监管性”原则：

  • 平台仍需设立法定实体作为服务提供人（Legal person in EU）；

  • DAO仅可作为建议或社区治理机制，而非取代平台核心决策；

  • 所有DAO提案执行应由法定实体最终批准；

  • DAO Token若涉及治理权+经济权益，可能被归类为证券型代币。

建议DAO设立时明确“非控股”属性，并设立“预警与问责机制”。

Q1106：是否可以通过股权众筹方式筹集MiCA牌照项目启动资金？

答：可以，但需区分“代币发行众筹”与“股权融资”路径：

  • 股权众筹应遵循欧盟《Crowdfunding Regulation》；

  • 发起方需披露完整项目计划书、财务预测、股东结构；

  • 不得向非专业投资人承诺固定回报或担保；

  • 若使用代币方式募集资金，须另行申请白皮书注册程序（如作为ART/EMT）。

募资过程中的合规披露与KYC/AML程序不能省略，务必保留完整审计链。

Q1107：MiCA对平台系统是否有压力测试、灾备要求？

答：有明确要求。平台必须：

  • 每年至少一次进行IT压力测试（包括并发处理、区块同步、撮合延迟）；

  • 每季度更新灾难恢复计划（DRP），涵盖关键服务恢复时间目标（RTO）；

  • 至少设立一个数据热备份中心于欧盟境内；

  • 灾备演练记录、测试报告需留存 ≥ 5 年并提交监管稽核；

  • 遇重大系统故障须于72小时内向BoL报告并公开说明。

建议建立自动化灾备切换脚本，并定期进行模拟演练。

Q1108：MiCA是否要求平台必须提供客户教育内容或“适当性提示”？

答：是。MiCA强调客户“信息对称与知情权”：

  • 平台需设立教育专页解释加密资产风险、市场波动性、监管边界；

  • 客户在注册或交易前，必须阅读并确认《风险披露声明》；

  • 针对零售客户提供模拟交易工具或风险评估测试（如投资偏好问卷）；

  • 对复杂产品（如杠杆、期权）必须设置知识门槛与经验判断题。

此类措施将有助于减少投诉、降低平台责任。

Q1109：申请MiCA时是否可以未立即开展业务，仅为“预注册”阶段备案？

答：可以。MiCA允许企业以“拟营运状态”提交申请，但需满足：

  • 提供详细的业务计划（12–18个月）；

  • 提交合规框架、人员配置、拟上线时间表；

  • 说明资金准备情况与后续融资路径；

  • 承诺在牌照获批6个月内上线运营，否则监管机关可撤销许可。

此模式适用于尚在开发阶段、但已搭建合规架构的初创平台。

Q1110：MiCA对“冷钱包私钥”有无加密标准或存储要求？

答：有明确指引，包括：

  • 私钥必须加密保存，采用FIPS 140-2或同等级别的硬件安全模块（HSM）；

  • 建议分层权限配置（2–3人共签制度）；

  • 禁止存储在公开网络或通用硬盘中；

  • 每次私钥操作都应记录访问人、操作时间、链上影响；

  • 定期更换私钥或定期更换管理人权限。

使用Ledger Vault、Fireblocks等MPC架构可显著提升监管满意度。

Q1111：MiCA是否接受“多签”冷钱包管理机制？

答：接受，且属于监管推荐做法之一：

  • 多签机制（Multi-signature Wallet）可用于冷钱包管理、资产出入金；

  • 建议配置为“N-of-M”模式（如3人中2人签名），提升安全性；

  • 每个签署人应具备AML背景审查及签名日志备案；

  • 多签结构必须有预案以应对其中一人失联或被解雇的情形；

  • 建议多签私钥地理分布于不同国家，满足灾备要求。

可配合MPC（多方计算）框架构建更高等级的冷钱包权限控制。

Q1112：MiCA对NFT类项目是否一律排除监管？

答：不一律排除。是否受MiCA监管取决于其“可交易性”与“同质性”：

  • 若NFT代表唯一性艺术品、收藏品，且非可分割，通常不受MiCA监管；

  • 若NFT支持可拆分、频繁交易、具有投资功能，可能被视作资产通证（Crypto-Asset）；

  • 若NFT平台提供交易撮合、钱包管理等功能，也可能触发CASP义务；

  • 部分游戏类NFT（如GameFi）需额外分析代币经济模型。

建议项目方出具法律意见书澄清NFT性质与用途，并标明是否受MiCA约束。

Q1113：是否必须在立陶宛设立办公室，才能获得MiCA牌照？

答：不强制必须实体办公室，但以下条件必须满足：

  • 在立陶宛设立实体法人，拥有有效注册地址（可由秘书公司提供）；

  • 至少一名核心人员（如MLRO、技术负责人）为常驻立陶宛或可定期到访；

  • 应有固定通讯机制与可接触的合规联络人；

  • 若采用虚拟办公室，则必须确保文件接收、监管信件签收正常运行。

如未来需要申请“护照通行”，建议在立陶宛实际配置人员办公区，提升可信度。

Q1114：MiCA对“奖励机制”、“挖矿激励”是否存在特别监管要求？

答：若奖励与激励机制构成经济诱因，可能触发以下监管边界：

  • 若用户通过推荐他人注册/交易获得代币，可能构成“营销+发行”双重义务；

  • 若奖励代币本身有交易流通功能，需考虑其是否构成MiCA下的Crypto-asset；

  • MiCA鼓励平台披露所有奖励模型设计，避免形成庞氏结构；

  • 若项目含Staking奖励，需提供验证节点机制说明与锁仓计划。

建议提前披露代币经济模型、奖励算法、发放规则及潜在监管解释。

Q1115：MiCA要求平台必须接入“第三方合规报告系统”吗？

答：不是强制要求，但监管鼓励平台采用第三方合规审查服务：

  • 第三方可协助提交定期报告（年度报表、风险审查、AML报告）；

  • BoL认可如Sumsub、IDnow等做身份验证、KYC存证；

  • 第三方审计机构出具的《内部控制报告》或《合规性报告》更具公信力；

  • 如无第三方系统，平台须建立自主审查制度并保留完整记录。

在初期申请阶段，可同步委托外部服务，节省人力成本，提升通过率。

Q1116：是否可以先申请MiCA简化牌照，仅开展部分服务？

答：MiCA不设置“简易牌照”，但业务范围可细化申请，仅限单项服务开展：

  • 申请CASP时，可选择如下部分服务项申请：

    • 虚拟资产交易撮合

    • 代币发行托管

    • 钱包托管服务

    • 法币兑付服务

  • 每个服务项均需单独说明系统、人员、流程与风险控制；

  • 后期如拟扩展业务，须再次向BoL报批并更新合规文档。

建议初期可聚焦在交易撮合与法币兑付服务两项，先申请较易通过的部分。

Q1117：MiCA对虚拟资产平台的“链上操作权限”是否有监管约束？

答：有约束。平台不得“绕过”监管，以链上智能合约替代内部管控：

  • 所有链上操作（如清算、销毁、转账）应嵌入合规流程中；

  • BoL要求清晰列明私钥控制方、交易触发机制、系统审核路径；

  • 若采用链上合约+链下风控模型，必须确保有“暂停/回滚”机制；

  • 建议平台保留操作日志链上同步接口供审计使用。

 “黑盒式”的链上模块若不受控制，可能被视为违反可追溯性原则。

Q1118：MiCA对平台的“法币兑付”功能是否需持有EMI牌照？

答：若仅支持虚拟资产兑换法币（如出售ETH换EUR），不需EMI牌照，但需说明：

  • 法币结算服务由第三方金融机构提供（如银行、电汇服务商）；

  • 兑付流程明确平台不直接吸收法币，而由用户与支付机构直接对接；

  • 若平台自行提供法币账户（如客户余额账户），则可能触发电子货币监管（需EMI）；

  • 建议所有兑付记录经由第三方支付网关处理。

可采用EMI合作方或通过支付指令API整合法币出入金逻辑，确保平台无实际控金义务。

Q1119：MiCA是否支持“跨链转账”、“桥接服务”？

答：MiCA未禁止，但强调需对跨链风险予以详尽披露与技术合规处理：

  • 跨链操作应披露智能合约代码、安全审计结果；

  • 若桥接服务涉及发行包装代币（Wrapped Token），须明确包装资产是否为MiCA下资产；

  • 桥接提供者应纳入平台服务者清单，接受统一监管；

  • 所有跨链交易应保留链上记录，并说明交易发起/确认机制。

如使用跨链桥建议优先使用开放协议（如LayerZero）并出具第三方安全审计报告。

Q1120：MiCA是否要求平台必须向客户出具交易对账单或财务报表？

答：是，客户保护为MiCA重要原则之一。平台须：

  • 每月向客户出具账户摘要，包括余额、交易详情、费用；

  • 所有报表格式需可导出为CSV/PDF，具备归档与追踪功能；

  • 对于重大交易（如大额提款、提现失败）应发送单独通知；

  • 平台应提供交易纠错渠道并记录处理结果；

  • 客户数据储存 ≥ 5 年，不得删改。

建议设立“客户交易中心”或“报表导出模块”，标准化对账单格式，避免纠纷。

Q1121：MiCA是否规定必须使用欧盟本地托管服务商？

答：不强制使用欧盟本地托管商，但需满足以下条件：

  • 所选托管商必须接受欧盟法律的司法管辖；

  • 托管协议须包括灾备机制、密钥管理责任划分、终止条款；

  • 若托管商位于欧盟以外国家，必须提供：

    • 该国监管等效性说明；

    • 客户资产分隔与追索保护证明；

    • 数据保护合规声明（符合GDPR）。

最佳实践：优先选择在欧盟注册或受MiCA监管的托管商（如BitGo Europe、Ledger Vault France）。

Q1122：MiCA下的平台是否可以提供“保证金交易”或“杠杆产品”？

答：仅在满足以下监管限制与风险披露条件下可以：

  • 平台须设立风险控制制度，评估客户适当性；

  • 杠杆上限应符合“专业客户/零售客户”分类标准；

  • 须披露风险信息，签署知情确认书；

  • 平台应配有强平机制、止损系统与风控告警系统；

  • 若提供CFD（差价合约）类产品，需遵守相关《MiFID II》产品干预机制。

一般建议MiCA初期申请不包含杠杆交易模块，待基础业务成熟后追加申报。

Q1123：MiCA对DAO（去中心化自治组织）是否有监管适用性？

答：MiCA目前并未明文涵盖DAO，但若DAO结构涉及以下业务则间接适用：

  • DAO发行代币、接收用户投资、运营交易平台，即构成“Crypto-Asset Service”；

  • 即便为去中心化治理，只要存在链下接口、管理人或团队，即可识别合规责任人；

  • BoL监管思路：任何“可识别的人”均可成为监管对象。

若DAO申请MiCA牌照，建议设立法人包壳（如在立陶宛注册法人实体承接DAO服务），明确法律关系。

Q1124：MiCA如何看待“矿工奖励”所生成的资产？是否纳入监管？

答：MiCA区分是否涉及“对公众发行”或“作为金融产品提供”：

  • 纯粹出块所得、不向公众销售、不进行募资的“矿工奖励”，不纳入监管；

  • 若将所生成资产上市交易、对公众营销或用于支付，则可能触发MiCA适用；

  • 若矿池平台接受客户委托代挖，并收取管理费用，视作“服务型CASP”，须纳管。

推荐做法：区分资产用途（保留/交易/支付）并设置透明挖矿奖励模型披露文档。

Q1125：MiCA是否允许使用匿名币（如Monero、Zcash）进行交易？

答：MiCA本身未全面禁止匿名币，但受限于AML法规与欧盟高风险资产审查制度：

  • 平台应拒绝完全不可追溯的交易；

  • 若支持匿名币，必须具备“KYC绑定机制”（如Zcash t-addr 需实名）；

  • 建议将匿名币交易限定于“已实名账户之间”并记录链上轨迹；

  • 强烈不建议支持“完全匿名转入”功能（如Tor隐藏节点、跳板地址）。

实操中，多数合规平台会明确在条款中排除匿名币交易服务以降低监管风险。

Q1126：平台设立“Token Listing委员会”是否是MiCA合规必要动作？

答：非强制设立，但属于推荐性“治理合规动作”：

  • Listing委员会负责评估代币是否具备合法性、经济合理性、安全性；

  • 应记录每个上市决策的合规会议纪要；

  • 可引入外部合规顾问作为观察员参与决策；

  • 委员会建议包括合规、技术、产品、市场多维成员组成。

可将委员会机制纳入平台运营政策说明书，提升监管透明度与信任度。

Q1127：MiCA对稳定币（ART/EMT）提供者的税务申报有哪些要求？

答：若在欧盟发行资产参考通证（ART）或电子货币通证（EMT）：

  • 须按季度/年度向本地税务机关申报收入、资本利得、客户利息等项目；

  • EMT可能涉及增值税、利息税、客户负债确认等税务问题；

  • BoL鼓励发行方聘请专业会计师出具《年度税务合规报告》；

  • 所有客户存放的资产应纳入平台资产负债表。

可参考立陶宛税务局VMI发布的Crypto资产税务指南及跨境税务处理要求。

Q1128：MiCA是否认可以“第三国法”为依据的服务协议？

答：服务协议可以使用第三国法律（如新加坡法、英美法），但应满足以下条件：

  • 客户在签署时清楚知情协议适用法律并明示；

  • 合同争议处理应优先在欧盟境内仲裁或法院处理；

  • 数据保护部分必须符合GDPR规定；

  • 如客户在欧盟境内，可强制适用欧盟消费者保护法。

最佳做法：使用“双法版本”协议，即合同受英美法约束，但关键条款另附欧盟合规补充条款。

Q1129：客户在MiCA平台的余额是否属于平台公司资产？

答：否。客户资产应严格与平台运营资产隔离。

  • 客户余额为“信托持有”或“委托托管”性资金，不得用于公司运营；

  • 平台须建立独立账套记录客户每一笔余额变动；

  • 若公司破产，客户资产必须可被追溯并优先赔偿；

  • 建议设立“客户资产独立账户”并定期进行余额核对与审计。

可设立“客户资金信托账户（Client Fund Trust Account）”模式，并披露资产保护政策。

Q1130：MiCA平台是否需披露与合作伙伴（如EMI、KYC供应商）的关系？

答：是的，平台须披露所有外部合作服务商，并说明其角色与法律关系：

  • 应提供合作协议摘要或备忘录（MoU）；

  • 披露服务范围、责任归属、替代机制；

  • 合规审核是否由平台或供应商主导；

  • 如供应商出错是否由平台承担监管责任。

可在《外部服务供应商合规表》中统一列示各服务商名称、服务项、资质与联系方式。

Q1131：如果平台出现“客户资产盗窃”事件，MiCA如何界定法律责任？

答：MiCA下平台运营者承担初步责任，除非能证明：

  • 客户因自身过失（如泄露私钥）导致；

  • 平台具备完善的冷/热钱包管理与签名审批机制；

  • 平台事发后即刻启动应急处理并向BoL报告；

  • 第三方托管服务有不可抗力免责条款，并符合审计标准。

建议所有平台实施“事后追溯+应急补偿机制”并购买网络保险（Crypto Crime Insurance）。

Q1132：平台是否必须在法律文本中注明“免责声明”？有哪些不可豁免责任？

答：MiCA接受合理范围的免责声明，但以下责任不得豁免：

  • 平台丧失客户资产的直接责任；

  • KYC失误引发的洗钱事件；

  • 重大信息未披露导致客户决策失误；

  • 非公开利益冲突安排。

所有免责条款应以明示格式呈现，推荐独立展示《风险揭示书》而非藏匿于服务条款尾部。

Q1133：MiCA是否允许平台使用AI或自动化系统进行KYC？

答：允许使用AI进行辅助判断，但须具备“人类最终审核”机制。

  • KYC程序中所有关键识别步骤（如ID识别、地址验证）必须人工复核；

  • 自动化系统需定期验证准确性，避免误杀/误放；

  • 所有AI判断记录应保存，并可供监管抽查。

可设立“AI辅助+人工双轨复核”流程，例如：自动打分<80需强制人工复审。

Q1134：MiCA如何定义“托管失败”或“系统故障”责任？

答：托管失败责任由平台与托管方共同承担。

  • 平台须制定系统宕机响应机制（Disaster Recovery Plan）；

  • 如因托管商故障引发客户资产损失，平台应负责协调赔付；

  • 所有系统必须具备三层备份机制、隔日快照与多签控制策略；

  • 平台宕机须在4小时内通报BoL并记录事故日志。

最佳实践：每日备份快照+多云存储+热冷钱包自动切换方案。

Q1135：是否必须披露平台团队的背景资料？需到何种详细程度？

答：MiCA要求公开平台核心高管（如CEO、CFO、MLRO）的以下信息：

  • 姓名、学历、金融/科技背景；

  • 曾任职企业及相关经验；

  • 是否有金融犯罪或违规历史；

  • 担任其他公司董事或利益冲突声明。

推荐在官网专页设置“管理团队”栏目，提供LinkedIn链接及监管信披备案编号。

Q1136：MiCA牌照能否被“出售”或“转让”？

答：不能直接转让，但可通过变更大股东或董事间接实现控制权转移。

  • 控股人变更需预先向BoL报告并经其审批；

  • 新控制人需满足适当人选审查（包括无犯罪记录、资历说明）；

  • 若变更幅度较大，BoL可能重新审核部分申请内容。

强烈不建议通过“影子控股”规避BoL监管，可采用“控股架构穿透图”向BoL展示完整控制链。

Q1137：平台是否必须建立“业务连续性计划”BCP？

答：是，MiCA明确要求所有CASP建立BCP（Business Continuity Plan）：

  • 内容包括：突发情况处理机制、异地备份节点、紧急通报制度；

  • 应涵盖：系统宕机、合规人员离任、技术瘫痪、供应商故障等场景；

  • BCP须每年更新一次并经董事会审批；

  • 平台应开展BCP演练，报告交由MLRO存档。

可使用标准模板：《CASP业务连续性方案BCP模板（附演练流程）》，并配合风险等级分类表格。

Q1138：MiCA如何界定“跨境服务”？我只在立陶宛注册但接受欧盟客户是否算跨境？

答：如平台客户来自其他欧盟国家，即构成MiCA意义下的“跨境服务”：

  • 平台须在接触客户所在国的监管名单中登记；

  • 部分国家需在提供服务前提前通报（如德国BaFin、法国AMF）；

  • 官方语言说明、风险披露、客户协议须具备当地语言版本；

  • 若属高风险业务，还需任命当地代表联系人。

建议采用“欧洲经济区通报程序（EEA Passporting）”，BoL许可后通知其他国家监管机构。

Q1139：平台能否代替客户进行税务申报？

答：可以提供“辅助申报服务”，但不承担最终税务责任。

  • 可向客户提供年度收益摘要（Capital Gains Statement）；

  • 客户须签署税务免责声明；

  • 可与第三方税务平台（如Koinly、TaxBit）合作提供个性化税务分析；

  • 若客户为公司，可代开收入发票（Invoice）并保留税务记录副本。

需标注：平台仅为技术工具提供者，非纳税义务人。

Q1140：MiCA下平台是否需要配备“信息披露官”或“公共沟通负责人”？

答：强烈建议设立“信息披露负责人（Disclosure Officer）”角色，职责包括：

  • 编制年度披露报告（如收益分布、客户分布、法律纠纷等）；

  • 应对客户查询与媒体访谈；

  • 审核所有对外披露资料（如白皮书、广告）；

  • 与BoL监管沟通窗口。

可由Compliance部门分支设立，避免合规与市场宣传信息不一致。

Q1141：如果CASP经营稳定币，是否必须提供抵押资产审计报告？

答：必须。根据MiCA第30条与第33条，所有E-Money Token（EMT）发行人需：

  • 提交第三方审计机构出具的储备资产证明报告；

  • 定期（至少每季度）更新抵押资产明细；

  • 储备资产必须存放在低风险可赎回资产中（如央行存款、国债）；

  • 必须区分平台自有资金与抵押金账册，确保清晰隔离。

推荐聘用具有审计资质的本地审计事务所，并遵循IFRS会计标准。

Q1142：MiCA要求如何处理平台客户的“未申领余额”或“长期不动资金”？

答：平台应设定明确规则：

  • 通知客户并保留其资金不低于3年；

  • 可设立“休眠账户管理机制”，如设定提醒频率；

  • 超过法定保留期未认领资金，须按当地金融法规处理（如上缴主管机关或特设账户）；

  • 不得擅自挪用、转入收益科目。

建议设立《Dormant Accounts Policy》，并由合规官年审其合理性。

Q1143：MiCA是否要求平台审查员工的“个人数字资产持仓”情况？

答：是，特别是以下人员：

  • 负责交易、资产上市、市场宣传的员工；

  • 所有合规与财务部门成员；

  • 董事会、执行委员会成员。

应建立“员工数字资产申报制度”，防止利益冲突。内容包括：

  • 定期申报所持加密资产种类及数量；

  • 限制员工参与平台发行/上线资产的交易；

  • 离职冷却期申报机制（如3个月内禁止大额提现或对冲）。

Q1144：平台是否需设置“终止服务”的流程？MiCA有无具体要求？

答：有。MiCA第60条规定：

  • 平台若决定终止CASP服务，须提前30日通知BoL和客户；

  • 须设立“用户资产清算期”及退款通道；

  • 所有客户资料、合规记录仍需保留5年以上；

  • 必须提供独立第三方报告说明终止原因及合规保障措施。

可制定《终止运营管理政策（Cessation Plan）》，并内含通知模板与存档要求。

Q1145：MiCA允许平台“赠送”代币或派发Airdrop吗？合规风险在哪里？

答：允许，但必须符合以下要求：

  • 不能隐瞒赠送的经济目的（如换取用户信息、诱导注册）；

  • 若Airdrop代币具金融工具属性，须事先完成白皮书注册；

  • 须设置用户认领机制，并提供风险披露；

  • 若赠送与交易挂钩，需符合广告与促销监管要求。

建议附加《免费分发免责声明》，并备案至BoL作为促销材料。

Q1146：平台可否根据用户国家或IP限制某些功能？是否违反MiCA跨境服务原则？

答：可以，前提是有合理的风险管理与合规理由，如：

  • 特定国家在FATF灰名单或高风险区域；

  • 用户当地法律限制某种产品交易；

  • 本地反洗钱义务与MiCA标准存在冲突。

限制措施应：

  • 明确告知用户理由；

  • 可设立“合规豁免申请机制”；

  • 留存限制规则备案记录，以备审计。

Q1147：MiCA是否允许匿名用户注册平台？是否可以设置部分免KYC交易？

答：不允许匿名账户，所有MiCA牌照持有平台必须进行完整KYC识别。

以下行为视为违规：

  • 不收集身份证明/地址证明；

  • 虚拟号码注册（如VoIP）；

  • 使用Tornado Cash或同类混币服务后不报警。

可允许低额度用户做初阶KYC（如仅持证核查），但必须设定交易限额（如€250/月）。

Q1148：若平台因重大违规被BoL吊销MiCA牌照，是否可申诉或复议？

答：可以。申诉程序包括：

  • 在BoL作出决定后10个工作日内提出异议说明；

  • 可聘请律师提交正式复议申请；

  • 若不服BoL决定，可进一步向立陶宛行政法院提起上诉。

吊销后若拟重启业务，需重新申请并披露前次违规详情，影响审核。

Q1149：平台是否需要对“算法稳定币”额外备案？MiCA对此有何态度？

答：MiCA严厉限制算法稳定币流通，理由是其波动性与不可控风险。

  • 不可用于日常支付目的；

  • 如被发现存在隐性锚定机制，将被视作非法EMT发行；

  • 即便非直接锚定，也需提交BoL完整技术说明；

  • BoL有权强制平台下架、冻结其交易对。

实操建议：如项目方拟发行类似币种，应明确标注“非稳定币”并禁止宣传其价格稳定性。

Q1150：平台是否可以通过“分布式组织”DAO结构运营？MiCA是否允许？

答：MiCA暂未直接禁止DAO，但强调需有“明确法律责任承担方”。

  • DAO可作为业务治理架构存在，但需设立法人主体申请MiCA；

  • 所有决策责任最终仍落于法人董事会；

  • 不得以DAO投票结构规避监管问责；

  • DAO成员不得干预平台合规职能。

推荐结构：DAO控制治理权 + 实体公司持牌并负责监管关系，保持透明问责路径。

Q1151：平台是否需设立“年度合规培训计划”？内容和频次有无硬性要求？

答：是。根据MiCA合规治理原则，平台应设立年度员工培训制度，尤其是涉及以下方面：

  • AML/CFT识别与报告机制；

  • 客户适当性评估制度；

  • 新法规与监管通函解读；

  • 新技术/新币种的风险管理（如DeFi/NFT）；

  • 内部违规上报机制。

建议：每年至少组织2次内部合规培训（可线上），每次培训须保留：

  • 培训计划大纲；

  • 参与名单；

  • 培训PPT或录像；

  • 效果评估记录。

Q1152：MiCA对平台处理客户“杠杆交易”有何监管要求？

答：MiCA本身不直接允许或禁止杠杆交易，但对风险控制设下高门槛：

  • 须在白皮书中说明杠杆机制；

  • 对应客户需额外适当性评估（如经验、净值）；

  • 须有自动平仓机制与最大亏损限制；

  • 杠杆资产如为证券型代币，还需符合MiFID/Prospectus等欧盟指令要求。

实操建议：平台不得对零经验客户开放杠杆权限，且应强制设定杠杆倍数上限（如≤5倍）。

Q1153：平台内设虚拟资产兑换功能是否需额外申请PSP/EMI许可？

答：一般不需，但以下情形除外：

  • 若涉及以欧元/法郎结算并提供预存余额或电子钱包服务；

  • 若提供支付功能（如收单、结算、自动扣款）；

  • 若服务超出“资产换资产”范围，涉及“客户资金处理”。

若有上述情况，建议同步申请立陶宛EMI（电子货币机构）或PI（支付机构）牌照。

Q1154：平台是否可以不对客户钱包收取保管费用？MiCA对收费模式有限制吗？

答：MiCA未强制要求收费，但对收费项目提出透明披露义务。

平台必须：

  • 在注册页面和用户协议中清晰展示所有费用；

  • 不得隐藏、捆绑或在非明确位置标注；

  • 任何临时调整（如活动优惠、费率调整）需提前通知用户至少7日；

  • 不得以技术手段限制用户转出资金以“节省成本”。

费用结构建议包含：充值费、提币费、托管费、交易手续费、账户管理费等。

Q1155：MiCA是否要求平台预设“危机应对与灾备机制”？具体需准备哪些材料？

答：必须设立完整的Business Continuity Plan（BCP）与Disaster Recovery Plan（DRP）。

需包含：

  1. 断网、数据丢失、攻击应对流程

  2. 客户资产快速提取方案

  3. 热/冷钱包自动切换机制

  4. 关键岗位替代人选与职责矩阵

  5. 模拟演练报告及改进计划

建议：每年开展1次以上应急演练，并在系统日志中保留证据供审计。

Q1156：平台是否可提供“加密抵押借贷服务”？MiCA允许此类业务吗？

答：MiCA对加密抵押贷款未直接禁止，但涉及多项监管衔接：

  • 借贷协议本质若涉及利息、清算权、强平机制，可能落入信贷或投资业务；

  • 借出币方需作风险揭示；

  • 若利率浮动或算法调整，须符合透明、公平原则；

  • 借贷过程中的抵押币须隔离于运营资金，按托管机制保存。

建议设立独立子公司运营该类服务，并取得必要监管许可（如融资许可）。

Q1157：平台能否禁止或限制用户“通过智能合约自动执行转账”？

答：MiCA允许平台对智能合约设限，前提是出于合规、风控、安全目的。

可通过下列方式限制：

  • 禁止接入黑名单地址的合约；

  • 限制合约自调用频次或金额；

  • 拦截调用混币服务的交易路径；

  • 强制审核智能合约部署方的KYC信息。

平台应向用户说明“可接入的合约标准”，并保留拦截机制透明化说明。

Q1158：MiCA是否强制要求平台接入TRAVEL RULE（旅行规则）机制？

答：是。MiCA平台必须符合FATF TRAVEL RULE，即：

  • 每笔交易中，必须记录并传送发送人和接收人的KYC信息；

  • 涉及跨平台转账的，需双方平台系统对接并验证信息一致性；

  • 如对方平台不接入TRAVEL RULE，则应标注为“高风险交易”并人工审核；

  • 最终KYC信息需保留不少于5年。

推荐接入Notabene、Sumsub、TRISA等提供合规Travel Rule API的供应商。

Q1159：MiCA平台是否可以为DAO、基金会或信托类机构开设账户？需哪些额外文件？

答：可以，但需进行“穿透式尽调”及“UBO识别”。

额外文件包括：

  • DAO治理机制与合约逻辑说明；

  • 基金会章程、注册证明、董事名册；

  • 信托契约文件、受托人KYC信息；

  • 控制人控制路径图（UBO Chart）；

  • 冻结/解冻资产机制说明。

所有非自然人客户，需提供最终控制人KYC及合理性说明。

Q1160：MiCA对跨境服务（passporting）有何技术接入要求？是否自动获得其他国家认可？

答：MiCA明确赋予CASP“欧盟通行证”（passporting）权利，但需履行下列程序：

  1. 向立陶宛BoL提交目标国家列表；

  2. 提供当地语言披露材料摘要；

  3. 披露是否设有分支或代表；

  4. 接受目标国监管机构补充要求（如反恐、税务合作）；

  5. 目标国监管机构无异议期满后（15日），可开始运营。

注意：MiCA通行证≠完全免除当地数据税务等义务，仍需个别国家备案。

Q1161：若平台服务对象是“非欧盟居民用户”，MiCA是否仍适用？

答：MiCA适用于服务“欧盟市场”的加密服务提供商（CASP），而非客户国籍本身。

只要平台：

  • 面向欧盟用户开放注册；

  • 在欧盟地区投放广告、提供服务或建立接口；

  • 在MiCA注册国以外的欧盟国家提供服务（需启动passport机制）；

即使客户是非欧盟居民（如新加坡、日本、香港），MiCA仍适用。

实操建议：如仅服务非欧盟客户，平台可不申请MiCA，但不得通过任何形式触达欧盟市场。

Q1162：MiCA下是否允许使用“代币化实物资产”（如黄金、房产）作为交易标的？

答：允许，但需遵守以下监管路径：

  • 如代币为资产参考代币（ART），需按照ART规定注册；

  • 如代币为电子货币代币（EMT），则适用EMT模式；

  • 若代币本质上为证券或基金份额，仍受MiFID II 或AIFMD监管。

此外，发行该类代币需确保：

  • 对应实物资产有明确托管安排；

  • 公布估值方法、流动性风险说明；

  • 具备明确赎回机制与责任方；

建议先明确代币的法律属性，再确定是否纳入MiCA或其他金融监管体系。

Q1163：MiCA是否强制平台公开“冷钱包地址”与“审计签名机制”？

答：MiCA未强制披露冷钱包地址，但要求平台具备：

  • 客户资产与平台资产隔离制度；

  • 资产托管结构（含热/冷钱包）审计报告；

  • 多签或权限分层机制说明；

  • 定期向BoL提交资产余额证明。

许多合规平台会主动公开冷钱包签名策略及托管服务提供者（如BitGo, Fireblocks）以增强信任。

Q1164：MiCA对“币安式平台”的Launchpad、IEO服务是否设有特殊限制？

答：IEO（首次交易所发行）行为属于资产发行，若由平台协助发行、营销，即视为“发行商”角色。

平台需承担以下义务：

  • 白皮书审查责任；

  • 披露与项目方的利益关系；

  • 承担项目尽职调查与风险揭示责任；

  • 若为稳定币、ART、EMT类代币，还需分别注册并受限额监管。

建议平台Launchpad业务设立专门子公司运营，并对项目收取“信息发布平台费用”，避免视为承销商。

Q1165：客户资产是否允许用于平台流动性管理或抵押借出？

答：禁止。MiCA强制客户资产独立托管，不得挪作他用。

平台不得：

  • 使用客户加密资产为他人提供流动性；

  • 将客户资产用作抵押申请贷款；

  • 为平台自营账户与客户账户之间提供垫资或对冲。

可允许客户主动参与流动性池（如AMM），但需明示其风险并通过智能合约实现“自托管”。

Q1166：MiCA是否要求平台必须设立内部稽核（Internal Audit）机制？是否可外包？

答：是，且优先鼓励内部独立合规审核机制，但可通过第三方专业机构外包。

平台需建立：

  • 年度审计计划；

  • 内部控制流程抽样核查；

  • 各部门SOP执行情况审阅；

  • 高风险用户行为抽查（如异常交易、大额提现）；

若委托外部稽核，应签署保密协议，保留审计底稿5年以上，并报告BoL。

Q1167：MiCA要求平台遵守“持续营运能力”，若计划退出市场该如何处理？

答：平台若主动撤牌或终止服务，必须提前至少3个月通知BoL及所有用户。

并提交：

  • 客户资产清算安排；

  • 数据存储备份方式；

  • 资金返还机制；

  • 后续责任承接（如申诉处理、合规调查应对）；

平台若无法继续运营，但无恶意行为，监管机构可能批准有条件退出。

Q1168：MiCA允许平台提供“多重币种账户”服务吗？例如用户账户同时持有ETH、USDC、BTC？

答：允许，MiCA对账户结构不设限，但必须提供以下功能与披露：

  • 每个币种单独显示余额、交易记录；

  • 各币种价值折算机制（需披露币种参考来源，如CoinMarketCap）；

  • 清晰列明每币种的手续费率；

  • 客户可随时转出单一币种，无最低限制。

推荐平台后台使用“分币种+总估值”双显示架构，确保对用户透明化展示。

Q1169：MiCA对平台是否强制要求设立“风险管理委员会”？

答：并不强制设立“委员会”形式，但必须具备风险识别、评估、缓解与应对机制。

平台可采取以下方式满足要求：

  • 委派合规负责人（CRO）主持风险会议；

  • 按季度汇总风险事件；

  • 分类记录操作风险、法律风险、系统风险、声誉风险；

  • 对接董事会设立“风险通报机制”。

若平台规模较大或涉及杠杆产品，建议正式设立“风险控制小组”并设独立预算。

Q1170：MiCA是否允许平台同时提供加密与传统金融产品？如基金、股票、结构化票据？

答：原则上允许，但需隔离运营并分别持牌。

MiCA仅监管加密资产及相关服务；若涉及传统金融产品，平台需申请：

  • MiFID II投顾/交易牌照；

  • AIFM或UCITS基金管理许可；

  • 银行或保险类许可（如EMI/PSD2/CRD IV）；

可通过“双实体”结构（如：A平台为加密服务，B平台为传统投资）运营，并通过防火墙机制隔离信息、资金、客户。

Q1171：MiCA是否要求所有平台强制启用“冷钱包”机制？

答：MiCA并未强制规定加密资产存储形式必须使用“冷钱包”，但明确要求：

  • 客户资产需“高安全级别”保护；

  • 平台必须说明其资产托管策略；

  • 热/冷钱包分配比例需在合规文件中载明；

  • 有多重签名、多方审批、硬件隔离等机制者为优。

实操建议：采用冷热钱包混合结构，核心资产（≥80%）使用冷钱包，多签+硬件设备控制；热钱包限于日常流通金额。

Q1172：平台是否必须披露其技术服务商与核心系统架构？

答：MiCA未强制公开技术供应商名单，但在监管提交中需完整披露以下内容：

  • 钱包系统架构（含私钥管理机制）；

  • 撮合系统（撮合模式、撮合逻辑、是否中心化）；

  • KYC、AML系统供应商（如Sumsub、Jumio）；

  • 日志系统、风险预警系统、备份方案；

  • 第三方技术集成服务或外包关系。

如使用白标系统，必须提供代码所有权证明或源代码审查权限。

Q1173：MiCA是否要求平台强制使用“本地数据存储”或“欧盟数据中心”？

答：MiCA强烈建议数据存放于欧盟，但未硬性要求本地存储。关键要求为：

  • 所有用户数据、交易记录、合规数据可被BoL或ESMA随时调取；

  • 数据必须加密、具备备份与灾难恢复机制；

  • 若使用境外云服务（如AWS、AliCloud），需说明访问权限管理与主权数据分离机制；

推荐使用欧洲数据中心（如：Hetzner、OVH）以降低数据跨境风险。

Q1174：MiCA是否允许平台开展加密资产的“杠杆交易”或“衍生品交易”？

答：MiCA本身不适用于“加密衍生品”（如期货、期权、CFD），但ESMA会要求平台在以下情况下持MiFID II牌照：

  • 提供加密资产为标的的合约型衍生产品；

  • 提供保证金交易、杠杆倍数说明或爆仓机制；

  • 使用复杂结构（如结构性票据）连接虚拟资产价格。

若仅提供现货交易及杠杆借贷（非衍生形式），仍可在MiCA范围内运营，但需披露利率、风险、自动清算规则。

Q1175：MiCA是否允许平台设立“交易竞赛”、“邀请返佣”等增长机制？

答：允许，但需具备以下合规边界：

  • 所有营销活动应透明披露参与规则、评审机制及奖励方式；

  • 不得诱导客户过度交易或虚假宣传；

  • 邀请返佣应通过实名路径（非匿名推荐码）并限制多层返佣；

  • 禁止高频返佣、团队奖金等类传销模式。

推荐平台设置每日/每月返佣上限，并保留风控审核机制。

Q1176：MiCA是否规定客户须实名制（KYC）才能浏览平台行情？

答：不强制实名浏览，但凡涉及以下操作，均需KYC：

  • 注册账户；

  • 开始充值或交易；

  • 提现操作；

  • 获得代币空投、参加平台活动、交易竞赛等。

行情数据、新闻浏览、基础教育资料可对公众开放。

Q1177：MiCA对“项目方”（即Token发行人）是否要求具备审计或白皮书公开标准？

答：MiCA对白皮书设有明确规定，具体包括：

  • 项目目标、代币性质、发行机制、团队背景；

  • 风险披露、赎回条款、对投资人义务说明；

  • 资金用途及募集所得资金的监管保障机制；

  • 白皮书需用简明语言撰写，语言为立陶宛语或英语，另附摘要。

对技术审计虽非强制，但BoL建议提供智能合约第三方审计报告（如CertiK、Slowmist）增强信任。

Q1178：MiCA平台是否可提供“质押奖励”（staking）服务？

答：允许提供Staking服务，但需声明为哪种形式：

  1. 链上委托型Staking（如ETH 2.0）：平台为客户提供节点代理，收入根据链上规则分配；

  2. 平台合约型Staking：由平台主导设计，用户存入代币并获得固定或浮动年化收益。

无论哪种形式，都需：

  • 明示年化收益率计算逻辑；

  • 披露风险（如主网故障、Slashing机制）；

  • 禁止承诺“保本”收益。

高收益Staking需披露收益来源与分润机制，防范变相P2P或理财产品化。

Q1179：MiCA是否允许平台使用“AI客服”或“智能合约自动运营”？

答：允许，且鼓励采用自动化合规与服务方式，但需确保以下要求：

  • 对AI客服应定期测试其判断准确性；

  • 所有AI回复须可回溯、存档；

  • 对外声明AI回答不构成法律意见；

  • 智能合约运营逻辑须提交至BoL备案，并设紧急停止机制（Kill Switch）；

平台应设立人类监管机制，避免AI行为失控。

Q1180：MiCA是否要求平台必须公开披露团队成员身份与履历？

答：对关键高管（如CEO、CRO、MLRO、CTO）强制要求公开披露。

披露内容包括：

  • 姓名与身份（可加密处理，但应可供BoL确认）；

  • 担任职务及责任；

  • 相关从业经历与合规背景说明；

  • 无刑事、欺诈、金融违规历史；

如团队成员为匿名或化名，仅限于非核心岗位，且平台须承担管理责任。

Q1181：MiCA是否允许平台运营“子品牌”或“白标”服务？

答：允许，但存在严格边界与责任界定：

  • 主平台作为MiCA持牌实体需对所有子品牌、白标平台承担连带监管责任；

  • 每一个子品牌或“Powered by”平台的客户接入、交易、存取款等，必须使用主平台合规架构；

  • 不得外包核心业务职能（如钱包管理、KYC、AML）；

  • 所有子品牌平台须统一由主实体申报合规文件与年审报表。

推荐在白标协议中写明监管职责划分与事件应对机制，避免MiCA责任风险外溢。

Q1182：MiCA牌照是否有最低运营期限要求？可以“取得后立即转让或关停”吗？

答：MiCA对最低运营期限无硬性规定，但存在以下隐含门槛：

  • 若在拿牌12个月内无实质业务或客户活动，BoL可能认定“滥用牌照资源”；

  • 若取得后即进行股权转让或更换控制人，须重新进行适当人选审查；

  • 频繁变更实际控制人将被列为高风险牌照。

建议至少维持12-18个月正常运营，形成一定客户记录与监管报表后再考虑转让。

Q1183：MiCA牌照获批后，是否可以“暂时不开业”或延迟上线？

答：允许延迟上线，但需满足以下合规条件：

  • 须向BoL申报预计上线时间表（通常为6个月内）；

  • 在此期间应持续提交内部合规记录与系统测试报告；

  • 禁止对外开展任何营销活动或交易服务；

  • 延期不得超过12个月，超期可能面临吊销或重新审核。

推荐设定“预上线阶段（Pre-launch）”，并同步准备合规备案文件与KPI提交计划。

Q1184：MiCA平台是否可以引入DAO机制或社区治理？

答：可行，但MiCA监管只认可“实体责任制”模型，即必须有法律上可追责的法人实体作为运营方。

DAO若作为技术/社区辅助机制，需满足：

  • 所有核心决策由MiCA持牌实体最终负责；

  • DAO成员对外无监管豁免，若涉及管理客户资产或代币分发，需承担合规责任；

  • 不能以DAO为由回避KYC/AML义务。

实操建议：平台可将DAO作为“建议委员会”角色，而非运营执行体。

Q1185：MiCA是否允许平台向全球客户开放服务？需要地域限制吗？

答：MiCA不禁止跨境客户接入，但平台需：

  • 明确披露“平台接受服务客户的司法辖区范围”；

  • 若面向非欧盟国家用户，仍需履行本地法律义务；

  • 针对高风险国家（FATF灰名单/黑名单）应自动阻断访问；

  • 平台网站与APP需具备地理屏蔽功能或IP/身份识别机制。

推荐定期更新黑名单地区，使用自动接入限制策略配合KYC系统。

Q1186：MiCA是否允许平台接受“公司账户”用户或B2B客户？

答：允许机构客户使用平台，但需注意以下事项：

  • 公司用户需提交完整KYC文件：企业注册证、股东结构、UBO信息、章程、董事身份证明等；

  • 若公司为信托、基金、SPV等结构体，需提供穿透式合规信息；

  • B2B客户参与Staking或托管服务时，需披露最终受益人及资产来源。

企业用户需签署独立风险揭示文件，列明其非零售客户保障对象。

Q1187：MiCA是否支持代币质押转授权或作为借贷抵押品？

答：允许，但平台需符合如下披露与风控要求：

  • 明示质押用途、抵押物估值方式、赎回条件；

  • 引入第三方估值或链上预言机机制以防抵押品波动风险；

  • 明确违约清算机制与利息设定逻辑；

  • 须取得客户知情确认与二次授权。

此类业务本质接近“借贷+质押”，建议与MiCA适用规则同步备案并加强法律审查。

Q1188：MiCA是否允许发行非公开交易的内部点数或积分？

答：允许，但须满足以下条件：

  • 不得具备“可转让性”或“价值交换功能”；

  • 仅限于平台内部使用（如优惠、排名奖励）；

  • 不得承诺可提现或兑换为虚拟资产/法币；

  • 不得与任何区块链发行代币绑定价值。

积分可作为客户激励机制，但不得变相充当证券或虚拟资产。

Q1189：MiCA是否要求所有合规文件使用立陶宛语？

答：并非强制立陶宛语，BoL接受以下语言：

  • 英文（广泛接受，建议优先使用）；

  • 立陶宛语（如平台主要面向本地用户）；

  • 某些关键文件（如客户协议、白皮书摘要）可提供多语言版本以增强披露义务。

建议核心合规文件以英文为主，另行准备当地语言版本用于客户沟通。

Q1190：MiCA平台是否可设立“沙盒模式”账户，用于测试客户操作？

答：允许设立测试环境，但需确保：

  • 测试账户与实际账户完全隔离，不得涉及真实资金；

  • 须标示为“模拟账户”或“Demo Mode”，避免用户混淆；

  • 不可通过模拟收益诱导投资行为；

  • 不得使用测试环境绕过KYC或AML流程。

沙盒环境适用于新用户教育、操作引导与系统测试，但应避免与真实交易账户结构混淆。

Q1191：MiCA平台是否可以设有不同“业务子线”分别运营托管、交易、发行等？

答：可以，但需满足合规隔离与责任归属：

  • 各子线若以品牌或业务板块形式存在，须统一由主MiCA实体承担监管义务；

  • 不可设立“多个牌照壳”规避统一资本金或审计要求；

  • 系统应当分模块记录客户交易、资产托管、代币发行记录，避免交叉混淆；

  • 每项业务需编制独立的SOP（标准作业流程）及内控文件。

推荐设置“多业务线控制矩阵”，并制定跨线冲突处理机制。

Q1192：MiCA是否允许平台引入“非托管钱包”或客户自托管机制？

答：MiCA允许用户使用自托管钱包，但平台需明确“交易责任边界”：

  • 使用外部钱包的用户仍需进行KYC/AML，平台不得免责；

  • 若平台不持有私钥，则须在客户协议中披露其对资产遗失无保管责任；

  • 平台不得为非托管钱包提供担保或取回服务；

  • 强烈建议设置冷/热钱包权限桥，并附多签机制。

若涉及跨链桥或DeFi交互，须申报额外风险暴露声明。

Q1193：平台是否可以将代币初始发行收入（即“发行筹资”）用于运营成本？

答：可以，但必须在白皮书及财务披露文件中明示用途：

  • 明确列出筹资金额分配结构（如50%技术开发、30%运营、20%储备）；

  • 每季度更新代币资金使用情况与剩余余额；

  • 不得用于非法用途或控股股东个人提取；

  • 应设置由董事会或治理委员会审批的资金调拨机制。

推荐设置“Token Use of Proceeds报告模板”供定期披露。

Q1194：MiCA是否允许平台作为“托管中介”对接第三方冷钱包？

答：可行，但平台须对所有托管链路承担最终责任：

  • 需签署正式的第三方托管协议，并向BoL备案；

  • 第三方须具备等效于EBA或ESMA认可的安全资质；

  • 客户资产出入链条中不得有“隐性中转方”或技术代理节点；

  • 平台仍需每日盘点资产余额与链上对应情况，防止链下滥用。

强烈建议使用带审计功能的链上钱包管理系统（如Fireblocks、Copper）。

Q1195：平台是否可以只申请“部分MiCA许可”而非全牌？

答：可以。MiCA将不同业务授权模块化，包括：

  • Crypto-Asset Service Provider（CASP）：

    • custody and administration

    • exchange crypto-to-fiat

    • exchange crypto-to-crypto

    • execution of orders

    • placing of crypto-assets

    • transfer services

  • Issuer of ART/EMT（资产参考币/电子货币型代币）

申请人可根据自身业务选择一项或多项牌照模块，但：

  • 每项服务需单独说明系统架构、合规风险与运营安排；

  • 即便只做一项服务，也需满足MiCA全套合规基线要求。

实务中建议起步阶段先申请3–4项核心服务，后期再扩展。

Q1196：MiCA平台是否允许推出“合规托管+OTC代币撮合”双业务？

答：可以，前提是业务边界清晰、系统分隔明确：

  • OTC撮合服务必须进行客户KYC并报告可疑交易；

  • 所有撮合产生的代币交割必须通过MiCA合规钱包体系结算；

  • 撮合数据应同步入监管报表系统，避免“链下交易绕监管”；

  • 平台不得为匿名账户提供撮合通道。

建议为OTC单独设置一个操作界面与合规流程，并形成撮合操作SOP。

Q1197：MiCA平台如何处理“客户请求销户”的情形？

答：平台必须为客户提供销户通道，并满足以下条件：

  • 提供“资产提取+账户注销”机制；

  • 若客户资产余额为零，平台应在30日内关闭账户；

  • 保留注销账户的交易记录 ≥5年；

  • 客户注销后不得以同一身份证明重新注册匿名账户。

推荐在APP/网页设置“销户申请”按钮并由合规团队审核执行。

Q1198：MiCA平台是否允许“推迟代币上线时间”或撤销发行？

答：允许变更发行时间，但需向BoL备案以下内容：

  • 延期原因（技术原因、市场考虑、监管沟通等）；

  • 新的上线时间及代币合规更新说明；

  • 投资者保护安排（如退还预售款项）；

  • 更新后的白皮书与公告。

若取消发行，须提交《代币发行终止报告》，并退还所有已收客户资产。

Q1199：平台是否必须强制设置“交易最低限额”与“最大限额”？

答：MiCA未强制设置交易额度上下限，但强烈建议平台依据以下进行风险控制：

  • 每笔交易上限：基于客户风险等级与资产性质设定（如≥10,000欧元需增强监控）；

  • 每日交易限额：防止账户被滥用或洗钱路径测试；

  • 初次充值限额：加强首次入金验证；

  • 出金冷却期：24–72小时冷却窗口建议。

配套设置“限额超标审批流程”，由合规或MLRO核准。

Q1200：MiCA是否要求平台定期进行“模拟事故演练”？

答：并非强制性规定，但作为最佳实践强烈建议：

  • 模拟包括数据泄露、资产丢失、系统宕机、黑客攻击、KYC数据库被盗等；

  • 每半年开展一次综合演练，并提交事故应对报告；

  • 所有演练应记录决策链、处置措施与恢复时间；

  • 向BoL呈报“事故演练执行情况汇报”。

可配合SOC 2审计和ISAE 3402框架标准进行演练设计。

Q1201：MiCA牌照申请是否要求本地实体必须拥有办公场所？

答：是的。MiCA监管要求实体必须具备“有效实体存在”（substance），包括但不限于：

  • 立陶宛本地注册地址（必须为真实可接收函件地址）；

  • 实际营运场所或可办公空间（如使用共享办公空间需提供租赁协议及工作日志）；

  • 本地雇员配置，尤其是关键岗位人员如RO、MLRO等；

  • 可接受监管现场检查并保存相关文件的物理地点。

BoL可能在审查期间实地查访地址，建议配合提供照片、访问记录等。

Q1202：MiCA平台是否可以远程或虚拟方式聘用所有员工？

答：非关键岗位可远程，关键职能岗位至少需一名在地实体成员：

  • 高管、合规、信息技术安全负责人中，需有至少一人常驻立陶宛；

  • 所有人员需签署正式劳动合同或服务协议；

  • 虽允许混合办公模式，但必须能够展示监管问询时的“工作路径追踪”；

  • 可采用VPN+系统登录记录等手段辅助证明其履职行为。

推荐至少在本地注册一家“雇主实体”，用于人事税务合规。

Q1203：申请MiCA牌照时是否需要提供“信息披露模板”或披露策略？

答：需要，申请文件中需附带以下内容：

  • 平台披露政策（Disclosure Policy）：包含披露形式、语言、更新频率等；

  • 白皮书信息模板：按MiCA第49–52条标准格式说明代币细节；

  • 风险披露清单：向客户说明投资、交易、托管等关键风险；

  • 利益冲突披露机制。

建议采用标准“客户告知文件包”形式交由客户签字确认。

Q1204：MiCA是否允许平台接入外部KYC服务商（如SumSub、Trulioo）？

答：允许，但平台最终仍承担客户识别责任：

  • 须确保第三方KYC服务具备GDPR与AML指引下的合规资质；

  • 签订正式KYC委托协议；

  • 平台应留存所有验证记录及回溯报告；

  • 监管方可能要求平台展示对KYC供应商的审查流程（Vendor Due Diligence）。

强烈建议平台搭建“KYC中控台”，便于统一审核与审计。

Q1205：MiCA是否允许多平台使用同一技术底层系统？

答：技术系统可共用，但应设独立的数据隔离层与权限控制结构：

  • 若集团内多个MiCA实体共用系统，需分别配置账号、加密凭证与日誌；

  • 必须向监管机构提交系统共享声明，说明共享边界与防火墙机制；

  • 不得通过系统共用“跨平台数据搬运”或“客户池合并”行为。

系统架构图中应标注每个MiCA牌照的“独占数据处理链条”。

Q1206：MiCA是否允许平台参与Staking业务？

答：仅在不构成“集体投资”或“证券属性”前提下，部分Staking服务可允许：

  • 平台需明确说明Staking是技术委托还是收益分享机制；

  • 任何形式的“收益承诺”或“固定回报”均可能触发证券性质审查；

  • 须披露验证节点控制结构、资金路径与收益分配逻辑；

  • 若使用第三方节点，需取得服务商资质与技术合规证明。

推荐先向BoL提交“Staking结构解释函”并取得初步意见。

Q1207：MiCA平台是否允许用户交易NFT？

答：MiCA本身不直接监管“不可替代代币（NFT）”，但平台仍承担AML合规义务：

  • 若NFT具备金融投资属性（如可拆分、具稳定收益或具证券结构），可能仍被纳入监管；

  • 平台需披露NFT分类、发行人背景与价值评估机制；

  • 平台不得允许匿名用户或“临时账户”进行NFT大额交易；

  • 建议为NFT市场设置独立AML监控模块，并定期报告异常行为。

如平台NFT交易量占比高，建议提交《MiCA-NFT风险豁免函》。

Q1208：MiCA是否对“算法稳定币”有明确监管态度？

答：MiCA明确禁止未经许可的“高风险算法稳定币”流通与面向公众推广：

  • 所有稳定币（ART或EMT）均须具备可审计的储备资产；

  • 算法机制不能作为稳定基础，尤其是未经储备支持的算法控制锚定；

  • 若发行平台涉及“链上自动调节机制”，必须接受EBA额外技术审查；

  • 不得用于跨境清算或支付，除非取得欧盟EMI牌照。

推荐所有“类稳定币”产品优先提交法律意见函及结构说明书。

Q1209：MiCA平台是否必须具备年度审计机制？

答：是的。所有持牌平台必须配备独立第三方审计机制，主要包括：

  • 财务报表审计（根据IFRS或本地GAAP）；

  • 系统安全性审计（如SOC2 Type II）；

  • AML与KYC制度审计；

  • 客户资产托管审计（不应混同运营资金）。

审计报告需提交BoL，并向客户披露财务与资产审查结果摘要。

Q1210：MiCA是否对平台广告与营销行为进行限制？

答：MiCA对营销材料与广告内容规定严格，必须：

  • 使用清晰、真实、不误导的语言；

  • 不得使用“保证盈利”、“无风险”等字眼；

  • 所有广告内容须事前由合规团队审查备案；

  • 平台不得向未完成KYC或风险评估的用户群体投放广告。

建议制定《广告合规政策》，并设广告审批登记簿。

Q1211：MiCA是否允许平台向非欧盟客户提供服务？

答：可以，但需符合“第三国服务提供规则”，包括以下要点：

  • 平台需在官网和条款中明确“非欧盟用户服务限制”；

  • 若属于主动招揽（如广告投放、主动推销），则需持有目标国家相关牌照；

  • 被动接入（reverse solicitation）模式可行，但平台需保留用户首次接入行为日志；

  • 所有非欧盟用户仍需完成完整KYC，并遵守AML/CTF标准。

建议制定《第三国用户接入政策》，并定期评估跨境风险。

Q1212：MiCA是否要求平台披露客户资金用途与资产结构？

答：是的，尤其适用于持有客户资产的平台（如交易所、钱包提供商）：

  • 须披露客户资金托管方式、银行名称、资产种类及是否参与收益管理；

  • 不得将客户资金用于平台运营、抵押或借贷用途；

  • 每季度需对客户资金独立审计并报告；

  • 资金保管结构应“分账户分客户”或“隔离池”管理。

推荐提交《客户资金保管政策》与《托管银行协议摘要》。

Q1213：MiCA牌照是否适用于托管型钱包（custodial wallet）与非托管钱包？

答：MiCA主要规管托管型钱包业务；非托管服务如仅提供技术支持则不强制持牌：

  • 托管钱包：需要MiCA牌照，必须保障私钥安全、交易日志、客户授权机制等；

  • 非托管钱包（如MetaMask类工具）：若不持有用户资产，可免责，但若涉及收取费用、平台托管入口等仍可能触发监管；

  • 所有钱包服务商应具备KYC嵌入、STR机制与交易监控系统。

推荐所有钱包类业务先完成《Wallet风险评估模型》。

Q1214：MiCA平台是否可以进行加密货币借贷业务？

答：平台若参与借贷业务（lending/borrowing），需额外合规说明：

  • 若平台担任借贷中介或运营池机制，须披露风险、还款机制、流动性安排；

  • 如存在利息收益分配，则可能被视为金融工具或集体投资；

  • 建议分拆业务结构并取得专业法律意见书。

对应文档建议提交《加密借贷操作框架说明书》和《客户同意风险揭示书》。

Q1215：平台上线新币种时，是否必须重新向监管备案？

答：是否备案取决于该币种是否属于MiCA涵盖范畴：

  • 若为资产参考代币（ART）、电子货币代币（EMT）、或具证券属性代币（Security Token），需重新提交更新说明；

  • 若为传统公链币种（如BTC、ETH）且未具MiCA所定义属性，可豁免；

  • 不论是否备案，平台必须有《Token Listing内部评估政策》。

建议使用标准化《Token Listing评估表模板》，便于审计与监管报告。

Q1216：MiCA是否对平台高管设置年龄或学历门槛？

答：MiCA未设硬性年龄或学历要求，但各国主管机关（如BoL）审查重点包括：

  • 具备适当金融、合规或技术背景；

  • 避免形同“挂名高管”或无实际参与运营；

  • 必须提交详尽履历、合规声明及无犯罪记录；

  • 若为年轻创业者团队，建议聘请有资历合规顾问或董事辅佐。

若出现资历不足风险，BoL可能要求强化合规架构或引入“监管顾问”。

Q1217：MiCA平台是否必须执行交易对手风险评估？

答：是的，尤其涉及清算、撮合、资产交换平台，必须评估对手方风险：

  • 包括是否具备牌照、是否有合规披露、历史交易行为；

  • 平台须设立Counterparty Risk Policy并定期更新名单；

  • 大额交易前须完成尽调记录或引入风控评分机制。

建议集成AML评分、信誉评级、API级风险管理逻辑于系统中。

Q1218：MiCA平台是否可以与DeFi协议对接？

答：MiCA未明文禁止与DeFi协议合作，但平台需承担所有由此产生的法律责任：

  • 平台需说明DeFi协议的透明度、安全性及资产控制路径；

  • 不得引导客户直接与DeFi协议交互绕过MiCA监管；

  • 建议设立“DeFi沙盒接口模块”并配套KYC、AML管控。

若拟与Uniswap、Aave等接入，必须有完整法律意见书+技术测试报告。

Q1219：MiCA是否要求提交公司年度业务总结报告？

答：是的，MiCA下所有持牌机构需向国家主管机关提交年度运营报告，内容包括：

  • 客户增长数据；

  • 风险事件与应对；

  • 合规体系调整；

  • 财务报表与审计意见；

  • 未来风险预测与应对策略。

报告建议每年Q1提交，并由合规官主导撰写。

Q1220：MiCA持牌平台是否可以提供法币出入金服务？

答：仅当平台取得欧盟内EMI或支付机构牌照时，方可直接提供出入金服务。否则需：

  • 与银行或支付机构合作，作为第三方通道；

  • 明确披露出入金路径、手续费、时间、受监管机构；

  • 对入金来源与出金用途实施监控并保留记录。

推荐制定《法币进出金监控政策》并设API对接银行合规接口。

Q1221：MiCA平台是否需要提供24小时客户服务？

答：MiCA并未强制要求全天候客服，但在合规实践中，平台需确保以下机制：

  • 出现交易错误、资产冻结、登录问题时能及时响应；

  • 对客户投诉设有专责人员并记录回复流程；

  • 高风险操作（如资产转出）出现异常应立即告警；

  • 建议建立多渠道客服（邮件、电话、在线表单）。

推荐建立《客户响应时间与服务等级协议（SLA）》，并定期回测。

Q1222：MiCA对商业计划书有强制格式要求吗？

答：是的，MiCA监管申请中要求提交详尽商业计划书（Business Plan），需包含：

  • 未来三年盈利预测及风险情景模拟；

  • 市场定位、竞争分析、差异化优势；

  • 法律结构图、人员配置图；

  • 系统部署架构及关键服务供应商；

  • 资金来源与用途细化。

使用官方推荐格式撰写，并附Excel预测数据源+版本控制记录。

Q1223：如果平台想同时申请MiCA牌照和EMI牌照是否可行？

答：完全可行，甚至是监管推荐结构之一：

  • MiCA管辖加密资产服务，EMI牌照可用于法币出入金与账户服务；

  • 可由同一法团下两个业务部门操作，或设立母子公司结构；

  • 应提交《多牌照职能分隔计划》确保合规责任分明。

推荐结构：MiCA由控股公司持有，EMI牌照由子公司或并行法人运营。

Q1224：平台能否将系统托管在Amazon AWS / Google Cloud等海外服务商？

答：可以，但需满足数据可追溯性、审计能力、跨境数据合规要求：

  • 云服务提供商应在欧盟设有数据中心或支持“本地托管”选项；

  • 必须提交《外包服务风险评估报告》与《审计接入协议》；

  • 平台需保证即使第三方中断，也能维持核心功能不瘫痪。

推荐选择AWS Frankfurt、Google Cloud EU Region或Azure欧洲区，并启用合规监控组件。

Q1225：MiCA是否强制要求平台接入欧盟金融消费者投诉机制？

答：是的，平台必须设立投诉处理机制，并允许客户升级至主管机关调解：

  • 应设立《投诉接收与处理政策》并公告于官网；

  • 每起投诉需记录处理过程与反馈时间；

  • 须报告投诉统计至国家主管机关；

  • 客户可向BoL或ESMA申诉。

推荐设立“投诉处理专责人员（Complaints Officer）”，并由RO定期复核流程。

Q1226：MiCA下NFT市场是否受监管？

答：视NFT是否具备“可转让性”与“投资特征”而定：

  • 单一、非分割、无收益承诺的艺术型NFT通常不受MiCA约束；

  • 若NFT被用作资产证券化、集体投资入口，可能被视为ART或Security Token；

  • 平台如涉NFT交易，建议设立“商品型 vs 金融型NFT识别政策”。

所有涉及NFT交易的服务建议附带“非证券声明”与用户风险提示条款。

Q1227：平台技术人员是否也要进行尽职调查？

答：若该人员为系统管理员、加密密钥持有人、冷钱包签署人，则必须进行KYC/KYE（Know Your Employee）流程：

  • 包括无犯罪记录、过往雇佣背景、访问权限等级说明；

  • 系统应建立“敏感权限矩阵”，并配合定期审计；

  • 重要技术人员更替，需向监管机关备案。

建议使用《技术合规人员背景调查表》，配套《系统权限审计记录表》。

Q1228：MiCA是否要求平台有灾备系统和紧急计划？

答：是的，所有平台必须具备完整业务连续性与灾难恢复计划（BCP/DRP）：

  • 包括数据备份机制、冷备与热备切换流程；

  • 明确紧急联系人与恢复时间目标（RTO）/恢复点目标（RPO）；

  • 每年至少进行一次演练并提交测试报告。

平台应提供《业务连续性计划》和《应急演练报告摘要》予BoL存档。

Q1229：平台是否可以发行自有稳定币？

答：如稳定币具“资产参考”或“电子货币”特征（即ART/EMT），则须另行申请发行人牌照（MiCA Title III或IV）：

  • 不得在无牌状态下公开发行与流通；

  • 自有稳定币若仅限平台内部使用，仍需设限额与KYC绑定机制；

  • 须提交《稳定币设计说明》、《资产备抵机制报告》、《波动性风险模型》。

建议将发行、交易、托管功能切分为不同实体，降低监管复杂度。

Q1230：MiCA是否允许平台发Token融资（ICO/ITO）？

答：允许，但平台必须依法完成白皮书注册与客户保护机制：

  • 白皮书须通过BoL备案；

  • 须说明募资用途、项目风险、法律责任、退出路径；

  • 募资不得向非专业客户进行广泛推广，除非符合投资者适当性评估。

建议配套《Token发行项目内部审查政策》、《投资者认购适当性问卷》。

Q1231：MiCA对发行Token的项目方是否要求拥有实体办公室？

答：是的。若项目方计划公开发行资产参考代币（ART）或电子货币代币（EMT），必须：

  • 在欧盟设有法定注册办公地址；

  • 办公室须为真实运营场所，接受监管访查；

  • 提供租赁协议、电费或网络账单作为佐证文件。

若为远程办公结构，建议设立虚拟办公室仅作为通讯地址是不足够的。

Q1232：在MiCA监管下，平台是否必须对冷钱包进行物理隔离？

答：MiCA并未强制冷钱包物理隔离，但要求实现最高级别的安全控制，建议包括：

  • 冷钱包私钥离线存储且由2人以上多签控制；

  • 定期演练冷钱包提币流程并记录审批路径；

  • 禁止通过互联网连接自动化操作冷钱包。

最佳实践为：FIPS 140-2 Level 3硬件安全模块 + 多重签名（如Shamir Secret Sharing）。

Q1233：MiCA是否允许使用Open Source的核心交易引擎？

答：允许使用开源架构，但应注意以下风险和监管重点：

  • 需评估其安全性、维护频率、漏洞响应机制；

  • 应有内部代码审计与更新记录机制；

  • 所有开源组件应列入《第三方代码清单》并附合规声明。

推荐平台保留完整的代码修改日志与测试记录（Git log / GitLab流水线等）。

Q1234：平台是否可以授权其他企业或白标合作伙伴使用其MiCA牌照？

答：不可以。MiCA明确禁止牌照转租、白标运营、变相外包核心功能：

  • 合作伙伴若需提供受规服务，须单独持牌或受控股结构约束；

  • 可通过合规子品牌模式实现协作，但平台必须全面控权、监控并报告；

否则可能构成“影子平台”经营，属重大违规风险。

Q1235：MiCA是否允许多币种钱包？是否有限制？

答：允许支持多币种（Crypto Assets），但平台必须披露所有支持币种的合规性质分类：

  • 对于每种币种，须列明其归属MiCA分类（ART、EMT、Utility Token、Security Token）；

  • 对于非主流币种，须提交风险评估报告与披露通知；

  • 不可交易被明令禁止或高风险未注册币种。

建议建立《支持币种合规清单》和《币种上线审批机制》。

Q1236：MiCA是否允许平台在欧盟以外运营用户接口？

答：可以，但前提是：

  • 接口不能面向欧盟零售客户（除非该平台已获MiCA授权）；

  • 如面向欧盟客户，必须由持MiCA牌照实体全权控制该接口（含代码部署、用户数据、KYC）；

  • 界面、语言与客服内容若明显面向欧盟，即使技术托管海外亦属MiCA监管范畴。

实操建议为采用“区域识别+IP过滤+KYC国籍验证”组合。

Q1237：MiCA是否接受Token挂钩实物资产（如黄金、房地产）？

答：接受，但此类Token一般被归类为资产参考代币（ART），需要：

  • 提交详尽的资产托管、估值、披露和赎回机制；

  • 对实物资产的流动性、变现机制做出解释；

  • 必须具备审计证明（如第三方黄金储备审计报告）。

例如黄金挂钩的Token，需披露保管仓库、每日克重对账数据、保险证明。

Q1238：MiCA是否规定客户的资产可否用于平台对外借贷？

答：MiCA明确禁止未经客户明示同意的资产再使用（Rehypothecation）：

  • 如要借出客户资产，须获得“逐笔授权”；

  • 须披露再使用条款、潜在风险与交易对手信息；

  • 所得收益应合理分配给客户，并记录操作细节。

平台应设置《资产再使用风险声明》与《客户再授权记录制度》。

Q1239：MiCA是否允许通过DAO或社区治理结构运营？

答：允许DAO存在作为技术架构或辅助决策机制，但核心运营责任必须落到法人实体：

  • DAO不能代替牌照持有人履行监管义务；

  • 所有治理决议需有法定公司董事会备案确认；

  • 关键合规职能（如RO、MLRO）不可匿名或由DAO控制。

推荐建立《DAO决策记录备份与公司内审机制》。

Q1240：平台是否必须为每笔客户交易生成审计记录？

答：是的，MiCA要求平台具备“逐笔交易记录+可回溯机制”，包括但不限于：

  • 交易发起时间、交易ID、撮合匹配路径；

  • 交易双方KYC编号、IP地址、资产出入路径；

  • 系统内存储的加密指令或交易签名摘要。

审计数据保存期限≥5年，建议每日生成《交易审计汇总日志》，并定期加密归档。

Q1241：MiCA是否要求平台对所有上线的虚拟资产进行尽职调查（Due Diligence）？

答：是的，MiCA要求所有支持交易或托管的加密资产必须经过内部合规尽职调查流程。包括但不限于：

  • 项目方KYC与UBO信息；

  • 代币白皮书/技术文档；

  • 合约代码审计报告（如Solidity审计）；

  • 是否涉嫌证券化/资金募集；

  • 项目所在国法律合规状态。

建议平台建立《Token Listing评估机制》，包括“技术、法律、风险”三维度审批制度。

Q1242：MiCA监管是否适用于NFT平台？

答：MiCA对不具有可替代性（Non-Fungible）的NFT不作直接监管，但若NFT具备下列特征，将纳入监管：

  • 批量发行、可交易、可分割或具投资性；

  • 结构上与金融工具相似（如NFT抵押借贷）；

  • 或通过智能合约引发资产收益权或治理权。

实操建议：若涉及多件NFT、市场功能或代币化股权，应咨询法律意见确认是否构成“金融类NFT”。

Q1243：MiCA是否对算法稳定币设限？

答：MiCA禁止无资产支持的纯算法稳定币（如UST），并对混合结构稳定币提出严格要求：

  • 必须至少80%的储备为流动、低风险的实物资产（如政府债、现金）；

  • 算法机制不得在无抵押前提下扩张发行；

  • 禁止使用加密资产本身作为主要抵押来源（如BTC挂钩DAI结构不可行）。

所有储备比例和算法原理应披露并经监管认可。

Q1244：MiCA合规团队需具备哪些背景？是否强制欧盟本地人员？

答：MiCA未强制合规团队必须为欧盟居民，但有明确能力与监管沟通要求：

  • 至少一位具欧盟工作经验的RO（责任人）；

  • MLRO应具备反洗钱法规知识、审查经验；

  • 建议合规总监拥有法律或金融背景，熟悉欧盟监管语言（英语或立陶宛语）；

  • 推荐聘请本地顾问配合与监管沟通。

Q1245：MiCA是否要求合规文档使用特定语言提交？

答：MiCA规定正式提交文件应使用欧盟语言，并由各成员国主管机关确认语言要求。对于立陶宛：

  • 官方提交文件须为立陶宛语；

  • 可附英文版本辅助说明，但不得取代官方文件；

  • 合同、制度、章程等内部文档也建议准备双语版本。

建议使用专业翻译机构进行文件认证或附公证件。

Q1246：MiCA是否强制平台使用银行托管客户资金？

答：是的。客户法币必须存放于欧盟授权的银行或支付机构账户：

  • 不得混同于平台自有运营账户；

  • 需实现每日对账与余额回溯；

  • 客户资金变动须有系统记录与银行对账单匹配机制。

若使用EMI或PI结构托管，需提供合规证明与反洗钱制度协同机制。

Q1247：MiCA对平台客服系统是否有最低要求？

答：MiCA强调“投资者保护”，客服系统必须：

  • 支持客户查询历史交易与申诉；

  • 提供处理进度追踪；

  • 客户投诉响应期限不得超过15个工作日；

  • 保留客户互动记录≥5年。

建议部署Ticket系统 + AI初筛 + 人工升级三层结构。

Q1248：MiCA对用户留存数据如何规定？是否适用GDPR？

答：MiCA下所有CASP平台同时适用《通用数据保护条例》（GDPR）：

  • 所有用户数据收集需获得明确授权（Consent）；

  • 用户有权请求数据删除、更正或转移；

  • 系统必须支持数据访问日志、权限审查、加密备份；

  • 数据保留最短5年，但最多不得超过法律规定用途存储期限。

强烈建议平台设有DPO（数据保护官），并完成GDPR注册与评估。

Q1249：MiCA是否允许平台开展杠杆交易或衍生品业务？

答：MiCA本身并不覆盖加密衍生品（如期货、期权），该业务属于欧盟其他法规（如MiFID II、EMIR）范畴：

  • 若提供杠杆或合约交易，平台需获得额外金融服务牌照；

  • 杠杆产品必须标示风险、不得向零售用户默认开启；

  • 须设定杠杆上限、风险预警机制。

如结合MiCA + MiFID结构操作，建议分实体管理并明确风控边界。

Q1250：MiCA申请能否使用境外公司控股结构？

答：可以，但平台实际运营实体（申请人）必须为欧盟注册法人，境外母公司可通过如下结构控股：

  • 直接持股：如母公司注册于新加坡或香港；

  • 设立中间控股公司（如立陶宛/爱沙尼亚子公司）；

  • 提供《最终受益人声明（UBO）》《穿透控股结构图》《资金来源报告》；

  • 控股路径须明确、合法且无匿名股东。

推荐使用欧盟本地实体作为牌照持有公司，境外公司可作为集团控股方并提供声明。

Q1251：MiCA是否规定了服务中断后的应急响应机制？

答：是的。MiCA要求平台必须具备明确的应急预案和灾难恢复计划（BCP/DRP），包括：

  • 核心系统中断后的替代处理机制（如人工撮合、暂停服务告知）；

  • 系统备份频率（建议每日+异地备份）；

  • 最长恢复时间目标（RTO）与数据恢复点目标（RPO）；

  • 必须每年至少一次模拟演练，并保留演练记录。

建议制定《MiCA灾难恢复政策（含流程图）》并向监管机构备案。

Q1252：MiCA是否限制平台通过DeFi协议进行资金管理？

答：MiCA不禁止DeFi技术使用，但明确要求：

  • 客户资金或储备资产不得直接注入未经许可的DeFi协议；

  • 若将部分平台资产投入流动性池或借贷池，必须具备透明可审计流程；

  • 须向用户披露相关操作逻辑、风险提示，并获得授权。

实操建议：所有资金流动路径必须记录并可生成审计链条。

Q1253：MiCA对空投（Airdrop）是否有监管要求？

答：若空投行为具备以下特征之一，MiCA将其视为发行活动（Offering），需进行监管备案：

  • 具备投资回报预期（例如质押可得收益）；

  • 与金融性Token直接绑定（例如持Token可投票并分红）；

  • 空投后可在受监管平台上市交易。

建议所有空投行为预先提交合规意见书，避免被视为非法募资或未备案发行。

Q1254：MiCA是否允许平台进行跨国收购或兼并？是否需报备？

答：允许。但以下情形需提前获得主管机关批准：

  • 股东结构发生变化，导致最终受益人控制权转移；

  • 平台整体被兼并入另一家CASP或金融集团；

  • 境外公司成为控制方或战略投资者；

  • 新法人将取代现持牌实体继续营运。

须提前30日向监管机构申报并附尽调材料。

Q1255：MiCA是否要求平台开设合规培训计划？

答：是的。所有CASP平台需建立年度员工合规培训机制，包括：

  • AML/CFT防洗钱与恐怖融资；

  • MiCA相关法规讲解；

  • 客户投诉处理流程；

  • 信息系统安全操作与权限使用；

建议准备《员工年度培训记录模板》《合规签到表》《测验问卷样本》以供备查。

Q1256：MiCA是否要求平台公布收费结构？

答：是的，MiCA要求所有费用公开透明，包括：

  • 交易手续费、充值/提现费用；

  • 托管服务费用；

  • 非活跃账户管理费用；

  • 额外服务费用（如API接入、法币结算服务等）。

用户协议中应明确“费用标准+计算方式+修改机制”。

Q1257：MiCA是否禁止平台与非欧盟国家客户开展业务？

答：不禁止，但平台需评估是否符合法域国监管：

  • 若非欧盟国家禁止该服务类型，平台应设限；

  • 须对非欧盟客户进行强化KYC审核；

  • 必须提供客户适当性评估并取得授权。

推荐建立“境外客户接入合规审查机制”及客户国别黑名单列表。

Q1258：MiCA是否对平台使用托管钱包或多签钱包有要求？

答：有明确要求，尤其针对客户资产保管安全：

  • 必须采用分层权限钱包架构（如冷热钱包分离）；

  • 建议采用2-of-3多签架构（平台+合规官+第三方审计）；

  • 所有私钥操作需保留日志并录入系统审计模块；

  • 交易需设定每日额度、风控审批层级。

推荐使用《冷钱包签名授权流程图》作为系统审核支撑文件。

Q1259：MiCA平台是否可以开展贷款/借贷业务？

答：MiCA本身不许可CASP平台从事贷款/借贷业务，如需开展该类业务需：

  • 申请另一个金融机构牌照（如信贷牌照、电子货币牌照等）；

  • 与第三方有执照贷款平台合作，并确保客户保护机制；

  • 所有利率、质押规则必须事前披露并经用户确认。

建议平台避免将MiCA与借贷服务混同，防止越权经营。

Q1260：MiCA是否规定了平台终止营运时的清算流程？

答：MiCA要求CASP在终止业务前至少提前60天公告并提交以下内容：

  • 《终止业务计划书》；

  • 客户资产返还机制与时间表；

  • 客户通知程序与资金划拨渠道；

  • 数据备份计划与数据访问过渡期安排；

  • 报送监管机构的结业审查报告。

推荐设置“退出机制说明页”并提交《自主清盘说明书》。

Q1261：MiCA对平台IT系统的版本更新是否有限制？是否需要报备？

答：MiCA对平台核心系统更新实行“重大变更须报备”制度，具体包括：

  • 核心撮合引擎、冷钱包系统、安全防火墙、数据库结构等更新；

  • 引入新模块（如：OTC交易模块、自动借贷模块）；

  • 新增智能合约或接入链上节点服务；

  • 新服务引发客户界面重大变更（UI/UX大改）等。

建议提前7-14个工作日前提交《系统变更说明报告》，附测试结果与风险评估表。

Q1262：MiCA是否要求平台保留日志？日志保存多久？

答：是的，MiCA要求平台保留以下日志并可供监管机构抽查：

  • 所有客户交易记录日志（≥5年）；

  • 系统登录、权限更动、冷钱包签名等操作日志（≥5年）；

  • 合规审批流程与黑名单触发记录（≥5年）；

  • 任何STR（可疑交易报告）日志与KYC流程调用记录。

强烈建议平台接入“审计级别日志系统”，并定期外包稽核审查。

Q1263：MiCA是否允许平台支持NFT交易？

答：MiCA对NFT类资产定义为“非可替代性代币”，若满足以下任一条件，平台支持NFT交易需申请额外授权：

  • NFT被结构化为金融产品（如NFT证券、可转让收益权）；

  • NFT用于投资回报（如质押、分红）；

  • NFT具有批量发行+标准化合同的“类证券”属性。

若仅为艺术类、游戏类单一NFT，可不纳入MiCA；建议编制《NFT交易合规分类备查表》。

Q1264：MiCA是否要求定期更新商业计划书？

答：MiCA不强制年度更新商业计划书，但平台在出现以下情形时必须补交最新版本：

  • 增加新服务类型（如跨境兑换）；

  • 营运范围扩大至多个欧盟成员国；

  • 获得重大投资或更换控股股东；

  • 被监管机构列为重点抽检对象。

实务建议：每年仍应维护《年度营运总结报告》作为备查材料。

Q1265：平台如何证明其客户资产与自有资产隔离？

答：需采用如下手段合规证明：

  • 使用独立客户资产银行账户，命名为“Client Asset A/C”；

  • 钱包层面使用独立路径、独立私钥；

  • 系统后台建立分账模块，分清客户资金池与营运资金池；

  • 每季度编制《客户资产与公司资产分离说明函》。

审计机构每年将核实隔离情况并签发《资产隔离核证函》。

Q1266：MiCA是否要求平台具备反欺诈系统？

答：是的，MiCA强烈建议平台建立智能监控与反欺诈系统，应包括以下模块：

  • 异常交易监控（如频繁小额转账、高频撤单）；

  • 设备指纹识别（如同一IP/设备操作多个账户）；

  • 跨境行为审查（如高风险国家IP登录）；

  • 高频API调用行为分析。

可委托合规科技服务商构建或采用“交易行为评分模型”。

Q1267：MiCA是否允许平台为客户提供交易建议？

答：不允许。MiCA下的CASP平台如提供投资建议或分析服务，将触发MiFID II等指令监管，需申请证券类牌照。

平台可提供如下信息但须明确声明“非投资建议”：

  • Token基本信息披露；

  • 历史价格趋势；

  • 官方白皮书摘要。

建议添加免责声明：“本信息不构成投资建议，亦不应被视为任何形式的财务顾问意见。”

Q1268：MiCA是否要求年度监管报告？内容包括哪些？

答：是的，MiCA要求CASP平台每年向监管机构提交年度监管报告，内容包括：

  • 客户资产托管状况；

  • 反洗钱与客户适当性审核摘要；

  • 平台营运数据与交易量；

  • 投诉数量、处理机制总结；

  • 年度信息系统安全报告（含入侵检测、数据备份情况）。

建议提前准备《年度报告合规填报模板》和监管递交清单。

Q1269：MiCA是否允许客户匿名交易？

答：完全禁止。MiCA要求客户必须完成完整KYC/身份验证流程，平台必须记录以下信息：

  • 身份证明文件（护照/身份证）；

  • 实体客户的UBO、公司结构、业务性质说明；

  • 实名银行账户用于出入金；

  • 疑似关联账户交易行为应设拦截机制。

系统应设置防止“钱包地址间绕过出金”的风控模块。

Q1270：MiCA是否规定合规官（Compliance Officer）必须驻立陶宛？

答：是的，作为CASP注册国的监管要求之一，合规负责人（MLRO/CO）必须实际居住在立陶宛或在立陶宛设有办公场所，能够随时配合监管抽查与日常合规运营。

实务建议：可设立合规服务子公司或与本地专业服务机构签署驻地合规代表服务合同。

Q1271：MiCA 牌照下客户资金托管是否必须由银行完成？

答：不一定必须是银行，但必须是被授权的“合格托管机构（Qualified Custodian）”，包括：

  • 欧盟持牌银行（EU Credit Institutions）；

  • 欧盟监管下的电子货币机构（EMI）；

  • 经MiFID/MiCA承认的第三方资产托管商；

  • 特殊经批准的CASP机构，具有独立托管权限。

平台自托管客户资金需提交《内部托管系统说明书》并接受独立审计。

Q1272：MiCA 是否限制交易对数量或交易币种数量？

答：MiCA 本身不限制交易币种数量，但要求平台为每个上线币种准备：

  • 风险评级文件（Token Risk Assessment）；

  • 白皮书摘要与验证；

  • 客户适当性匹配说明（是否高风险、高波动）；

  • 上市委员会审核流程存档。

上币前建议通过《Token Listing 审查机制》，记录流程及合规意见。

Q1273：MiCA 是否允许将客户交易数据共享给第三方（如：广告公司）？

答：不允许。MiCA 遵循 GDPR（通用数据保护条例），未经客户明确授权或监管豁免，不得将客户数据用于以下用途：

  • 商业营销或定向广告；

  • 出售给数据中介；

  • 与技术合作伙伴共享非匿名化交易行为数据。

所有客户数据应加密保存，并可提供数据访问日志审查。

Q1274：MiCA 规定平台如何处理“客户死亡或丧失行为能力”？

答：平台需事先制定“账户继承及受托机制”，建议包括：

  • 设置法定继承申请机制（提供法院判决书/公证书）；

  • 提供多重签名+授权人机制（如委托钱包控制权）；

  • 暂停账户并通知监管机构记录为“待处理账户”；

  • 保存完整操作与冻结记录。

实务建议：上线“数字遗嘱服务”模块可作为平台差异化优势。

Q1275：MiCA 是否允许平台经营杠杆交易、借贷或期货？

答：MiCA 本身不直接授权杠杆、衍生品、DeFi 借贷等活动，若涉及此类业务，应：

  • 另行申请 MiFID II 金融工具牌照；

  • 或转为注册为“Multilateral Trading Facility (MTF)”；

  • 涉及DeFi产品，监管目前以“审慎原则”评估。

建议独立设立交易类子平台，并在风险披露中明确杠杆机制。

Q1276：MiCA 是否允许用户使用第三方钱包登录平台？

答：技术上允许，但平台应确保：

  • 客户仍完成实名KYC（与钱包绑定）；

  • 平台后台有风控监测第三方钱包活动轨迹；

  • 加强对MetaMask、Ledger、Trezor等设备兼容性测试；

  • 若为Web3接入，应限制客户绕过AML模块。

最佳做法是“第三方钱包登录+平台托管账户绑定”双轨制。

Q1277：MiCA 是否对平台员工有专业认证要求？

答：合规与客户管理岗位员工建议完成以下认证培训：

  • AML/KYC专业培训（如ACAMS）；

  • 虚拟资产监管课程（如：Cambridge、FATF模块）；

  • 每年至少完成8小时以上的合规持续教育；

  • 所有负责人员应记录履职日志与专业履历。

企业应保留员工培训档案 ≥5年，以备审查。

Q1278：MiCA 是否适用于 DAO（去中心化自治组织）结构？

答：MiCA 尚未完全覆盖 DAO 模型，但若 DAO 实质开展以下行为，则可能触发合规义务：

  • 公开招募投资者资金；

  • 提供交易撮合或资产保管服务；

  • 发行具有收益性质的 Token；

  • 提供面向欧盟客户的金融类产品。

强烈建议 DAO 设立法律代表实体（如：立陶宛UAB）持牌运营。

Q1279：MiCA 是否允许平台引入多语言界面？有何义务？

答：允许，但平台必须确保所有关键内容翻译准确，并符合以下标准：

  • 白皮书必须提供英文版本；

  • 风险披露内容翻译需经法务审阅；

  • 客户协议、AML政策、隐私政策多语版本需保持一致性；

  • 若发生争议，监管默认以英文原版为准。

建议引入“合规翻译供应商”进行审查或认证译本。

Q1280：MiCA 是否规定冷钱包必须100%离线？

答：MiCA 并未明文强制100%离线冷存储，但在审查安全性时，会重点考核：

  • 是否为多签+离线签名机制；

  • 签名操作是否隔离于主网访问；

  • 是否具备非网络连接环境操作流程（如：离线签名服务器）；

  • 是否每日出入账均需由两名授权人员分层审批。

平台若采用“热/冷钱包混合机制”，必须建立《冷钱包资产调拨机制备查表》。

Q1281：MiCA 对于客户适当性测试是否必须强制进行？

答：是的，MiCA 要求在销售某些类型虚拟资产（尤其是复杂产品或无资产支持的 Token）前进行客户适当性评估。包括：

  • 客户是否理解虚拟资产性质；

  • 客户风险承受能力；

  • 客户过往投资经验；

  • 是否涉及老年、低收入或非金融背景人群。

建议设置“适当性问卷+风险打分系统”，系统自动标记不适合客户，防止违规销售。

Q1282：MiCA 是否允许平台提供返佣、邀请返利或营销激励？

答：MiCA 并不明文禁止返佣机制，但必须遵循以下限制：

  • 不得误导性宣传（如保本、保收益）；

  • 所有返佣信息应在注册前明示并提供风险说明；

  • 禁止涉及“拉人头”多层次结构；

  • 营销活动不得影响客户独立投资判断。

建议设立《营销合规政策》，并定期向监管申报相关活动备案。

Q1283：MiCA 是否允许平台使用AI进行客户风险评估？

答：允许使用 AI / 算法模型进行评估，但应满足以下要求：

  • 模型算法透明，可供审计；

  • 不得基于敏感数据歧视（如国籍、宗教、种族等）；

  • 应有人工复核机制；

  • 必须保留算法决策日志，供未来合规抽查。

推荐附加《算法透明性政策》与AI风险评估说明。

Q1284：MiCA 是否允许平台自行设定收费结构（例如：按交易额百分比收费）？

答：允许。MiCA 没有统一收费标准，但需满足以下义务：

  • 收费明细应于平台主页清晰展示；

  • 收费模式应公平、非歧视；

  • 应对特殊费用（如提现费、Gas费）进行单独说明；

  • 应定期披露费用调整通知，不得临时更改。

建议制作《收费结构与披露政策》以规避争议。

Q1285：MiCA 如何界定“虚拟资产服务”与“技术服务”？是否存在监管灰区？

答：监管关键在于是否“直接接触客户资金/资产”或“中介买卖”。例如：

  • 仅提供钱包API的技术服务公司，可能不视为CASP；

  • 若参与撮合订单、托管资产，则属于MiCA监管范畴；

  • 灰区行为（如：提供“指令转发服务”）可能被视为实质交易商。

建议由合规顾问撰写《业务边界认定意见书》提交监管备案。

Q1286：MiCA 是否规定 Token 必须可验证源代码？

答：MiCA 鼓励透明性，但未强制公开源代码。对于某些高风险或创新型 Token，监管建议：

  • 提供可验证的智能合约地址；

  • 提供代码审计报告（如：CertiK、SlowMist等）；

  • 白皮书中说明代码版本控制机制；

  • 若为可升级合约，需说明管理权限机制。

建议设立《代码审计报告登记机制》，提高信任度。

Q1287：MiCA 是否允许平台提供“托管+基金管理”一体化服务？

答：允许，但必须分别满足两个许可要求：

  • 托管服务需合规冷/热钱包体系、资产隔离机制；

  • 基金管理需具备投资顾问资质、设立投资策略披露机制；

  • 且必须避免利益冲突，如平台推荐自营基金等。

应设立《利益冲突管理政策》并接受独立审计。

Q1288：MiCA 如何监管“稳定币抵押借贷平台”？

答：若平台提供以稳定币作为抵押物进行借贷活动，须注意以下几点：

  • 抵押比例、清算机制应明示；

  • 借贷合约需具备清晰违约处理规则；

  • 平台需承担一定“贷款人”责任，接受MiCA框架内资金池管理要求；

  • 若向公众募集借贷资金，需额外注册为信贷服务平台。

建议同步建立《借贷风险说明书》和《资产池透明度报告》。

Q1289：MiCA 是否允许向美国/亚洲客户开放平台服务？

答：MiCA 许可本身仅适用于欧盟境内运营，但若非欧盟客户可自由注册/交易，需确保符合以下条件：

  • 不违反当地金融法规（如美国SEC规则）；

  • 客户明确知悉其所在司法区无监管保障；

  • 强烈建议限制部分敏感地区访问（如：通过IP屏蔽）；

  • 对外国客户设立独立KYC及交易风控模块。

若业务重度依赖海外客户，应考虑设立本地合规实体。

Q1290：MiCA 如何监管平台的应急响应能力？

答：平台需制定《业务持续性计划（BCP）》及《应急响应手册》，包括：

  • 关键系统（钱包、撮合、风控）停运应对机制；

  • 客户资产即时快照机制；

  • 冷钱包恢复流程；

  • 与第三方托管商的接口恢复SLA；

  • 每年进行灾备演练并记录完整流程。

应设置专职BCP负责人，并定期更新应急方案。

Q1291：MiCA 是否允许平台托管客户 NFT（非同质化代币）？

答：MiCA 对 NFT 本身不适用直接监管，但若平台提供以下服务，仍可能被纳入 CASP 范畴：

  • NFT 买卖撮合（视同交易所）；

  • 为 NFT 提供钱包托管服务（如代管私钥）；

  • NFT 质押借贷或集合销售。

若 NFT 有证券化特征（如分享收入、分红），则可能被视为“可转让证券类加密资产”，须额外获得证券服务许可。

Q1292：MiCA 是否适用于 DAO（去中心化自治组织）？

答：MiCA 本身不直接适用 DAO，但监管机构强调：

  • 若 DAO 实际控制平台系统、托管权限或代币发行，即使无注册法人，仍需履行 MiCA 义务；

  • DAO 可授权实体代表向监管注册为 CASP；

  • DAO 没有法律责任承担主体时，平台/开发团队将被视为责任人。

推荐设立实体法人作为 DAO 前台代表，以确保合规履职。

Q1293：MiCA 是否支持使用代币分红或利润返还给用户？

答：若代币设置“按期分红”或“与公司利润挂钩”的机制，则可能被视为证券型代币（Security Token），需满足更高监管要求，如：

  • 白皮书需披露盈利模型；

  • 注册时附加金融工具监管披露义务；

  • 需申请 MiFID 相关授权许可。

建议结构设计中避免明确收益绑定条款，或采用积分类方案取代代币分红。

Q1294：平台是否可以提供 OTC 场外大宗交易服务？

答：可以，但必须履行以下监管要求：

  • OTC 客户需进行增强版尽职调查（EDD）；

  • 每笔交易应记录价格、公允性、撮合对象；

  • 不得绕开平台自动撮合系统从事“规避申报”的操作；

  • OTC交易额纳入平台整体 AML 报告体系。

建议设立《OTC服务政策》并单独审计合规性。

Q1295：MiCA 监管是否覆盖算法稳定币（如 Terra Luna 类型）？

答：是的。MiCA 规定所有“无资产支持”的算法稳定币必须：

  • 提交算法结构公开说明；

  • 接受监管审计、应急测试；

  • 需配套有偿还机制，防止“脱锚”风险；

  • 禁止向大众营销或广泛流通，监管强度等同电子货币。

建议回避此类结构，或仅向专业投资者封闭提供。

Q1296：MiCA 是否要求白皮书必须有监管审批？

答：视虚拟资产类型而定：

  • ART（资产参考型代币）与 EMT（电子货币代币）：需提交白皮书并由监管批准；

  • 普通代币：可在提交白皮书后自动生效（无须预先批准），但仍需确保信息真实、全面；

  • 白皮书需提供多语种版本（英文+注册地语言）。

建议提前进行法律审查，确保内容不触发证券型代币认定。

Q1297：MiCA 对“Token销毁机制”有何规定？

答：销毁机制可视为影响代币稀缺性的重要结构，需披露以下内容：

  • 触发条件（如收入分成、费用销毁）；

  • 销毁方式（如：链上不可逆转地址）；

  • 销毁数量及频率；

  • 影响 Token 供应和价格的预估分析。

若销毁机制涉及“回购”，应特别说明其与证券型交易之间的界限。

Q1298：平台能否将用户数据在欧盟外处理？（如设服务器在新加坡）

答：可以，但必须遵守 GDPR 和 MiCA 数据本地化原则，特别是：

  • 使用非欧盟数据中心时，需具备标准合同条款（SCC）；

  • 数据需加密传输、访问控制审计；

  • 客户需明确知悉其数据将传输至何处；

  • 出现数据泄露时需48小时内通知监管。

建议优先选择 GDPR Adequacy List 列表国家托管客户数据。

Q1299：是否可以由外包技术团队负责平台日常运维？

答：可以，但前提是：

  • 签订明确的 SLA（服务水平协议）；

  • 外包商需接受平台 AML/KYC 安全控制政策；

  • 所有客户数据访问需进行审计跟踪；

  • 重大系统更新必须经平台董事会或合规部门批准。

强烈建议保留核心权限（如钱包密钥管理、撮合引擎控制）在平台本地人员手中。

Q1300：MiCA 实施后是否自动替代现有立陶宛VASP许可？

答：否。MiCA 并不会“自动替代”现有许可，需进行重新注册或“过渡审查”。立陶宛FNTT监管机构将设有过渡期机制，企业须提交以下材料以获得MiCA合规延续许可：

  • 旧VASP授权文件；

  • 符合MiCA要求的系统调整说明；

  • 指定合规负责人；

  • 注册新业务类型对应的许可类别。

建议提前6个月启动MiCA重授权申请，避免业务中断。

香港证监会SFC牌照 | 加拿大MSB牌 | 香港合规牌照 | 美国合规牌照 | 香港黄金交易所 | 仁港永胜（深圳）法律服务有限公司
八、结语：FAQ是一种合规导航器

MiCA申请的核心，不是简单填表，而是理解法规逻辑、运营实质、监管心理的过程。本章节FAQ旨在为申请人解疑释惑、排雷提效、做好准备。

建议将FAQ整理成公司内部“问答手册”，以便团队同步理解申请条件、合规义务、流程要点。

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

第十一篇章：MiCA申请材料模板包说明与下载建议

（Business Plan + AML Policy + 冷钱包图 等核心文档）
立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇为MiCA申请实操篇，由仁港永胜唐生撰写讲解，围绕立陶宛及欧盟监管机构在申请阶段强制要求提交的核心文档进行逐一模板化解析，并说明建议格式、结构、使用方式及注意事项。适用于希望快速搭建申请材料初稿的项目方、顾问、申请人等。

一、模板材料包的核心构成（官方推荐）

MiCA申请应提交的材料可分为六大类模板文档，分别为：

类别 模板文件 是否强制提交
商业类 《Business Plan商业计划书模板》 ✅ 强制
合规类 《AML/KYC政策手册模板》、《MLRO任命函模板》 ✅ 强制
结构类 《组织结构图》、《控股结构图》、《UBO申报模板》 ✅ 强制
系统类 《IT系统说明书》、《冷钱包权限控制图》 ✅ 强制
操作类 《客户投诉处理机制》、《交易流程图》、《STR处理流程图》 ✅ 推荐
法律类 《法律意见函模板》、《服务条款 & 用户协议（英文）》 ⚠️ 可选（部分类型强制）

二、模板1：《商业计划书 Business Plan》模板说明

用途：

作为MiCA最核心文件之一，须清晰展现贵公司业务逻辑、服务范围、客户来源、营收模式及监管适用性。

建议结构如下：

  1. 公司简介（含注册信息、组织架构、主要负责人介绍）

  2. 服务描述（说明拟申请的MiCA服务类型及业务场景）

  3. 市场分析（客户定位、竞争格局、核心优势）

  4. 营收模型（服务收费模式、交易收入、咨询或分销结构）

  5. 风险管理（操作风险、客户资金风险、网络风险说明）

  6. 监管匹配声明（MiCA条文适用解读、自愿受监管陈述）

  7. 三年财务预测表（收入、支出、盈亏、现金流）

  8. 合规承诺声明

附件：组织结构图、股东图、团队成员履历摘要

三、模板2：《AML/KYC政策手册》模板说明

用途：

明确展示企业如何执行反洗钱与客户识别政策，以符合MiCA与AMLD6的监管要求。

建议内容章节：

  1. 政策声明与适用范围

  2. 客户识别标准（KYC等级）

  3. 业务关系建立前的尽调流程（CDD/EDD）

  4. 可疑交易识别标准与流程

  5. STR报告机制（内部流转+外部上报）

  6. 员工培训制度（频率+内容）

  7. 黑名单管理与信息共享机制

  8. 数据保留机制（不少于5年）

附件：KYC表格模板、黑名单筛查工具示例、MLRO汇报线说明

四、模板3：《IT系统说明书 + 冷钱包权限流程图》模板说明

用途：

向监管说明系统运作机制、客户数据安全架构、权限设置及私钥控制流程。

IT系统说明书应包括：

  • 系统架构总览图（客户端、后台管理端、交易逻辑）

  • 钱包管理策略说明（冷热钱包分离、签名流程）

  • 权限控制说明（分角色权限配置表）

  • 日志审计系统（可追溯性、操作历史记录）

  • 数据存储说明（服务器位置、加密方式、备份策略）

冷钱包权限图建议示意：

graph TD
Admin[系统管理员] -->|设定签名规则| Wallet[冷钱包]
Operator[操作员] -->|日常发起交易| Wallet
Compliance[合规负责人] -->|审核+授权| Wallet

Audit[审计只读权限] -->|访问日志| Walle


附件：钱包签名逻辑流程图、授权审批文档模板、恢复机制文档

五、模板4：《STR流程图 + 客户投诉处理机制》说明

STR报告流程图：

应展示系统识别可疑交易 → MLRO人工审核 → 上报BoL或FIU的全链路流程。

投诉处理机制模板结构：

  1. 客户申诉入口说明

  2. 客户接收回执期限（通常为5个工作日）

  3. 内部调查流程

  4. 客户反馈回复期限（通常不超过20个工作日）

  5. 记录保存制度（每起投诉保存5年以上）

  6. 投诉数据年度归档机制（合规官汇总报告）

附件：投诉表模板、回复格式示例、客户告知信范本

六、模板5：《MLRO任命函 + 高管履历模板》说明

MLRO（Money Laundering Reporting Officer）任命须提交：

  • 正式任命信 + 董事会会议记录摘要

  • MLRO职责清单（反洗钱体系执行、STR提交、员工培训等）

  • MLRO简历（包含AML培训记录、过往经验、无犯罪证明）

附件：AML培训结业证书样本、MLRO承诺书模板、职责月度值勤模板

七、模板6：《法律意见函 + UBO结构图》说明

法律意见函主要用于：

  • 说明公司结构合法性（包含控股关系）

  • 确认所提供服务是否确属MiCA下监管范围

  • 符合MiCA第3章至第5章相关条款

  • 描述公司是否已在其他欧盟司法管辖区注册或被处罚

附件：由律师签发的PDF扫描+英文译本（立陶宛语可选）

UBO结构图须清晰展示：

  • 所有自然人最终控制股东路径

  • 控股比例 ≥25%的股东必须申报

  • 所有中间层公司须标注注册国家+注册号

八、建议模板提交格式与命名约定

模板名称 建议文件名格式
商业计划书 01_Business_Plan_RGX_Lithuania.pdf
AML/KYC手册 02_AML_KYC_Policy_RGX_v1.pdf
冷钱包权限图 03_ColdWallet_Structure_Flowchart.pdf
系统说明书 04_IT_Systems_Overview_RGX.pdf
STR流程图 05_STR_Flowchart_and_Policy.pdf
MLRO任命函 06_MLRO_Appointment_Letter.pdf
 

所有文档建议统一编号 + 英文命名，以便审查人员阅读排序。

九、结语：一套成熟模板 = 缩短审批周期的关键

监管机构最怕看到的是“形式化空模板”。您应使用模板的基础结构作为合规骨架，在其中注入企业真实的业务逻辑与内部制度执行流程。我们建议：

  • 每份模板不要“照抄照搬”，应进行“合规本地化加工”；

  • 所有关键模板均附有使用说明、常见错误提示、提交格式要求；

  • 若不熟悉MiCA条款与结构，建议委托合规顾问预审润色；

如需获取可编辑的 Word / Excel / PPT 模板包，请留言仁港永胜唐生索取《MiCA申请材料模板合集》。

第十二篇章：MLRO职责模板 + STR报告范例（含自动识别机制）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、什么是MLRO？为什么MiCA必须设置？

MLRO（Money Laundering Reporting Officer，反洗钱报告官）是MiCA架构中企业最核心的合规角色之一，要求如下：

✅ 具备反洗钱法规知识与实际经验
✅ 对客户行为、交易模式具备审查与报告能力
✅ 独立履行职责，不受董事会干预
✅ 有权直接向监管机构（如BoL、FIU）提交STR报告

MLRO不是形式角色，BoL常会在审查阶段单独约谈MLRO，测试其是否真实胜任。

二、MLRO职责模板（范例）

以下为MiCA合规结构下推荐的MLRO月度/季度/年度职责清单：

频率 职责 工具或记录方式
每日 审查系统自动标记的可疑交易（STR预警） 风控引擎后台审阅记录
每周 审核新增客户KYC完整性与风险分级 客户尽调记录
每月 汇总STR监测情况，记录未上报理由 STR处理日志
每季度 更新黑名单、匹配OFAC/EU高风险地区清单 黑名单更新通知截图
每半年 员工反洗钱培训（含技术/业务部门） 培训签到表、课程内容
每年 提交AML年度报告 + 合规制度更新摘要 年报PDF文件与董事会会议纪要
 

可搭配《MLRO值勤记录表模板》、《STR登记与处置日志表格》使用。

三、MLRO任命函模板（重点内容）

To Whom It May Concern,

This is to confirm that Mr./Ms. [Full Name] has been officially appointed as the Money Laundering Reporting Officer (MLRO) of [Company Name], in accordance with Article 61 of Regulation (EU) 2023/1114 (MiCA).

His/her responsibilities shall include:
- Overseeing the implementation of AML/KYC procedures;
- Identifying and assessing suspicious transactions;
- Filing Suspicious Transaction Reports (STR) to the Bank of Lithuania and FIU;
- Ensuring regular AML training for staff;
- Acting independently in compliance matters.

This appointment is effective as of [Date].

Sincerely,  
[Director Name]  
[Company Stamp
 

另须附：

  • 履历摘要（CV）

  • AML培训证书（可为立陶宛或等效欧盟国家）

  • 无犯罪记录证明

四、STR报告机制详解（MiCA强制要求）

STR（Suspicious Transaction Report）即可疑交易报告，是MLRO必须履行的监管义务之一。

MiCA监管机制规定：

  • 所有STR必须以书面形式向BoL/FIU提交；

  • 必须有记录并保存至少5年；

  • 应包含交易明细、涉事账户、判断理由、截图附件；

五、STR报告自动识别机制（系统逻辑推荐）

系统应设置自动识别规则引擎（Rule Engine）触发预警，如：

编号 规则描述 响应行为
R1 客户单日出金 ≥ €10,000 且为首次大额交易 自动发送警报至MLRO后台
R2 IP位置频繁更换 + 登录设备切换 风控标记“账户异常”
R3 发送加密资产至高风险国家（如朝鲜、苏丹）地址 强制冻结 + STR预警
R4 客户KYC文件疑似伪造或OCR识别失败 标记为潜在欺诈，推送人工审核
R5 客户使用匿名混币工具（如Tornado Cash） 自动生成STR草稿报表
 

建议集成风控引擎与AML管理模块，如：

  • Chainalysis KYT

  • ComplyAdvantage

  • Elliptic

  • Sumsub（包含AML+KYC监控）

六、STR报告范例（英文标准格式）

—STR REPORT—

Report Date: 2025-06-17  
Reporting Entity: RGX Crypto Lithuania UAB  
License No.: CASP-LT-2025-0082  
MLRO: Eva Balciunaite  

Subject: Suspicious Transfer to High-Risk Address

Transaction ID: 0x876abc...901  
Wallet: 0x12fcd...e9a  
Date & Time: 2025-06-15 14:34 UTC  
Amount: 3.98 BTC (~€238,000)  
Destination: Wallet known to be associated with sanctioned Iranian entity (OFAC SDN List)

Reason for suspicion:
- First-time customer
- Immediate deposit followed by full withdrawal
- Destination address listed on OFAC

Actions Taken:
- Transaction temporarily blocked
- Internal investigation launched
- This STR submitted to BoL and FIU

Attached: KYC documents, transaction screenshots, risk engine log.

MLRO Signature: ____________________
 

七、STR登记日志建议模板结构（Excel格式）

序号 STR编号 客户名 触发规则 报告日期 是否上报 上报机构 附件
001 STR-20250615-001 John Smith R3 2025-06-16 是 BoL, FIU 链接

八、监管机构审核重点（MLRO问答常见问题）

问题 回答建议
你认为可疑交易的最常见迹象是什么？ 不一致KYC、异常金额、使用匿名混币器、IP/国家切换等
你过去是否提交过STR？为何？ 是，客户将资产发送至黑名单地址。系统自动识别后提交报告
STR多久必须上报？ 发现后应立即内部核查，并不迟于5个工作日内上报
你如何确保STR的保密性？ STR提交后仅限合规团队访问，存储于加密服务器，限制读取权限

九、结语：MLRO是MiCA下企业与监管之间的“首席沟通者”

MiCA监管体系已将MLRO角色制度化、功能实务化、责任法律化。一个合格的MLRO不仅要能识别与上报，还必须能建立制度、培训员工、协调审计、应对BoL面谈。

建议申请人配备：

  • 《MLRO职责明细表》

  • 《STR登记日志模板》

  • 《AML培训年度计划表》

  • 《自动预警规则集汇编》

第十三篇章：商业计划书（加密钱包 + 交易平台）撰写结构与合规要求详解

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐上永先生撰写讲解。

一、商业计划书在MiCA申请中的地位

在MiCA申请流程中，《商业计划书（Business Plan）》是仅次于AML/KYC制度的核心文件之一。它不仅是BoL审查企业合规性与可持续性的重要依据，也影响ESMA对其服务范围、风险等级的认定。

BoL对BP的格式无强制模板，但内容结构必须实质可审查，尤其适用于拟经营以下服务者：

✅ 加密资产托管（钱包服务）
✅ 加密资产交易平台运营（集中撮合/流动性撮合）

二、商业计划书推荐结构总览（适用于MiCA）

编号 章节名称 内容说明
1 执行摘要（Executive Summary） 公司概况、申请目标、拟开展的服务简述
2 公司背景与架构 注册信息、团队成员、UBO、结构图
3 申请牌照内容说明 申请的CASP服务类别、业务流程
4 产品与技术系统介绍 钱包设计、交易系统、权限分层、安全机制
5 市场定位与目标客户 客户类型、主要市场区域、流量来源预测
6 风险识别与管理机制 操作风险、IT风险、法律风险应对方案
7 合规框架描述 AML/KYC策略摘要、STR机制、客户适当性政策概览
8 财务预测模型 三年收入/成本/盈利预测 + 假设前提说明
9 发展路径与关键里程碑 启动时间表、系统上线计划、客户增长计划
10 退出或应急预案 若终止运营时的客户资产保护与合规处理计划

三、加密钱包（Custodian Wallet）业务内容写法详解

示例结构与写作重点：

服务说明（What）：

  • 提供基于多签或MPC机制的冷钱包托管服务

  • 面向B端（项目方）与C端（终端用户）

  • 具备交易审查与反洗钱预警模块

技术框架（How）：

  • 每个客户资产分钱包独立存储

  • 签名层采用2-of-3多签权限控制

  • 日志系统全量保存每次授权记录

合规机制：

  • 冷钱包恢复机制说明书

  • 黑名单地址拦截系统接入

  • 设定出金限额、白名单地址、审批流程

建议插图：冷钱包权限控制图（参考第八章）

四、加密资产交易平台业务内容写法详解

示例结构与写作重点：

平台类型说明（CEX / OTC / DeFi聚合）：

  • 采用撮合引擎（Matching Engine）

  • 不进行链上撮合（MiCA不接受链上交易自动执行）

  • 平台保留客户资产，设定最低准备金比例

客户交易路径描述（用户如何买卖）：

  1. 用户KYC → 钱包充值 → 资金到达托管账户

  2. 用户挂单 → 撮合成交 → 平台通知清算模块

  3. 提现需再次身份验证 + 限额审批

风控机制：

  • 系统风险偏好模型 + 限价机制

  • 高频交易识别与限制（如RT/HFT标记）

  • 停牌机制、异常价格断路器（Circuit Breaker）

五、市场定位 + 客户策略撰写模板

要素 示例内容
客户群体 面向中欧及北欧市场的合规客户、Web3初创项目方
客户风险评估 分三层次：低/中/高风险国别或客户行为
用户增长路径 初期与Web3钱包集成、NFT项目合作提供法币通道
市场差异化 强冷钱包控制能力 + MiCA牌照合规结构 + 简洁API对接

六、三年财务预测模板结构

建议包含以下指标：

项目 Year 1 Year 2 Year 3
客户数量 1,000 4,000 10,000
平均每月交易额 (€) 2,000,000 5,000,000 12,000,000
托管资产余额 (€) 10,000,000 25,000,000 50,000,000
年收入总额 €180,000 €550,000 €1,500,000
年支出（人力+IT+合规） €220,000 €400,000 €700,000
净利润 -€40,000 €150,000 €800,000

附加表格：费用分项、合规成本明细、客户获取成本估算（CAC）

七、常见问题与监管建议（BoL视角）

问题 答案建议
营收模型是否合规？ 强调不会承诺收益、不具备投资合同属性、不吸收客户资金
技术系统能否支撑大规模业务？ 提供系统处理能力估算报告，如撮合TPS、日处理笔数
客户是否会来自高风险国家？ 如有此类目标客户，须提供EDD程序与STR响应机制
若平台停摆，客户资产如何处理？ 建立退出计划：如安排备份托管商、客户资产退款路径说明

八、结语：一份合格BP = 50%成功率

MiCA下的商业计划书，早已不是单纯的“市场宣传文件”，而是反映合规逻辑、监管结构、实操能力的核心材料。一份精准表达业务实质、合规措施明确、风险管理逻辑合理的BP，将极大提高审查通过概率。

建议配合使用以下附件，原件可向仁港永胜唐生索取：

  • 《商业计划书结构提纲模板》

  • 《财务预测表格（Excel）》

  • 《交易平台系统图 + 操作流程图》

  • 《退出机制白皮书（Exit Plan Draft）》

第十四篇章：MiCA申请结构图 + 权限控制图（冷钱包、系统、职责权限）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、为什么MiCA要求结构图与权限控制图？

MiCA要求持牌申请人提交清晰的业务结构图和系统权限控制图，以协助监管机构（如BoL、ESMA）评估：

✅ 组织职责是否明确
✅ 钱包权限是否分层
✅ 系统访问是否合规隔离
✅ 管理与操作之间是否形成制衡

这类图解应与申请文件中的《IT系统说明书》、《AML政策》、《合规职责表》内容一致，避免结构混乱、权限集中、监管盲区。

二、企业组织结构图（组织+职责分布图）

样式建议（可Visio / PPT / Lucidchart绘制）

graph TD
CEO[CEO / Managing Director]
RO1[Responsible Officer 1]
RO2[Responsible Officer 2]
MLRO[MLRO]
Compliance[Compliance Officer]
Finance[Finance Officer]
ITHead[IT Head]
Support[Customer Support]

CEO --> RO1
CEO --> RO2
RO1 --> MLRO
RO1 --> Compliance
RO2 --> Finance
RO2 --> ITHead
ITHead --> Suppor
 

图解说明建议附注：

  • CEO统筹管理，但不能同时兼任MLRO

  • 合规线与财务线互不干扰，权限独立

  • MLRO可与Compliance Officer协作，但职责不同：前者主STR，后者主内控

三、加密钱包权限控制图（冷钱包签名分层）

MiCA对钱包类服务商特别强调：权限必须分层、操作必须记录、签名必须多重。

冷钱包权限分层图（推荐 2-of-3 签名结构）

flowchart LR
Admin[系统管理员]
Operator[交易执行人员]
Compliance[MLRO/合规负责人]
Wallet[冷钱包控制系统]
Audit[审计员（只读）]

Admin -->|创建签名规则| Wallet
Operator -->|发起交易请求| Wallet
Compliance -->|批准交易+签名| Wallet
Wallet --> Audit

  • 签名策略建议：2人联签（Operator + Compliance），系统Admin不可单独签名

  • 操作记录建议：每笔出金记录操作人、时间、IP、设备ID

  • 审计接口建议：设有审计员账号，具备只读权限查看日志

四、IT系统结构图（系统模块分层）

推荐结构图模块：

graph TD
A[用户界面]
B[账户模块]
C[交易撮合引擎]
D[钱包系统]
E[风险控制系统]
F[合规审查接口]
G[日志/审计中心]
H[数据库]

A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H

模块说明：

模块 说明
用户界面 客户端登录、交易、KYC上传
账户模块 用户资产余额、历史交易明细
撮合引擎 限价单/市价单撮合逻辑
钱包系统 与冷钱包联动，权限审批链
风控系统 实时监控、交易限额、地址评分
合规接口 STR触发、黑名单验证、客户风险评级
日志中心 所有操作日志（合规/技术/客服）
数据库 存储结构化KYC数据、交易数据、审计数据
 

建议交互界面附带箭头说明数据流方向，标注系统部署位置（建议在EU内）

五、职责权限对照表（附控制逻辑）

角色 权限 是否可签名 是否可查看钱包 是否可操作STR
CEO 签署战略文档 ❌ ✅ ❌
Compliance Officer 查看操作+审批政策 ✅ ✅ ✅
MLRO 可提交STR、冻结账户 ✅ ✅ ✅
IT管理员 系统维护 ❌ ❌（只读建议） ❌
财务主管 报表生成 ❌ ✅（查询） ❌
客服人员 KYC辅助 ❌ ❌ ❌

六、实际提交格式建议

类型 建议格式 命名方式
组织结构图 PNG / PDF / Visio / PPT 01_OrgStructure_RGX.pdf
钱包权限图 PDF / PNG 02_ColdWallet_Flowchart_RGX.pdf
IT系统结构图 PDF / Lucidchart 03_IT_Architecture_RGX.pdf
权限对照表 Word / Excel 04_AccessMatrix_RGX.xlsx
 

文件中建议附“说明页”，解释每个角色职责与权限边界，确保BoL审查时图与文一致。

七、监管面谈常见问题（结构图环节）

问题 答案建议
谁有权限控制客户出金？ 仅由Operator发起，Compliance复核后联签
冷钱包钥匙存放机制是？ 多签结构，Key片段分布在安全硬件中，具备恢复流程文档
系统如何阻止单人操控资产？ 所有资产转出需2人审批，系统自动锁定关键路径
合规系统是否能直接下达操作命令？ 合规系统仅审查风险提示，操作由IT或交易系统执行

八、结语：MiCA结构图不仅是图纸，而是监管透明度的体现

监管结构图是申报材料中最容易被低估、也最容易出问题的部分。它应起到“让监管官一眼看清贵公司合规性”的作用，而不是形式应付。

建议使用可编辑图形工具（Visio、Lucidchart、draw.io）制作，并配合职责说明书提交。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第十五篇章：系统合规说明书模板（含功能说明 + 安全控制 + 风控逻辑）

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA对系统合规的核心要求

MiCA法规特别强调加密资产服务商（CASPs）必须构建可控、可审计、可复原的技术系统结构。申请人需提交一份系统合规说明书（IT Systems Compliance Statement），用于说明以下关键问题：

✅ 系统架构是否符合数据保护与监管逻辑？
✅ 是否对客户资产具备权限管控与资金隔离？
✅ 是否支持日志记录、STR识别、灾备恢复？
✅ 是否具备合规触发逻辑与风控规则引擎？

二、系统合规说明书的推荐章节结构

章节编号 标题 内容概要
1 系统概述 构成、架构图、部署模型
2 用户账户与权限管理 用户角色划分、员工权限分层
3 钱包系统结构与签名机制 冷钱包、权限逻辑、多签管理
4 客户资产与公司资产隔离 数据隔离机制、数据库结构
5 风控模型与合规规则引擎 自动识别逻辑、交易风控触发器
6 STR识别与报告机制 可疑交易识别、系统触发、MLRO介入
7 日志记录与留存机制 日志类型、保留期限、安全访问控制
8 数据存储与灾备架构 数据中心位置、加密备份、恢复流程
9 外包服务与第三方系统说明 是否使用Fireblocks、KYT接口、OCR厂商等
10 技术审查责任人说明 CTO或IT主管签名声明页

三、样例摘选：关键章节内容范式

1️⃣ 系统概述示例：

本公司采用模块化系统架构，共包含五大核心模块：
- 客户前端系统（Web App + Mobile App）
- 中台账户与撮合系统（Internal Ledger + Matching Engine）
- 钱包托管系统（Cold Wallets + MPC节点）
- 风控审查系统（Rule Engine + KYT API）
- 审计与日志中心

部署于 AWS Frankfurt，冗余节点设于Hetzner（Vilnius）。系统设计符合GDPR与MiCA数据可追踪、隔离、授权原则。
 
2️⃣ 钱包权限与签名机制范式：
冷钱包采用 2-of-3 多签权限策略，权限划分如下：
- Operator：可发起出金指令，但不可签名执行；
- Compliance Officer（MLRO）：负责风险复审，拥有签名权；
- Security Admin：维护权限策略，不参与日常签名。

签名系统由 Fireblocks MPC 控制平台提供，所有签名行为自动记录操作人、时间、设备指纹。

3️⃣ 风控规则引擎定义：

规则编号 描述 系统行为
R01 客户首次交易金额超过 €10,000 触发警告，MLRO审核
R02 同一设备绑定多个高风险国家IP 自动冻结账户，记录STR草稿
R03 地址命中OFAC/EU黑名单 拒绝交易，推送监管备案
R04 使用混币服务（如Tornado Cash）地址 标记“匿名风险”，发起EDD（二级尽调）
 

建议使用 ComplyAdvantage、Chainalysis KYT、Elliptic 做为数据支撑引擎。

4️⃣ STR提交与日志记录机制：

  • 所有触发STR的交易，系统自动生成草稿并提交至MLRO后台审批；

  • STR提交成功后，生成唯一STR编号，并保存至合规数据库；

  • 所有操作日志保留至少5年，日志内容包含：

    • 操作人账户 + 职位

    • 操作时间（UTC）

    • 操作对象（如钱包地址、交易ID）

    • 设备指纹/IP记录

四、数据存储与灾备建议模板说明

要素 内容
数据中心 主节点部署于 AWS Frankfurt，备份节点于立陶宛Hetzner
数据加密 使用 AES-256 + TLS1.3 网络传输协议
灾备恢复流程 每日增量备份 + 每周全备 + 双地恢复模拟每季度1次
数据保留期限 所有合规数据保留 ≥5年（含STR、KYC、交易）
客户数据出境限制 所有敏感数据存储于欧盟境内，不转移至第三国

五、第三方系统说明模块（如外包/托管商）

如使用第三方技术服务，应列明：

类型 供应商 是否签署DPA 用途
MPC钱包托管 Fireblocks ✅ 已签署 多签控制系统
KYT风险识别 Chainalysis KYT ✅ 地址风险评分、交易行为分析
OCR识别引擎 Sumsub OCR ✅ 身份证件自动识别比对
云部署平台 AWS Frankfurt ✅ 系统主节点托管
 

⚠️ 所有第三方应提供 GDPR/MiCA 兼容性声明 + SLA 服务协议。

六、说明书提交建议格式与附图清单

文件类型 格式建议 附图
系统说明书 Word/PDF（建议含签名页） 系统结构图、钱包签名图
风控逻辑表 Excel（带颜色标记） 风控规则矩阵图
签名权限逻辑图 PNG/PDF 多签流程图
数据流图 Visio / Lucidchart 用户交易路径图
灾备流程图 PPT / PDF 数据恢复路径图（含时间节点）
 

七、BoL审查重点与实务建议

审查问题 建议回应
系统如何确保客户资金安全？ 冷钱包 + 日限额 + 多签机制，全流程日志审计
是否能识别可疑交易？ 内建规则引擎，联动AML/KYT系统，自动生成STR草稿
是否可恢复系统？ 已设置冗余节点 + 定期演练 + 完整数据镜像
外包服务是否监管透明？ 全部签署DPA，提供合规证明文件，系统集成接口安全审核通过

八、结语：一份合格的系统合规说明书 ≠ 技术白皮书

它不是写给开发人员的说明书，而是写给监管者、审计师、MLRO阅读并判断的“可监管性报告”。它需要语言严谨、逻辑完整、流程清晰、权限分明。

建议配合以下附件，原件可向仁港永胜唐生索取：

  • 《风控规则矩阵表模板》

  • 《系统结构图绘图稿（可编辑）》

  • 《合规接口说明书模板》

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

第十六篇章：《冷钱包托管政策范本（含签名权限机制 + 灾备演练记录模板）》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

一、MiCA对客户资产托管的核心要求

根据MiCA条例第67条至第70条，加密资产服务提供商（CASPs）在托管客户加密资产时必须：

  1. 明确托管责任，不得将客户资产与自有资产混合；

  2. 建立冷钱包托管机制，以保障资产安全；

  3. 实施签名权限分层机制，防止单点故障与道德风险；

  4. 定期进行灾难恢复演练，并形成记录归档；

  5. 建立客户资产损失赔偿制度（保险/储备金）或书面方案。

二、冷钱包托管政策内容结构（建议模板）

建议将冷钱包托管政策以正式制度文件格式提交，包含以下章节：

章节 内容概览
1️⃣ 适用范围与监管依据 引用MiCA条文与本制度适用业务类型
2️⃣ 钱包架构说明 钱包种类、冷热分层、技术平台（如Fireblocks）
3️⃣ 权限分层制度 定义各级角色及签名权配置（如2-of-3多签）
4️⃣ 出入金流程 包括风控前置、审批、签名与出金验证环节
5️⃣ 日常管理规范 包含白名单地址、限额设置、日志追踪等
6️⃣ 冷钱包灾备制度 包含密钥备份、MPC分布地点、演练频率等
7️⃣ 钱包资产保险或风险控制机制 包括保险安排或应对损失的责任方案
8️⃣ 附录 签名权限示意图、演练记录模板、应急预案
 

三、签名权限分层制度设计说明（案例模板）

建议采用 2-of-3 多签机制，权限角色如下：

权限角色 职责 是否具签名权 常驻地
Operation Officer 发起出金请求、编制出金指令 ❌ 可远程
Compliance Officer（MLRO） 审核交易合法性与客户风险情况 ✅ 常驻欧盟
Security Officer 审批权限控制、验证请求路径与系统完整性 ✅ 建议在立陶宛本地

出金流程：

flowchart TD
    A[发起人提交出金请求] --> B[合规负责人审核]
    B --> C[安全负责人二次验证]
    C --> D[生成多签命令]
    D --> E[资金出金
 

⚠️ 每一次签名行为必须写入日志（签名人身份、时间、请求内容、设备指纹/IP等）。

四、出入金流程范式（文字版流程）

  1. 客户在平台发起提现申请（系统验证KYC/AML等级 + 地址归属 + 冻结历史）

  2. Operation Officer 于钱包系统内录入请求，并设定出金金额与币种

  3. Compliance Officer 审查该出金是否满足AML、限额、地址风险要求

  4. 若通过，Security Officer 在控制面板验证请求数据并完成签名

  5. 所有流程在钱包系统日志、审计系统、风控数据库中记录并封存

五、灾备机制及定期演练政策（含演练模板）

钱包灾备包括：

灾备要素 内容要求
密钥备份机制 私钥分片应存储于不同国家/物理设备，并加密存储
MPC签名服务 使用Fireblocks或合规MPC工具，具备节点分散
系统恢复能力 可在1小时内恢复冷钱包访问权限与签名模块
演练频率 至少每季度1次，包括：签名失败、异常响应、密钥恢复
 

灾备演练记录模板：

日期 类型 参与人员 问题模拟 恢复时间 是否成功 演练结论
2025-03-15 密钥恢复演练 MLRO + CTO 模拟冷钱包密钥丢失 27分钟 ✅ 响应及时，流程完整
2025-06-10 非法地址白名单绕过 安全员 + Compliance 测试未授权地址出金 13分钟拦截 ✅ 签名系统正确拒绝，记录已存

六、保险或损失赔偿机制设计建议

欧盟MiCA允许如下两种方式满足客户资产安全保障义务：

模型 内容
钱包保险政策 与注册保险商签订保险合同，覆盖热/冷钱包被盗、密钥泄露等情况
内部赔偿储备金机制 单独设立客户资金赔偿基金账户（不低于冷钱包资产总额的2%）+ 全年审计报表
 

建议结合公司规模与业务性质选择其中之一，并形成书面说明（附保险单或储备金账户银行证明）。

七、审查注意点（BoL关注问题）

问题 审查意图 建议回应
是否混用客户与公司资产？ 保障客户利益隔离 明确冷钱包分属客户独立账户
是否具备权限控制与风控联动？ 防止滥用或被盗 提供多签权限逻辑与审计流程
是否设置限额与监控？ 避免大额突然转移 提供出金上限与权限分级设置
灾备是否可靠？ 防止丢失密钥或数据 演练记录完整 + 冗余储备说明
是否有保险机制？ 若平台破产或被盗时如何赔偿 提供保险或风险基金制度说明

八、冷钱包托管政策提交建议格式

  • 建议使用 PDF/Word 文档格式，附签名页（CTO + MLRO）；

  • 附带权限控制图、演练记录表、白名单机制截图；

  • 可配合其他文件如《系统结构图》《AML政策手册》《合规年审日志》联合呈报。

九、结语：冷钱包政策是MiCA审查核心文件之一

不论您使用Fireblocks、Bitgo、Copper还是自建MPC钱包系统，冷钱包托管制度必须具备：

  • 明确逻辑

  • 文件记录

  • 签名权限

  • 灾备预案

  • 客户资金保障

若您需要一套完整的《冷钱包托管政策范本（中英文对照）》+ 灾备记录表格模板（Excel）+ 签名流程图（可编辑Visio/PDF），请告知，我将为您配套提供。选择一间专业专注的合规服务商协助牌照申请及后续维护及合规指导尤为重要，在此推荐选择仁港永胜。

第十七篇章：《MiCA常见问题大全（适用于客户答疑）》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇章汇总了在MiCA加密资产服务过程中客户最常提出的问题及标准答复格式，适用于平台前线客服/合规专员/销售部门与客户沟通时参考使用。每个问题配标准应答语、MiCA条款依据及客户关切点，支持中英文双语版本输出。

一、MiCA背景与合规性常见问题

问题编号 客户问题 标准答复
Q1 什么是MiCA？为什么你们要拿这个牌照？ MiCA（Markets in Crypto-Assets）是欧盟统一监管框架，自2024年底起生效。我们申请MiCA CASP牌照，是为了合法合规地在欧盟提供加密资产服务，客户资金与操作更有保障。
Q2 你们已经拿到MiCA牌照了吗？ 我们正按欧盟MiCA条例正式申请CASP牌照，相关流程已提交至立陶宛央行。预计在监管时间节点内完成并通告客户。
Q3 MiCA牌照在哪些国家有效？ MiCA是欧盟统一牌照，在全部27个欧盟成员国及欧洲经济区内有效，支持跨境护照制度。
Q4 如果没有MiCA牌照，可以继续交易吗？ 自2025年6月起，所有在欧盟境内提供加密资产服务的公司必须持有MiCA CASP牌照，否则即属违规。我们正积极合规申请，确保客户服务不中断。
 

二、客户资产托管与安全保障

问题编号 客户问题 标准答复
Q5 我的加密资产是你们保管吗？ 是的。我们使用冷钱包及MPC技术进行资产托管，分层权限管理，并严格区分客户与公司资产。托管政策已通过欧盟监管审查。
Q6 钱包是热钱包还是冷钱包？安全吗？ 我们使用多签机制的冷钱包系统，确保私钥离线隔离、安全审计，符合MiCA对客户资产最高级别保护要求。
Q7 如果平台破产，我的资产怎么办？ 根据MiCA第67-70条规定，客户资产独立托管，不计入平台资产。如出现风险，我们设有赔偿机制与钱包保险方案保障客户权益。
Q8 你们的钱包托管在立陶宛吗？ 是的，核心数据及冷钱包托管节点均部署在欧盟境内，以符合数据监管与灾备审查标准。
 

三、KYC与客户尽职审查（适当性评估）

问题编号 客户问题 标准答复
Q9 为什么要做KYC？不能匿名注册吗？ MiCA及欧盟反洗钱法规（AMLD6）要求所有加密资产服务必须完成客户身份识别（KYC）流程，保障交易安全与防止非法资金。
Q10 提交哪些文件才能开户？ 需上传有效身份证明（护照/ID）、地址证明（近3月内账单/水电单）及风控问卷，以完成开户流程。
Q11 你们会把我的KYC资料提供给别人吗？ 不会。除非因监管要求（如可疑交易申报STR）需向监管或执法部门提交，否则我们不会向任何第三方提供您的资料。
Q12 做了KYC就可以交易所有资产吗？ 不一定。根据客户适当性评级结果，部分风险较高产品如衍生品或稳定币（ART）将只开放给经验丰富的客户。
 

四、费用与操作相关常见问题

问题编号 客户问题 标准答复
Q13 有哪些费用？是否透明？ 我们承诺所有费用将事先公示，包括充值手续费、交易点差、提现费率、托管费用等。您可在官网或App内清楚看到每笔费用说明。
Q14 提现到账时间多久？ 通常在工作日内24小时内完成冷钱包授权与链上确认；若遇大额或疑似风险交易，可能会延迟审核，请您理解。
Q15 能否使用欧元或法币充值？ 可以。我们支持SEPA转账与部分电子钱包充值法币，兑换为加密资产后进行交易。
Q16 钱包地址可以重复使用吗？ 为提升隐私与链上分析防御，我们建议每次充值使用不同生成地址，平台已提供此功能支持。
 

五、MiCA生效时间与平台进度

问题编号 客户问题 标准答复
Q17 MiCA什么时候开始强制实施？ 对EMT/ART类稳定币：2024年12月起强制执行。对CASP服务商：2025年6月起全面执行。我们计划在此时间前全面持牌运营。
Q18 原来你们是VASP吗？MiCA之后还可以继续吗？ 我们曾持有立陶宛VASP登记证明，目前正在过渡为MiCA正式牌照。原客户不受影响，服务将无缝升级。
Q19 是否所有服务都要拿MiCA？ 是的，平台交易、托管、兑换、发币等均属于MiCA下的CASP服务类型之一，必须持牌后才可运营。
 

六、语言/客户支持常见问题

问题编号 客户问题 标准答复
Q20 有中文服务吗？你们团队在哪？ 有的。我们提供中英双语支持，客户经理来自香港/立陶宛/新加坡。您可通过WhatsApp、微信或官网工单联系到我们。
Q21 平台客服回复慢怎么办？ 若常规渠道未能及时回应，您可通过邮件support@xxx.com 或拨打热线+370 xxx联系合规专员进行跟进。
Q22 平台是否支持多语种界面？ 是的，目前支持中、英、德、立陶宛语等界面，并可根据您的账户默认设置切换显示语言。
 

七、FAQ设计建议（适用于企业合规/客服团队）

  1. 格式统一：每个问题配编号，便于内部引用、审查备查；

  2. 答复合规：务必与MiCA、AMLD6法规条文一致，避免误导；

  3. 多语版本：中英文对照，适合不同客户群体；

  4. 可嵌入前端：建议以FAQ网页组件、邮件模版或App弹窗展示；

  5. 可导出PDF/手册：供SFC/BaFin/CSSF等监管抽查客户教育环节使用。

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

八、是否需要标准文档模板？

可提供如下文档资源，原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]：

  • 《MiCA客户FAQ文档模版》（Word版，含编号+法条注解）

  • 《前端FAQ网页内容结构建议》

  • 《客服培训答疑模板+标准用语指南》

  • 《FAQ合规审阅检查表》（适用于法务审查）

第十八篇章：《商业计划书（加密钱包+交易平台）》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇章专门解析在申请立陶宛MiCA CASP牌照过程中所需提交的《商业计划书》（Business Plan）编制指南，适用于涉及“加密钱包服务”+“加密资产交易平台”双重业务模型的企业。涵盖内容框架、撰写要点、合规重点、监管预期和财务预测要求，确保满足立陶宛央行（BoL）及欧盟监管（ESMA）审查标准。

一、编写目的

商业计划书是MiCA申请材料中的核心文件之一，其作用包括：

  • 展示公司业务模型及发展目标；

  • 向监管机构证明其具备持续经营能力；

  • 说明如何合规运营加密资产服务；

  • 提供3年期财务预测，辅助BoL评估公司偿付与风控能力。

二、结构框架建议（适用于MiCA申请）

商业计划书推荐使用以下结构布局：

序号 模块名称 内容说明
1 执行摘要（Executive Summary） 公司背景、业务概览、MiCA牌照申请类别及战略目标
2 公司组织结构（Legal & Governance Structure） 公司架构图、股东背景、董事会/高管职能分配、MLRO责任划分
3 服务类型说明（Services Offered） 明确列出10类MiCA CASP服务中适用的类型（如钱包管理、交易撮合等）
4 市场分析（Market Analysis） 目标市场、竞争格局、合规优势、客户定位（B2C/B2B）
5 商业模型（Business Model） 收费模式、用户增长路径、收入渠道、成本结构、平台结构（钱包+撮合引擎）
6 风险管理体系（Risk Management） 针对运营、市场、法律、技术等风险的识别与缓释方案
7 合规制度简述（Compliance System） AML/KYC流程、STR制度、合规官架构、MiCA合规实施路径
8 IT系统与数据安全（IT System & Cybersecurity） 钱包系统（含冷钱包）、交易引擎、系统架构、安全措施、备份节点说明
9 财务计划（Financial Projections） 未来3年财务报表预测（损益、现金流、资产负债表），包含资本支出计划
10 附录与声明 审计师或法律顾问声明函、董事签字页、UBO结构说明等
 

三、撰写关键内容详解

✅ 钱包服务部分应包括：

  • 钱包类型：冷钱包、热钱包、MPC钱包等；

  • 密钥管理机制：多签结构、权限分层图；

  • 资产隔离机制：平台自有资产与客户资产的分账方式；

  • 托管制度：是否使用第三方托管、如何实施合规托管责任。

✅ 交易平台服务部分应包括：

  • 撮合机制：是否为集中撮合（Order Book）、是否自动成交；

  • 对接渠道：是否接入其他加密交易所、法币通道结构；

  • 客户操作路径：下单、撮合、结算、提现完整流程；

  • 市场风控模型：限价单保护、异常订单识别、流动性补偿策略等。

四、财务预测模板（3年期）

✅ 报表类型：

  1. 损益表（Profit & Loss Statement）

  2. 资产负债表（Balance Sheet）

  3. 现金流量表（Cash Flow Statement）

✅ 关键指标涵盖：

  • 客户数量增长预测（用户数/活跃地址数）

  • 平均资产托管量（AUC）

  • 交易手续费收入（% of trading volume）

  • 钱包服务年费（如托管费）

  • 人力资源成本（合规官、客服、IT工程师等）

  • 系统开发与维护费用

  • 审计/法律/保险费用

建议提供基础情境、中性情境、最优情境三套版本，展示不同市场表现下的财务稳定性。

五、合规监管关注点

监管要求 商业计划书必须回应
持续运营能力 是否具备3年以上正现金流发展路径
客户资产保障 客户资金是否与平台资金隔离存放
AML/KYC机制 客户身份识别、风险评级与交易监控流程是否清晰
系统稳定性 系统服务架构、权限管控、冷备机制是否说明
实质性经营 是否具备本地办公、本地董事与技术人员说明
 

六、附录推荐材料

建议附带以下附加材料，提升审查通过率：

  • 《公司控股结构图》（附UBO说明）

  • 《MiCA服务类型与实际服务功能对照表》

  • 《冷钱包权限管理说明文档》

  • 《3年财务预测Excel附表（含注释）》

  • 《法律顾问出具的合规运营建议函》

七、标准模板与撰写建议

若需快速制作合规模板，推荐使用以下资源：

  • ✅《MiCA专用商业计划书模版》（Word+Excel）

  • ✅《平台业务流程图+结构图矢量模板》

  • ✅《多签冷钱包合规说明样本》

  • ✅《ESMA监管关注清单比对表》

八、评估/审查建议

  • 建议使用第三方审计师或律师事务所进行商业计划书合规预审；

  • 所有数据预测应“保守+合理+有注释”；

  • 计划书内容应与IT说明书、AML手册保持一致。

第十九篇章：《冷钱包托管政策范本》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇章专为申请立陶宛MiCA CASP牌照的企业设计，全面解析《冷钱包托管政策》的合规编制方法，涵盖技术结构、权限分层、安全控制、操作流程及审计机制。该政策文件为申请MiCA牌照必备材料之一，需配合IT系统说明书、AML政策手册等同步提交。

一、文档作用与监管关注重点

冷钱包托管政策的作用包括：

  • 向监管方展示客户资产的安全保障机制；

  • 明确平台对冷钱包资产的管理责任与权限划分；

  • 符合MiCA对“客户资产分离、权限控制、安全存储”的三大要求；

  • 附属支持IT安全合规性评估与业务持续性说明。

二、适用范围与托管类型

✅ 文件适用于以下CASP服务类型：

MiCA服务类型 是否强制要求冷钱包政策
加密资产托管服务（第1类） ✅ 强制
加密资产交易平台运营（第2类） ✅ 强制
客户订单执行与自营交易（第7/8类） ⚠️ 建议配套
资产交换服务（第3/4类） ⚠️ 建议配套

三、政策结构建议（标准模板）

序号 模块名称 内容说明
1 引言 文件目的、法规依据（MiCA、AMLD6、BoL通告）
2 钱包体系架构 冷/热钱包区分、冷钱包分布式节点图
3 资产托管政策 资产隔离方式、客户分账机制、保险机制
4 权限控制机制 多签结构、签名人名单、层级控制
5 操作流程 存币/提币授权流程、审批流、操作人员职责
6 密钥管理策略 硬件存储、备份节点、恢复机制
7 异常管理与应急响应 丢失、攻击、错误交易场景下的响应计划
8 审计与日志记录 操作审计、时间戳记录、第三方审计
9 外包托管政策（如适用） 委托第三方冷钱包管理时的合规声明与控制标准
10 定期测试与演练 年度灾备演练机制、测试报告保存规定


注：原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]


四、关键要点逐条详解

1️⃣ 钱包体系架构

  • 所有冷钱包应物理隔离于联网环境；

  • 使用HSM硬件加密模块或Ledger/Trezor类设备；

  • 多地多节点冷备，建议地理分布在 EU 境内。

2️⃣ 权限控制机制

签名方式 推荐配置
3-of-5 多签结构 至少5位签名人，需3人签署才可放行资产
内部分级 签名人来自不同部门：法务、合规、技术
外部审批人 可引入独立董事或合规外部顾问参与审批
 

  • 设置签名权限手册；

  • 每笔提币必须附操作审计日志与截图；

  • 所有操作记录保留 ≥ 5年。

3️⃣ 密钥管理与备份

  • 密钥分散存储（不能集中交由一人或一机构控制）；

  • 离线备份保存在两地保险柜，并加封加密；

  • 密钥更换频率建议半年一次；

  • 灾备恢复需附完整流程图及测试记录。

五、应急响应机制建议

应急机制必须覆盖：

  • 冷钱包设备遗失或损坏；

  • 私钥外泄或被入侵；

  • 内部员工串谋盗取；

  • 法律机关突袭冻结资产。

建议内容包括：

  • 24小时内启动内部通报机制；

  • 启动“冻结/转移”冷钱包资产的应急路径；

  • 报告监管机构（BoL + ESMA）并提交STR报告；

  • 通知保险机构与客户（如适用）；

  • 记录事故详情，事后评估报告建议附录提交。

六、监管合规关注要点（审查建议）

项目 BoL/ESMA 关注重点
权限分层 是否明确“谁有权发起/审核/放行”？
客户资产独立性 冷钱包资产是否清楚标示客户所有权？
物理安全性 是否非联网？是否使用认证HSM设备？
操作可追溯性 是否有完整日志、操作记录与定期审计？
第三方托管 是否有合规说明、责任划分、可控性？

七、模板格式建议

建议冷钱包政策文件以 Word/PDF + 图解 附件方式提交，并附带以下内容：

  • ✅《冷钱包签名流程图》

  • ✅《签名权限职责矩阵图》

  • ✅《应急响应操作时间轴》

  • ✅《分布式密钥存储地图》

注：原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]

八、参考工具及资源建议

如需加快政策文件生成进程，可使用以下模板，原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]：

  • 《冷钱包托管政策Word版标准模版（含流程图）》

  • 《Ledger硬件钱包配置指南》

  • 《HSM部署与审计接口对接说明书》

  • 《应急响应流程标准操作程序（SOP）》

  • 《权限层级控制图（Visio格式）》

  • 《监管反馈意见常见问题汇总》

第二十篇章：《常见问题大全（适用于客户答疑）》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇章系统整理了MiCA结构下，加密资产服务商（CASP）常见问答内容，适用于客服部门、投资者关系部门、监管应对准备、合规面谈等业务使用场景。所有问答依据《MiCA条例（EU 2023/1114）》《AMLD6》《立陶宛银行BoL通告》及ESMA指南进行标准化答复。

一、MiCA法规与监管结构常见问题

Q1：MiCA条例适用于哪些类型的加密资产？
答：MiCA适用于除NFT及DeFi协议以外的大多数加密资产，主要分为三类：

  • EMT（电子货币型代币）

  • ART（资产参考型代币）

  • 其它虚拟资产（如效用型代币、交易币）

Q2：MiCA和立陶宛VASP制度有什么不同？
答：立陶宛VASP是国家级注册制，MiCA是欧盟统一牌照监管体系，具备跨境passporting效力，监管强度更高，要求更全面。

Q3：我公司已是VASP，是否需重新申请MiCA？
答：是的。MiCA将取代VASP制度，2025年6月起，未完成MiCA转化的公司将失去运营资格。建议提前准备。

Q4：MiCA牌照是哪家机构核发的？
答：在立陶宛，由立陶宛银行（Bank of Lithuania）受理；最终监管协调机构为ESMA（欧洲证券与市场管理局）。

二、业务开展常见问题

Q5：MiCA CASP牌照是否可以在整个欧盟通行？
答：是的。MiCA牌照可在所有欧盟及EEA成员国通行，无需逐国申请二次许可（passporting机制）。

Q6：MiCA牌照是否可支持交易平台业务？
答：可以。需在申请时声明服务类型为第2类“运营加密资产交易平台”，并满足更高资本金（€150,000）与IT系统要求。

Q7：MiCA是否允许Token发行（ICO/IEO）？
答：允许，但须申报资产白皮书，并获得国家主管机关核准。若代币为EMT/ART，还需额外EMI/CRR授权。

Q8：是否可以提供非托管钱包服务？
答：可提供，但不属于MiCA强监管范围，建议同时建立托管结构以拓展业务合规边界。

三、IT系统与钱包安全常见问题

Q9：是否必须建立冷钱包？
答：若申请第1类“保管服务”，必须建立冷钱包架构，并提交详细《冷钱包托管政策》与权限控制说明。

Q10：冷钱包是否可以外包给第三方？
答：可以，但需签订合同、声明责任边界，并由申请方承担最终监管责任。

Q11：是否需要日志系统和STR接口？
答：是的。IT系统需支持完整交易日志、风险识别、STR生成接口，以及事后审计。

Q12：数据中心是否可以设在非欧盟？
答：不可以。客户数据和资产系统必须托管在欧盟境内的数据中心（含灾备中心）。

四、合规人员与董事问题

Q13：RO和MLRO是否必须设在立陶宛？
答：建议至少有一位负责人常驻立陶宛；远程任职可行，但需配合监管备案、设立常驻办公地址。

Q14：董事是否需要金融或区块链背景？
答：需具备相应“受监管行业经验”，如银行、金融科技、AML/风险合规等背景。

Q15：是否可以只任命一个负责人？
答：不行。MiCA要求至少两位独立高管，共同履行管理与合规职责（Dual-Control制）。

五、资金与审计常见问题

Q16：资本金是否可由股东贷款方式注入？
答：不建议。资本金应为实缴注资，不得通过短期借款、非实益持有方式注入。

Q17：资本金使用是否有限制？
答：部分可用于技术投入、市场拓展，但必须保留一定比例作为风险缓冲；不得全部耗尽。

Q18：是否必须指定外部审计？
答：是的。每年需提交审计报告，由立陶宛注册审计机构签发，覆盖财务与内控制度。

Q19：MiCA实施前获批是否能直接转换？
答：VASP牌照企业可申请“过渡机制”，经补充材料审查后升级为MiCA持牌人，流程较正式申请简化。

六、运营维护常见问题

Q20：获批后是否可自由增减业务范围？
答：不可。变更服务类型需提前向BoL申请变更并补充文件，未经批准前不得开展新服务。

Q21：年审内容包含哪些？
答：包括但不限于：

  • 财务报表；

  • 合规报告（AML执行、KYC审查情况）；

  • IT系统安全测试；

  • 高管变化申报。

Q22：是否需设立合规培训机制？
答：必须。MiCA要求每年有至少一次员工AML培训，并保留记录供BoL查验。

Q23：如业务终止，如何注销牌照？
答：需提前60天向BoL提交业务终止声明，清算客户资产、结清税务、交还监管牌照后方可正式注销。

七、常见疑难情形处理建议

场景 建议处理
冷钱包私钥意外丢失 启动灾备流程，向BoL提交事件说明与补救措施
更换MLRO负责人 提前30日备案 + 提供新任人选履历与声明
系统发生DDoS攻击 封锁外部访问、隔离系统、记录日志、提交STR
客户拒绝配合KYC 暂停服务、提交可疑交易报告（STR）

第二十一篇章：《商业计划书（加密钱包+交易平台）》

立陶宛MiCA牌照申请注册指南 · 深度解释完全指南，由仁港永胜唐生撰写讲解。

本篇章将详细讲解如何编制符合MiCA条例要求的商业计划书，适用于正在申请CASP牌照的加密资产服务商，尤其包括“钱包服务商（Custody）”与“交易平台运营商（Exchange）”两类核心业务申请人。

该商业计划书可用于提交至立陶宛银行（BoL），也可作为监管机构合规面谈、投资人尽调、银行开户材料等使用。

一、商业计划书整体结构建议

商业计划书应清晰、实用、合规，建议结构如下：

推荐目录结构

编号 模块名称
1 执行摘要（Executive Summary）
2 公司结构与背景介绍
3 服务概况（钱包+平台）
4 市场分析与竞争优势
5 商业模式与盈利模型
6 客户类型与招揽计划
7 风险识别与应对策略
8 IT系统架构与冷钱包方案
9 合规制度与AML框架
10 高管团队介绍
11 财务预测（3年）
12 结语与发展愿景

二、加密钱包服务（Custody）板块重点说明

1️⃣ 客户资金托管策略

  • 冷热钱包比例说明（如：90%冷钱包，10%热钱包）；

  • 多签机制（如：3/5签署制度）；

  • 资产隔离制度（客户资产与公司运营资金完全隔离）；

  • 每日资产对账机制与异常处理流程。

2️⃣ 权限管理逻辑

  • 内部分层（操作岗 / 审核岗 / 管理岗）；

  • 区块链节点控制责任归属；

  • 异常操作自动锁定策略；

  • 外部审计公司定期核查冷钱包权限配置。

三、交易平台业务（Exchange）板块重点说明

1️⃣ 撮合机制说明

  • 撮合是否为内部订单簿；

  • 是否允许P2P或AMM模型；

  • 是否具备链上交易桥接能力；

  • 撮合延迟与系统冗余机制。

2️⃣ 法币与加密资产兑换模型

  • OTC处理方案（自营/第三方）；

  • 与银行法币对接策略；

  • AML检测工具集成（如Chainalysis、Elliptic）；

  • 实时价格来源说明。

四、市场分析与竞争对比

1️⃣ 目标市场定位

  • 面向欧盟境内B端企业钱包托管、交易所服务；

  • 零售端：个人投资用户或Defi用户过渡需求。

2️⃣ SWOT分析

维度 说明
优势 持MiCA通行证、低税率、高级别合规设计
劣势 初期用户基数低，品牌影响力待建立
机会 欧盟新监管环境带来集中用户迁移
威胁 大型交易所竞争压力（如Binance Europe）

五、财务预测结构建议（3年）

样表示例（单位：EUR）

年度 收入 成本 利润 注资资金余额
第1年 250,000 420,000 -170,000 330,000
第2年 600,000 500,000 +100,000 430,000
第3年 1,200,000 750,000 +450,000 880,000
 

说明：

  • 成本包括人力、技术维护、审计、牌照年费等；

  • 注资资金余额必须维持在BoL规定的最低资本金以上；

  • 盈利模式可标明为手续费、提现费、账户费等。

六、高管与合规板块补充说明

1️⃣ 高管团队信息（摘要）

  • CEO/COO简历、核心成就；

  • CTO技术主导经验；

  • MLRO合规履历、STR处理经验。

2️⃣ 外部顾问团队介绍（如有）

  • 法律顾问：提供MiCA法律分析与监管应对；

  • 审计顾问：提供年度审计与审阅支持；

  • 合规服务商（如仁港永胜）：负责制度搭建、培训支持、STR申报引导等。

七、附录建议

  • 冷钱包控制结构图；

  • 权限分层说明；

  • 客户KYC流程图；

  • 系统风险预警图示；

  • Token发行业务流程图（如适用）；

  • AML报告流程图。

八、撰写实务建议

✅ 建议使用英文撰写，便于提交至立陶宛监管机构
✅ 保持篇幅控制在25~40页之间（PDF格式），包含图表与附录
✅ 所有运营假设应附有“合理依据”或来源（如市场调研、KPMG报告、ESMA报告）
✅ 所有财务数据应以欧元呈现，汇率假设注明来源（如ECB参考汇率）

✅ 本文文档/附件原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]

第二十二篇章：《系统结构图》全面介绍（深度解释）完全指南

适用于MiCA牌照申请中的技术合规文件要求，由仁港永胜唐生撰写讲解。

一、章节导言

系统结构图（System Architecture Diagram）是MiCA牌照申请中的核心组成部分，尤其适用于以下业务类型：

  • 加密资产托管（Custody）

  • 加密资产交易平台（Exchange）

  • 加密资产转账服务（Transfer）

  • 钱包管理平台（Wallet Providers）

本章节旨在系统性解释该图的核心组件、绘制原则、监管重点及配套文档建议，确保平台能够在BoL（立陶宛银行）及ESMA（欧洲证券及市场管理局）审核中顺利通过。

二、监管视角下的“系统结构图”功能定位

维度 描述
合规性验证 展示系统权限、交易、风控、合规分离逻辑
安全性评估 体现冷/热钱包隔离、灾备架构、数据安全机制
审计配合 支持STR追溯、客户资金流动路径、系统日志
技术审查 向IT监管提供接口、节点、控制点的完整图解
 

三、系统结构图应包含的核心组成模块

以下为MiCA合规架构中建议的系统模块（适用于交易平台+钱包）：

1. 用户接入层（Frontend）

  • 用户Web端 / App端

  • 用户登录认证（含MFA机制）

  • API对接层（如提供B2B服务）

2. 业务逻辑层（Business Logic）

  • 钱包模块：热钱包 / 冷钱包分离模块

  • 交易撮合引擎：订单簿 / 撮合规则 / 手续费引擎

  • 结算清算模块：实时账户变更+余额校验

  • 法币支付网关接口（SEPA、SWIFT桥接）

3. 权限与身份层（IAM）

  • 角色分层：用户 / 运营 / 审核 / 系统管理员

  • 签名权限控制图（Cold Wallet 3/5 或 2FA机制）

  • 区块链节点访问控制层

  • 账户冻结 / 黑名单 / 审计可控接口

4. 风控与AML层

  • KYC验证引擎（外部对接Sumsub、Onfido等）

  • AML交易监测系统（连接Chainalysis、Elliptic等）

  • STR生成接口（支持监管接入）

  • 交易风控模型（大额预警、异常频率拦截）

5. 数据与日志层

  • 客户数据存储（合规数据保留 ≥5年）

  • 日志系统（用户操作、资金流动、后台变更）

  • 系统备份机制（本地+异地双冗余）

  • 合规数据接口（提供导出结构化CSV）

6. 安全与灾备层

  • 防火墙与入侵检测系统

  • 异地灾备计划（如立陶宛本地与爱沙尼亚同步站）

  • 多节点数据同步机制

  • 安全补丁管理系统（定期更新记录）

四、图示展示建议（结构图草图）

以下是推荐的逻辑层结构示意（可用Visio、Draw.io绘制）：

graph TD
A[用户终端] --> B[接入API & 网页/APP认证层]
B --> C[交易撮合引擎]
B --> D[钱包管理模块]
C --> E[账户结算系统]
D --> F[冷钱包签名控制系统]
E --> G[AML & 风控监控系统]
G --> H[日志 & 合规数据模块]
H --> I[灾备系统与同步节点]

  • 左侧：用户接入与指令发出

  • 中部：系统业务逻辑处理区

  • 右侧：风控、日志、审计、备份

五、冷钱包结构说明建议（配套说明文件）

除结构图外，MiCA强制要求说明冷钱包权限与结构控制机制。建议附带以下图：

✅ 多签控制图（Multisig Control）

3/5 多签钱包机制：

- Signer 1：CEO
- Signer 2：MLRO
- Signer 3：技术负责人
- Signer 4：外部合规顾问
- Signer 5：审计员监控Key

授权交易必须满足：≥3签署人共识 + 审计授权流程。

六、注意事项与监管建议

项目 建议说明
数据主机位置 应明确服务器/钱包存储地是否在欧盟境内
外包说明 所有外包系统/工具（如托管、KYC引擎）需列明服务方名称、合规状态
实时性 是否支持实时监控风控指标、STR自动提交
合规接口 系统是否支持BoL或ESMA规定的监管数据抽取格式

七、配套文档建议一览

文件名称 内容
系统结构图（PDF） 核心业务层、权限层、审计层图解
冷钱包权限说明（附图） 多签人身份、操作流程、灾备机制
系统说明书 IT架构说明、第三方服务清单
合规技术说明文 支持MiCA条款引用、结构图注释说明
API接口文档（如对接第三方） 提供对监管查询、KYC外包等说明

第二十三篇章：《AML政策手册》全面介绍（深度解释）完全指南

适用于MiCA牌照申请CASP合规要求的反洗钱制度设计范本，由仁港永胜唐生撰写讲解。

一、章节导言

MiCA框架要求所有加密资产服务提供商（CASP）在申请前必须具备一套完备、实用、持续更新的反洗钱（AML）政策手册。该手册不仅是向**立陶宛银行（Bank of Lithuania）**提交的法定材料之一，同时也在牌照获批后的持续合规中发挥关键作用。

二、AML政策手册的主要作用

功能 描述
合规承诺 明确公司履行AMLD6及MiCA下的AML义务
内部指导 为所有员工提供操作规则与红旗指引
外部监管 为BoL/ESMA监管检查、审计提供结构化制度材料
STR配套 为可疑交易报告（STR）建立制度化评估标准

三、手册核心框架结构（建议章节）

  1. 引言与适用范围

  2. 法律框架依据（AMLD6 + MiCA第90~97条）

  3. 客户识别制度（KYC）

  4. 加强尽职调查制度（EDD）

  5. 客户分类与风险评分体系（CRR）

  6. 交易监控与红旗行为识别

  7. 可疑交易报告机制（STR）

  8. 员工培训计划与记录

  9. 高级管理层职责与审核流程

  10. 手册更新与审计记录机制

  11. 第三方外包与合作方KYC审查制度

  12. 数据留存与监管披露义务

四、关键制度模块深度解释

✅ 1. 客户识别制度（KYC）

内容 要求
自然人客户 护照、住址证明、合规声明、面部识别
企业客户 公司注册证书、章程、董事名册、UBO结构图
验证方式 实名认证 + 电子验证 + 视频KYC 或引入外部KYC平台
样本附录 建议附上《客户尽调表》、《UBO结构说明书》模板
 

✅ 2. 加强尽职调查（EDD）

场景 触发条件
高风险客户 非欧盟客户 / 加密资产频繁大额交易者 / 黑名单国家
法人结构复杂 多层境外控股结构、SPV、信托持股
触发机制 EDD流程启动 + 管理层审批 + 可疑交易备注归档

✅ 3. 可疑交易识别机制（STR）

步骤 描述
识别信号 红旗指标模型（如短时间大额转出、多次失败KYC尝试）
初步筛查 运营人员提交“潜在可疑活动报告”至MLRO
STR生成 MLRO整理证据 → 使用模板填报STR表格
向监管提交 若需提交至BoL/ESMA，保存副本、时间戳、执行证据

⚠️ 附：建议提供《STR报告模板 + 提交流程图》

✅ 4. 员工培训制度

内容 频率
AML培训（基础） 新员工入职前必须完成（含KYC/EDD/STR基础）
AML进阶培训 每年1次更新，包括欧盟AMLD6、MiCA新规
培训记录 员工签字档案 + 培训幻灯片 + 测试题报告归档

✅ 5. 数据保存与审计追踪

  • 客户尽职调查记录、交易日志、STR申报记录 ≥ 保留5年

  • 推荐建立“合规归档编号体系”供审计时检索

  • 每季度进行一次内部AML制度执行审计并由MLRO汇报董事会

五、监管引用条文（MiCA + AMLD）

法规 核心条款 内容概览
MiCA 第90~97条 CASP的AML责任、KYC义务、STR义务、MLRO任命
AMLD6 全文适用 欧盟第六反洗钱指令，对犯罪定义、处罚及合作有明确标准

六、附录模板建议（文件+说明）

模板文件 内容描述
《AML政策手册（完整版）》 正式制度文档PDF + Word可编辑格式
《STR报告模板》 含触发逻辑、内容结构、申报时间线
《KYC尽职调查表》 自然人/法人客户表格版本
《客户风险评级模型评分表》 自动评分逻辑（可Excel实现）
《MLRO内部职责备忘录》 汇报关系、权限分工、决策流程
 注：以上文档/附件原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]

七、实操建议

  • 建议使用KYC即服务（KYC-as-a-Service）外包方（如Sumsub、Fractal等）集成流程；

  • STR系统应支持日志追踪、时间戳、水印导出功能，便于审计；

  • 可与IT团队协作构建自动红旗触发模型（如链上地址识别、交易异常模型）；

  • 推荐至少每年更新1次手册，并向员工发布培训指引；

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

第二十四篇章：《冷钱包权限说明》全面介绍（深度解释）完全指南

适用于MiCA牌照申请中托管服务合规的关键制度文档，由仁港永胜唐生撰写讲解。

一、章节导言

在MiCA监管体系下，加密资产服务提供商（CASP）如涉及“托管服务”（Custody Services），必须提供清晰、可审计、合规可控的冷钱包权限结构说明文档。本章节将全面讲解如何构建一份符合欧盟审查标准的《冷钱包权限说明》，该文档是IT合规体系中核心组成部分，直接影响牌照能否获得批准。

二、冷钱包合规的监管核心要求

监管要求 描述
权限控制 多级权限分层：操作员、审核员、批准人、系统管理员、MLRO
安全机制 多签验证、多重物理/电子隔离、灾备机制、登录审计
权限透明 权限说明需覆盖所有热/冷钱包及其接口、调用逻辑
冷钱包定义 必须为完全离线保存、隔离网络的私钥系统

三、权限说明文档的基本结构建议

  1. 权限管理概述

  2. 钱包结构设计图

  3. 权限角色及职责明细

  4. 钱包启用/提币流程说明

  5. 冷钱包生成与备份机制

  6. 多签机制及门限管理

  7. 审计日志保留策略

  8. 安全事件应对机制

  9. 灾难恢复与系统切换方案

  10. 定期权限审查与更新机制

四、角色与权限说明（建议格式）

角色 权限 说明
操作员（Operator） 发起提币请求 无批准权
审核员（Checker） 复核操作员请求 必须不同人
批准人（Approver） 多签触发 不少于2/3门限签名
系统管理员 钱包部署维护 不得参与提币审批流程
MLRO 审计观察权限 可冻结特定地址或阻止提币执行
 

⚠️ 推荐权限组合示例：3人提币结构：2人签名 + 1人审计

五、冷钱包结构图示范（文字图解）

┌─────────────────────────────┐
│       冷钱包多签结构           │
│ ┌────────────┐              │
│ │ 操作员A     │              │
│ └────────────┘              │
│ ┌────────────┐              │
│ │ 审核员B     │────┐         │
│ └────────────┘    │ 多签     │
│ ┌────────────┐    ├─────> 提币审批完成（2/3）执行冷钱包释放
│ │ 批准人C     │────┘         │
│ └────────────┘              │
└─────────────────────────────┘

、关键合规设计点

✅ 1. 冷钱包密钥生成与备份

  • 密钥必须离线生成（建议用 Ledger、Trezor、HSM 等硬件）

  • 生成过程必须有2名以上见证人 + 拍摄记录

  • 密钥备份建议封存至2个物理地点，由不同人保管

✅ 2. 提币流程控制

步骤 描述
1. 用户申请提币 提交申请至后台系统
2. 操作员初审 检查KYC + 风险标记
3. 审核员复核 提币逻辑核实、验证地址
4. 多签人批准 达成设定门限（如3/5）后释放交易

所有步骤记录时间戳、用户信息、交易摘要、IP地址。

七、冷钱包多签机制说明模板片段（建议）

“The CASP's cold wallet system is structured using a 3-out-of-5 multisignature scheme. The keys are distributed among three designated personnel, with no single person able to complete a transaction alone. The private keys are generated via hardware devices in an offline ceremony and sealed separately in two geographic locations with signed witness records. Each transaction must be proposed, verified, and approved by distinct individuals and logged in an immutable ledger stored on the company's internal audit server...”

八、灾备机制与系统切换

场景 说明
冷钱包设备丢失 使用封存备份设备启动冷钱包
多签人离职 更新门限签名密钥时应触发Key Rotation流程
灾难级事件（火灾、泄漏） 地理隔离备份启动，恢复交易权限

九、建议附加文档列表

文档 用途
《冷钱包使用政策》 钱包部署与流程说明
《权限签署人登记表》 签名人KYC、职务、授权范围
《冷钱包密钥备份记录》 密钥创建过程、封存证明
《冷钱包提币流程图》 提币流程图文版用于SOP归档

十、审计与监管建议

  • 所有提币/充值事件应生成不可篡改日志（使用Hash签章）

  • 建议结合自动化风控引擎判断大额提币是否需额外审批

  • 每季度进行一次“冷钱包权限审计”并向董事会报告

文件交付建议：

如提交给监管机构（立陶宛银行 / ESMA），推荐文档结构为：

  1. 正式PDF版本（签名盖章）

  2. Word可编辑版（供监管意见修订）

  3. 附带结构图PNG版本 + 审批流程图Visio文件

  4. 多语言版本（英文为主 + 立陶宛语/中文可选）

  5. 注：本文文档/附件原件可向仁港永胜唐生索取 [手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）索取电子档]

如需进一步协助，包括申请、合规指导及后续维护服务，请随时联系仁港永胜 www.jrp-hk.com 手机:15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）获取帮助，以确保业务合法合规！
如欲查询更多LT 立陶宛MiCA牌照申请注册指南（详细介绍），Lithuania MiCA License Application and Registration Gui有关的资料，请与我们仁港永胜的专业顾问联络，我们将为您提供免费咨询服务。[点击联系公司注册专业顾问]
24小时专业顾问：15920002080（深圳/微信同号） 852-92984213（Hongkong/WhatsApp）
上一页： 上一页：已经没有了
下一页： 申请香港RAW牌照,Apply for Hong Kong RAW license

最新文章
推荐文章

专业提供注册金融牌照 | 仁港永胜 | 联系方式 | 新闻中心 |常见问题 | 网站地图

仁港永胜是一家领先的全球性合规服务公司，致力于为金融行业提供全方位的监管合规支持与服务，确保客户在复杂的法规环境中顺利运营，申请或收购合规牌照首选仁港永胜。

申请合规牌照 | 金融牌照申请 | 香港SFC牌照申请或收购 | 香港MSO牌照申请或收购 | 美国金融合规牌照申请 | 欧洲EMI牌照申请或收购 | 申请英国FCA牌照 | 申请香港SFC9号牌或收购