决策摘要
管理层在集成前应决定哪些事项
明确提供商
识别为每项受监管服务签约并实际提供服务的实体，而不仅是提供界面的实体。
审查客户方角色
检查品牌展示、指令处理、裁量权、资产控制或客户支持是否使产品公司进入受监管活动范围。
区分相邻服务
将托管、加密资产转账、法币支付和技术分别归入具备适当授权或承担相应责任的实体。
保持证据持续有效
上线前及发生重大变更后，根据当前官方记录核实授权、服务范围和跨境通知。
提供商审查
从职能和提供商关系图入手
从客户旅程入手，将每项操作追溯至相应法律实体。合同很重要，因为它告知客户由谁承担服务义务，但如果实际运营呈现不同情况，合同措辞并非决定性因素。如果一方决定是否执行订单或控制客户密钥，仅在合同中将其称为技术供应商并不能修正该模式。
实际审查分为三个层次。第一，识别承诺提供的服务以及被列为提供商的实体。第二，识别由谁实施构成该服务的实际活动，包括客户接纳、指令处理、执行、转账和托管。第三，确认对受监管服务层负责的实体持有适用于拟议服务及欧盟经营范围的必要许可。还需对产品公司重复这一审查:即使另一实体明确是客户的CASP，产品公司自身的行为仍可能需要分析。
模式比较
四种常见结构中的提供商分别是谁？
| 模式 | 通常的签约方及受监管提供商 | 产品公司角色 | 仍需审查的事项 |
|---|---|---|---|
| 纯技术模式 | 产品公司或独立CASP为受监管服务签约；供应商提供软件或基础设施。 | 设计业务方案并使用技术栈，但不将受监管决策委托给供应商。 | 审查供应商是否处理指令、控制密钥、行使裁量权，或以其他方式提供超出技术职能的服务。 |
| 引介方 | CASP与客户签约、接纳客户并为其提供服务。 | 营销或转介潜在客户，随后将受监管客户关系移交给CASP。 | 沟通话术、报酬、数据流、订单处理和转介后行为可能表明该角色已超出引介范围。 |
| 嵌入式或白标模式 | 即使客户旅程采用产品公司的品牌，合同仍会披露CASP，并由CASP提供受监管服务。 | 根据约定的责任分工图，负责部分界面、分销和客户体验环节。 | 品牌、披露、指令流、支持和运营控制必须与法律责任分配一致，并避免形成监管光环。 |
| 直接受监管服务 | 产品公司依据自身适用的MiCA许可签约并提供服务。 | 运营受监管业务，并持续对服务交付及外包职能负责。 | 供应商或商业合作关系无法替代公司自身所需的授权或通知状态。 |
责任分工图
各参与方应负责哪些事项
| 参与方 | 核心责任 | 需记录的边界 |
|---|---|---|
| 产品公司 | 产品设计、分销、自有界面以及分配给产品公司的行为。 | 除非法律上确实如此，否则产品公司不应将自身呈现为获授权提供商，同时仍需审查自身活动。 |
| 选定的CASP | 在经核实的授权范围和运营覆盖范围内，提供其通过合同承诺的受监管服务。 | 客户接纳、AML控制、指令、托管、转账、披露和投诉必须明确分配，不应依赖推定。 |
| 支付或银行服务提供商 | 任何需要由另行获授权提供商提供的相关法币账户或支付服务。 | CASP身份本身并不涵盖所有法币、支付或银行职能。 |
| 技术供应商 | 约定技术范围内的基础设施、安全和服务水平。 | 运营访问权限和决策权不应与纯技术服务的分类相矛盾。 |
| SKY7 | 模式梳理、提供商筛选支持、入驻准备和集成协调。 | SKY7不提供受监管的加密资产服务，不持有客户资产或密钥，也不向客户转移授权。 |
外包
通过API交付并明确监管责任
MiCA允许外包，但根据第73条，CASP仍对其义务承担全部责任。这一点对嵌入式交付至关重要，因为前端、入驻模块或运营流程可能位于CASP之外，而受监管服务仍由CASP负责。相关安排需要明确访问、监督、事件处理、业务连续性、分包和退出权利。CASP也受DORA框架约束，因此不能将ICT依赖关系仅作为普通供应商事项附带处理。
CASP承担全部责任并不会消除产品公司自身的风险敞口。营销必须公平、清晰且不具误导性，客户界面必须明确相关提供商，产品公司也只能开展分配给自身的活动。运营责任可以分配，但服务明细表无法改写法律监管边界。
分步实施
如何梳理嵌入式加密服务模式
-
追踪客户旅程
将每个界面、合同、数据移交、指令、资产流动、支持渠道和投诉路径映射至控制该环节的实体。
-
对资产和服务进行分类
在分配角色或选择提供商前，确认产品性质以及哪些活动可能构成加密资产服务。
-
审查各参与方的行为
将合同中的角色名称与实际访问权限、裁量权、订单处理、密钥控制和面向客户的行为进行比较。
-
核实受监管提供商
针对拟议的欧盟运营模式，检查实时官方登记册、确切获授权服务及所需的跨境通知。
-
分配控制义务
记录AML与KYT、资金转移规则数据、托管、法币支付、披露、记录保存、投诉、事件和外包监督责任。
-
统一合同与界面
确保从首个产品界面到法律条款，对提供商身份、服务范围、费用、风险、支持和投诉的表述保持一致。
-
建立变更控制
当服务、资产、市场、客户类型、供应商或运营控制发生重大变化时，重新开展监管边界和证据审查。
证明资料包
监管边界审查前应准备哪些材料
-
客户旅程与流程图
客户、数据、法币和加密资产流，包括异常处理和投诉路径。
-
合同与披露
客户条款、合作方附表、同意措辞、产品界面和营销声明。
-
控制矩阵
系统访问权限、密钥、审批权、指令处理、执行逻辑和升级处理责任。
-
产品清单
资产、服务、客户类型和拟议的欧盟经营范围，并标注分类问题。
-
合规责任分配
AML与KYT、资金转移规则、制裁、托管、投诉、记录和监管报告。
-
提供商证据
结合拟议模式审查当前登记记录、许可范围、通知和尽职调查材料。
托管与支付
将资产、密钥和法币归入相应责任提供商
如果产品包含托管服务，客户协议应明确获授权的托管提供商，并反映由谁控制资产或访问手段。MiCA第75条对托管提供商规定了具体的协议和责任义务。转委托托管不能简单地隐入一般技术安排之中；下游提供商必须是另一家获得托管授权的CASP。
法币服务需要单独梳理。根据第70条，相关支付服务必须在法律允许的情况下由CASP自行提供，或由具备适当授权的支付服务提供商提供。因此，集成CASP并不会自动带来银行账户、支付通道或全部资产保障职能。客户旅程应明确列出每个提供商，避免暗示一项许可覆盖整个服务栈。
分类关口
先进行代币分类，再分配提供商角色
嵌入式产品可能涉及MiCA范围内的加密资产、受其他金融服务制度约束的资产，或混合结构。将业务称为代币化、RWA或基础设施并不能决定答案。应先对资产和每项服务进行分类，再审查权限与角色。即使CASP服务层分工严谨，也无法弥补产品其他部分的分类错误。
01 白标CASP安排会覆盖产品公司吗？
不会自动覆盖。CASP的授权支持其在范围内实际提供的受监管服务。产品公司的品牌展示、客户接触、指令处理、裁量权、资产访问权限和支持角色仍需单独进行监管边界审查。
02 我们的品牌能否作为主界面，同时由CASP担任提供商？
如果合同、披露信息和运营流程清楚标明CASP，并与实际责任分工一致，这可以成为可行的结构。界面不应使客户误以为产品公司持有其实际并未持有的授权。
03 引介方是否始终无需MiCA授权？
任何角色名称都不会形成安全港。实质上仅限于营销和转介的角色，不同于接收指令、安排受监管服务流程或控制执行。应审查沟通话术、数据移交、报酬安排以及转介后的行为。
04 应由谁持有客户资产或加密密钥？
托管结构应在客户协议和运营记录中明确获授权的托管提供商。密钥控制、提款、对账和转委托托管必须遵循这一责任分配。SKY7不持有客户资产或密钥。
05 CASP授权是否包括法币支付服务？
不能一概而论。相关支付服务需要具备合法资质的提供商及明确的角色分配。应核实CASP能否自行提供该功能，或是否需要另行获授权的支付或银行服务提供商。
06 依赖某一提供商前应核实哪些事项？
应核实法律实体、当前官方登记记录、确切服务权限、相关跨境通知、合同角色、托管与支付模式，以及其与拟议客户旅程的匹配程度。针对特定提供商的证据应在当前私下尽职调查中审查，而不应依赖笼统的公开声明。