首页 > 加密货币牌照

阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照申请注册指引

时间：2026-01-10 16:31:32 阅读：263

《阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照申请注册指引》

Virtual Assets Regulatory Authority（VARA）虚拟资产服务提供商（VASP）牌照

Dubai VARA Virtual Asset Service Provider (VASP) Licence Full Regulatory & Licensing Guide

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

Dubai VARA Virtual Asset Service Provider (VASP) Licence｜按业务活动分八大类
服务商：仁港永胜（香港）有限公司｜Rengangyongsheng (Hong Kong) Limited

牌照名称：阿联酋·迪拜 UAE – Dubai VARA牌照申请｜Dubai VARA License Application

✅ 点击这里可以下载 PDF 文件：阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照常见问题解答（FAQ）
✅ 点击这里可以下载 PDF 文件：阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照申请注册指南
✅ 点击这里可以下载 PDF 文件：关于仁港永胜
注：本文模板、清单、Word/PDF 可编辑电子档，可向仁港永胜唐生有偿索取（用于监管递交与内部落地）。

一、牌照核心信息（Regulatory Snapshot｜仁港永胜拟定）

国家 / 地区：
阿拉伯联合酋长国（United Arab Emirates）
迪拜酋长国（Dubai Emirate）
适用监管区域：
UAE – Dubai（非 DIFC，即不适用 DFSA 体系）
监管机构（发牌机构）：
Virtual Assets Regulatory Authority（VARA）
牌照英文正式名称：
VARA Virtual Asset Service Provider (VASP) Licence
（Licence granted per Virtual Asset Activity）
牌照中文正式名称：
迪拜 VARA 虚拟资产服务提供商牌照
（按虚拟资产业务活动分类授权）
官方许可的虚拟资产活动（共 8 类）：
1. Advisory（虚拟资产咨询）
2. Broker-Dealer（虚拟资产经纪 / 交易商）
3. Custody（虚拟资产托管）
4. Exchange（虚拟资产交易所）
5. Lending & Borrowing（虚拟资产借贷）
6. Management & Investment（虚拟资产管理及投资）
7. Transfer & Settlement（虚拟资产转移与结算）
8. VA Issuance – Category 1（虚拟资产发行类）
牌照定位总结（一句话）：

VARA 牌照是目前中东地区监管颗粒度最高、制度最完整、国际认可度最强的虚拟资产牌照之一，适用于以迪拜为区域总部、面向中东及全球市场开展合规虚拟资产业务的机构。

前言（Preface｜监管背景与指南定位）

自 2022 年迪拜酋长国正式设立 VARA 以来，迪拜成为全球首个以“虚拟资产”为核心对象设立独立监管机构的司法辖区。与传统金融监管“将虚拟资产嵌入证券/支付框架”不同，VARA 采取了独立立法、独立许可、独立持续监管的制度路径。

VARA 的监管哲学可以概括为三点：

以“活动（Activity）”而非“公司名称”作为监管边界
→ 只要你从事某一类虚拟资产活动，即进入 VARA 监管范围
以“可运行的合规体系”而非“文件堆叠”作为审批核心
→ 监管关注的是你是否具备持续、可审计、可追责的经营能力
以“市场完整性 + 投资者保护 + 技术安全”作为长期目标

本指南并非市场宣传资料，而是以监管递交与实务落地为目的的“交付级合规指引”，适用于：

准备在迪拜申请 VARA VASP 牌照的企业
已获得原则性批准（ATI）并准备进入正式牌照阶段的机构
投资人 / 董事会对 VARA 项目进行尽调与决策
合规官、法务、外部顾问用于制度搭建与文件准备

第 0 章｜指南使用说明（How to Use This Guide）

0.1 本指南的使用方式（强烈建议）

本指南 不是按“阅读型”写作，而是按 “实施型 / 交付型” 编排，建议按以下方式使用：

阶段一：业务定性
对照 第 3 章（许可活动分类），准确识别拟开展的虚拟资产活动类型
阶段二：结构设计
对照 第 11 章（托管隔离）+ 第 7 章（治理），设计集团及实体结构
阶段三：制度搭建
以 第 7–21 章 为蓝本，直接生成公司内部制度文件
阶段四：监管递交
参考 第 23 章（RFI-ready 递交），准备完整申请包

0.2 本指南的适用边界（重要）

本指南 仅适用于 UAE – Dubai（非 DIFC）
不适用于：
- DIFC（由 DFSA 监管）
- 其他酋长国（如 ADGM，由 FSRA 监管）

0.3 关键监管提醒（监管原文精神总结）

在迪拜，不存在“无需监管的虚拟资产业务”。
无论你是交易所、钱包、托管人、借贷平台、技术中介、发行方或咨询方，只要触及虚拟资产活动，即可能需要 VARA 的许可、批准或不反对确认。

第 1 章｜司法辖区定位与监管边界

Jurisdiction Positioning & Regulatory Perimeter

1.1 VARA 的监管覆盖范围

VARA 的监管权限覆盖：

迪拜酋长国本土（Mainland Dubai）
迪拜各自由区（Free Zones）
明确排除：DIFC

凡在上述区域内：

设立实体
向迪拜居民或机构提供服务
在迪拜进行市场推广
以迪拜作为业务中枢或管理中心

均可能被认定为 在迪拜“开展虚拟资产活动”。

1.2 “虚拟资产活动”定义的宽泛性（实务重点）

VARA 对 Virtual Asset Activity 的解释采取 实质重于形式 原则：

是否直接持有客户资产？
是否对交易、托管、转移具有控制或影响？
是否向客户提供与虚拟资产相关的金融或技术服务？

即便你自称是“技术提供商”或“平台服务商”，若在业务链条中具有关键功能，仍可能被要求持牌或备案。

1.3 常见误区（监管失败案例总结）

误区	VARA 实际态度
只做撮合，不碰钱	仍属于 Exchange / Broker-Dealer
只做钱包技术	可能构成 Custody
只做自营交易	可能需要注册或限制
海外公司不在迪拜	若实质经营在迪拜，仍受监管

第 2 章｜监管机构与法律框架

Regulator & Legal Framework

2.1 VARA 的法律地位

VARA 由迪拜酋长国法律设立，拥有：

独立立法授权
独立发牌与执法权
独立制定 Rulebooks 的权力

其监管效力 不低于传统金融监管机构。

2.2 核心法律与规则体系（必须理解）

VARA 监管体系由三层构成：

（一）一级法规（Primary Regulation）

Virtual Assets and Related Activities Regulations 2023

（二）二级规则（Rulebooks）

Company Rulebook
Compliance & Risk Rulebook
Market Conduct Rulebook
Technology & Information Rulebook
Custody Rulebook
Issuance Rulebook 等

（三）指引与公告（Guidance & Notices）

Marketing Guidance
Circulars
Public Notices

第 3 章｜许可展业范围与牌照分类逻辑

Scope of Licensed Activities & Licence Architecture

⚠️ 本章是 VARA 申请中最核心、最容易犯错的一章

3.1 VARA 的核心监管逻辑

VARA 不发“万能牌照”，而是：

按 具体虚拟资产活动 授权
每一活动 = 一组独立监管义务
多活动可合并在一家公司，但必须 逐项满足全部要求

3.2 八大虚拟资产活动（监管级解释）

3.2.1 Advisory（咨询）

向客户提供与虚拟资产相关的投资、交易或配置建议
包括收费或非收费形式

3.2.2 Broker-Dealer（经纪 / 交易商）

代表客户进行虚拟资产交易
或在交易中起撮合 / 中介作用

3.2.3 Custody（托管）

持有、控制或管理客户虚拟资产或私钥
监管要求最严格，必须独立法人

3.2.4 Exchange（交易所）

运营订单簿
撮合买卖双方
提供交易基础设施

3.2.5 Lending & Borrowing（借贷）

虚拟资产质押
收益产品
借币/借钱模型

3.2.6 Management & Investment（管理与投资）

资产管理
投资组合管理
代客管理

3.2.7 Transfer & Settlement（转移与结算）

虚拟资产转账
清算、结算安排

3.2.8 Issuance – Category 1（发行）

虚拟资产发行
白皮书
发行合规披露

3.3 关键监管红线（必须提前设计）

Custody 必须独立持牌、独立实体
持牌 VASP 不得进行自营交易（需另设公司）
营销行为本身即受监管

第 4 章｜申请路径与许可阶段

Licensing Pathway & Regulatory Stages（交付级全流程说明）

本章定位：
本章用于回答监管与客户最核心的问题之一：
“在迪拜，VARA 牌照到底是怎么一步一步拿下来的？”

VARA 的许可并非“一次性核准”，而是一个分阶段、可回溯、强互动的监管流程。申请人需在每一阶段向监管机构证明：

“我不仅理解监管要求，而且已经具备持续合规运营的能力。”

4.1 VARA 牌照申请的总体逻辑

从监管视角看，VARA 的授权逻辑可以总结为三句话：

先审主体资格，再审业务能力
先给原则性许可，再给全面经营权
先验证系统可运行性，再允许规模化展业

因此，绝大多数 VARA 项目都会经历以下标准路径：

意向接触 → 原则性批准（ATI）→ 制度与系统搭建 → 正式牌照（VASP Licence）→ 持续监管

4.2 阶段一：申请前准备（Pre-Application Readiness）

⚠️ 监管实务重点
VARA 并不鼓励“边准备边递交”。
准备不足的申请，会显著拉长周期，甚至被动终止。

4.2.1 申请前必须明确的四个核心问题

在任何正式接触 VARA 之前，申请人必须内部明确：

我到底从事哪一类 / 哪几类虚拟资产活动？
- 是否涉及 Exchange / Custody / Lending 等高风险活动
是否涉及客户资产？是否需要托管？
是否计划向零售客户提供服务？
集团层面是否存在自营交易、关联交易？

这些问题将直接决定：

实体结构

资本要求

制度深度

审查强度

4.2.2 申请前常见失败原因（经验总结）

常见问题	VARA 实际反应
业务描述模糊	要求重新定义活动范围
托管与交易混在一个实体	要求重组
无合规官/MLRO	不进入实质审查
制度模板化	要求重写

4.3 阶段二：原则性批准（Approval to Incorporate, ATI）

4.3.1 什么是 ATI？

ATI（Approval to Incorporate） 并非正式经营牌照，而是：

VARA 对申请人主体资格、业务方向与总体结构的“原则性认可”

获得 ATI 后，申请人可以但仅限于：

设立或完善迪拜实体
启动制度与系统建设
招聘关键人员
与银行、技术服务商进行实质对接

⚠️ 但不得正式开展受规管虚拟资产业务

4.3.2 ATI 阶段 VARA 重点关注内容

在 ATI 阶段，VARA 主要审查以下方面：

（一）主体与股权结构

公司注册地
股东结构及 UBO 穿透
是否存在高风险司法辖区

（二）拟开展的虚拟资产活动

对照 8 大类活动逐项说明
是否涉及 Custody（高度敏感）

（三）高层与关键人员

CEO / GM
Compliance Officer
MLRO

（四）总体合规思路

是否理解 VARA 的监管哲学
是否具备“长期合规”意愿与能力

4.3.3 ATI 阶段通常需要提交的材料（示例）

⚠️ 以下为实务中常见清单，最终以 VARA 要求为准

初步业务说明书（Business Overview）
拟申请的虚拟资产活动清单
股权与控制结构图
关键人员简历与声明
初步合规架构说明

4.4 阶段三：正式牌照申请（Full VASP Licence Application）

这是整个项目中最重、最耗时、最专业的一阶段

在获得 ATI 后，申请人将进入 Full Licence Application 阶段。

4.4.1 这一阶段 VARA 的核心审查问题

VARA 会系统性地审查：

“如果今天给你牌照，你是否能合规、安全、可持续地运营？”

因此，审查将覆盖：

公司治理
合规体系
风险管理
技术系统
客户资产保护
市场行为
财务稳健性

4.4.2 正式牌照阶段的核心交付包（监管级）

申请人通常需要准备以下完整制度与证据包：

（一）公司治理与组织文件

公司章程
董事会及委员会章程
授权矩阵（Delegation of Authority）

（二）合规与风险制度

Compliance Manual
AML/CFT Policy
Risk Management Framework

（三）技术与信息安全

系统架构图
信息安全政策
灾备与业务连续性计划

（四）客户资产与托管（如适用）

钱包结构
私钥管理
客户资产隔离机制

（五）财务与资本证明

资本金来源
财务预测
审计安排

4.4.3 VARA 的互动方式：RFI（Request for Information）

在正式申请阶段，VARA 几乎一定会发出多轮 RFI，用于：

澄清业务细节
要求补充证据
测试申请人对自身模式的理解程度

⚠️ 监管经验提示
RFI 的质量，往往比首轮申请材料更重要。
能否快速、清晰、一致地回应 RFI，是成败关键。

4.5 阶段四：牌照发放与附加条件（Licence Granting）

4.5.1 牌照的形式

VARA 发放的牌照通常包含：

获准的虚拟资产活动清单
适用的许可条件（Licence Conditions）
监管限制（如客户类型、地域、规模）

4.5.2 常见附加条件示例

限制零售客户
限制产品类型
要求额外资本或保险
要求定期监管汇报

4.6 阶段五：持牌后的持续监管（Post-Licensing Supervision）

⚠️ 获得牌照不是终点，而是监管关系的开始

4.6.1 持续义务包括但不限于：

年度监管费用
定期合规报告
财务与审计提交
重大事件即时上报

4.6.2 VARA 的监管风格

非形式主义：更关注实质运作
持续互动：不是“一次审完就放手”
可升级执法：从沟通 → 警告 → 处罚

4.7 本章小结（交付级总结）

VARA 牌照申请不是行政流程，而是“合规能力评估过程”。

成功的关键不在于“文件多”，而在于：

业务模式是否清晰
结构是否合理
制度是否可执行
管理层是否专业

第 5 章｜费用结构、资本金与监管收费机制

Fees, Capital & Prudential Requirements

本章定位：
本章用于系统回答以下核心问题：

VARA 牌照到底要花多少钱？

费用是一次性的还是持续性的？

VARA 是否有“最低注册资本”？

不同虚拟资产活动的资金要求有何差异？

本章内容唐生不以市场报价为目的，而是以监管理解与合规预算制定为目的。

5.1 VARA 的费用监管逻辑（必须先理解）

与许多司法辖区不同，VARA 的收费并非简单的“申请费 + 年费”，而是建立在以下监管逻辑之上：

费用与“监管资源消耗”挂钩
费用与“业务风险等级”挂钩
费用与“获批的虚拟资产活动数量”挂钩
费用具有持续性，而非一次性

换言之：

你给 VARA 带来的监管复杂度越高，持续监管成本越高，费用就越高。

5.2 VARA 费用的三大组成部分（监管口径）

在实务中，VARA 的费用通常可以拆解为三大类：

5.2.1 申请阶段费用（Application-related Fees）

适用阶段：

ATI（Approval to Incorporate）阶段
正式 VASP Licence 申请阶段

费用特点：

与申请活动类别相关
一经缴纳，通常不退
不保证一定获批

监管理解要点：

申请费用本质上是 “监管审查成本分摊”
即使申请最终被拒或终止，监管已投入资源，费用通常不返还

5.2.2 年度监管费用（Annual Supervision Fees）

这是 VARA 项目中最容易被低估的一部分

（1）费用性质

按年度收取
需提前缴纳
与每一项获准虚拟资产活动挂钩

（2）关键监管原则

若一家 VASP 获准 3 项虚拟资产活动
→ 需为 3 项活动分别缴纳年度监管费
年度监管费是 持牌有效性的前提条件之一

⚠️ 若未按期缴纳年度监管费，VARA 有权暂停或撤销牌照。

5.2.3 风险加价与特别监管费用（Risk-based Adjustments）

VARA 在法规中保留了高度裁量权，可根据以下因素调整监管费用：

客户类型（零售 vs 专业）
客户规模与资产体量
是否涉及 Custody
是否涉及 Lending / Leverage
历史合规记录
技术与运营复杂度

监管实务中，这部分费用并非“明码标价”，而是在审批或年度审查中由 VARA 直接提出。

5.3 官方费用表的理解方式（重要说明）

VARA 在其法规附表（Schedules）中列示了：

各类虚拟资产活动的
- 申请费
- 年度监管费

⚠️ 但需要特别注意：

这些金额 不是总成本
只是 最低法定监管收费
不包括：
- 资本金
- 审计
- 技术合规
- 保险
- 外包服务

合规预算 ≠ 官方费用表

5.4 VARA 的资本金监管哲学（非常关键）

5.4.1 VARA 是否有“固定最低注册资本”？

结论性回答：没有统一的固定数额。

VARA 并未规定：

“所有 VASP 必须至少缴足 XXX 迪拉姆的注册资本”

而是采用以下原则：

资本必须与业务规模、风险水平和活动类型相匹配

5.4.2 资本要求的法律基础

资本与财务稳健性要求主要体现在：

Company Rulebook
Risk & Prudential provisions
Licence Conditions（个案化）

监管关注的不是名义资本，而是：

是否能覆盖运营风险
是否能承担客户赔付责任
是否具备持续经营能力

5.5 不同虚拟资产活动的资本侧重点（实务总结）

以下为监管实践中常见的侧重点总结（非官方数值）：

5.5.1 Advisory / Broker-Dealer

资本要求相对较低
重点在于：
- 治理
- 合规
- 人员资质

5.5.2 Exchange

资本要求显著提高
需覆盖：
- 市场风险
- 技术风险
- 运营风险

5.5.3 Custody（最高敏感）

资本要求最严格
通常需额外：
- 保险
- 准备金
- 技术冗余

5.5.4 Lending & Borrowing

重点在于：
- 流动性风险
- 信用风险
- 杠杆管理

5.5.5 Management & Investment

类似资产管理逻辑
强调：
- 客户适当性
- 风险披露
- 投资限制

5.6 资本证明的形式（VARA 可接受）

VARA 在实务中可能接受以下资本或财务证明形式：

已缴足股本
银行存款证明
股东资金支持函（需真实性证明）
财务预测与现金流模型
保险或担保安排（补充性）

⚠️ 空壳公司 + 承诺式注资 ≠ 可接受资本

5.7 持续资本与财务监控义务

5.7.1 持续充足义务

资本必须在整个持牌期间持续维持
若出现资本侵蚀，需立即采取补救措施

5.7.2 监管汇报义务

定期提交财务报表
重大财务变化需即时通报
可能触发特别审查

5.8 常见误解与风险提示（非常重要）

常见误解	实际监管风险
“资本先放着，等批牌再补”	可能直接中止申请
“资本写高一点就好”	VARA 要求证据
“年度费用不重要”	可导致牌照失效
“找便宜架构省成本”	后期整改成本更高

5.9 本章交付级总结

VARA 的资金与费用体系不是“门槛”，而是“过滤器”。

监管的真正目的不是阻止进入，而是确保：

进入者具备长期经营能力
市场不会因资本不足而系统性失序
投资者与客户资产得到实质保护

第 6 章｜营销合规、市场推广与展业边界

Marketing, Promotion & Business Boundary Control（高风险章节｜交付版）

本章定位（请务必重视）
在 VARA 的监管实践中，营销违规的执法优先级不低于无证经营。
很多项目并非因业务不合规被否，而是在“尚未获牌或超范围获牌”的情况下进行宣传、推广或路演而直接触发监管风险。

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

6.1 VARA 对“营销（Marketing）”的监管态度（核心原则）

在 VARA 的监管框架下，“Marketing”被定义为：

任何形式的、直接或间接的、以招揽、推广、引导或影响客户参与虚拟资产业务为目的的沟通行为

这意味着，营销的外延远超传统理解的广告。

6.1.1 被视为“营销”的行为包括但不限于：

官方网站展示虚拟资产业务
App / 平台功能介绍
社交媒体发帖（LinkedIn、X、Telegram、Discord 等）
白皮书、项目说明书
路演 PPT、投资人介绍材料
新闻稿、媒体采访
KOL、代理、联盟营销
面向潜在客户的私下沟通（如 DM、邮件）

⚠️ 是否收费、是否成交、是否已有客户，不构成是否营销的判断标准。

6.2 “未获批准不得营销”的真实含义（实务解释）

6.2.1 VARA 的基本立场

在迪拜：

任何尚未获得 VARA 批准、许可或不反对确认的机构，不得就受规管虚拟资产活动进行营销。

这里的“批准”并不等同于：

正在申请中
已提交材料
已获得 ATI
已在海外持牌

⚠️ 只有在 VARA 明确允许的情况下，才能开展对应范围的营销。

6.2.2 ATI 阶段是否可以营销？

原则性答案：不可以。

ATI（Approval to Incorporate）阶段：

仅代表 VARA 对主体与方向的初步认可
不代表可对外开展业务或营销

在 ATI 阶段，允许的活动通常仅限于：

内部准备
技术开发
合规搭建
与银行/服务商对接

不包括：

对客户的任何招揽
对市场的任何宣传

6.3 营销合规的三大监管红线（必须写进制度）

红线一：无证或超范围营销

未持有 VARA VASP Licence
或已持牌但营销内容超出获准虚拟资产活动范围

均构成严重违规

红线二：误导性或不完整披露

VARA 明确禁止以下表述或暗示：

“保本”“零风险”“确定收益”
夸大监管背书
暗示 VARA、政府或王室认可
选择性披露收益、不披露风险

红线三：通过第三方规避监管

VARA 明确指出：

KOL、代理、联盟伙伴的营销行为，将被视为 VASP 自身的营销行为。

这意味着：

“不是我们发的，是 KOL 发的”
“代理自己乱说的”

不能构成免责理由。

6.4 营销审批与内控机制（交付级制度设计）

6.4.1 强制设立“营销合规审批流程”

建议在制度中明确：

所有营销材料必须事前审批
审批人至少包括：
- 合规官（CO）
- 法务 / 风险职能（如有）
审批结果需留痕并归档

6.4.2 建议设立的营销合规文件清单

《Marketing & Promotions Policy》
《Marketing Approval Workflow》
《Approved Risk Disclosure Library》
《Prohibited Statements List》
《KOL & Agent Management Policy》

6.5 不同渠道的合规要点（实务拆解）

6.5.1 官网与 App

首页必须清晰披露：
- 持牌状态
- 获准活动范围
- 监管机构名称
禁止展示未获准产品或功能

6.5.2 社交媒体

所有官方账号视为“营销渠道”
转发、点赞、评论也可能构成推广
建议设立 统一内容模板 + 禁止话题清单

6.5.3 白皮书与项目资料

白皮书被 VARA 视为高度敏感文件
必须：
- 完整披露风险
- 清晰区分“技术愿景”与“已获许可业务”

6.5.4 路演与私下沟通

面向潜在客户的 PPT / Deck 同样属于营销
不得以“仅供参考”“非公开材料”规避监管

6.6 KOL、代理与联盟营销的合规治理

6.6.1 合规责任不外包原则

VARA 的明确立场是：

营销责任不能通过外包、代理或合作方式转移。

因此，VASP 必须：

对第三方营销内容进行事前或实时监管
在合同中设置合规条款与处罚机制

6.6.2 建议合同条款要点（示例）

明确禁止误导性宣传
要求使用官方审批文案
赋予 VASP 即时下架权
违规即终止合作并追责

6.7 跨境营销与海外客户的特殊风险

6.7.1 海外持牌 ≠ 迪拜可营销

即便企业在以下地区持牌：

欧盟（MiCA / VASP）
英国（FCA）
新加坡（MAS）

也不能当然地在迪拜开展营销活动。

6.7.2 反向情形同样成立

在迪拜持 VARA 牌照：

并不当然允许向其他司法辖区营销
仍需遵守当地法律

6.8 违规后果（必须向董事会说明）

营销违规可能导致：

即时叫停业务
行政罚款
暂停或撤销牌照
被列入监管观察名单
对后续业务扩展产生长期负面影响

6.9 本章交付级总结

在 VARA 体系下，营销不是“配套行为”，而是“受监管活动的一部分”。

合规的营销不是“不宣传”，而是：

在获准范围内
使用真实、平衡、可核查的信息
在合规官监督下进行

第 7 章｜公司治理结构与“三道防线”体系

Corporate Governance & Three Lines of Defence（监管核心章节｜交付版）

本章定位（监管视角）
VARA 在审批过程中反复强调：
“虚拟资产风险的根源，不在技术，而在治理。”

因此，监管关注的并非公司规模或估值，而是：

谁在做决定

谁在监督风险

出问题时，谁承担责任

7.1 VARA 对公司治理的基本监管哲学

VARA 的公司治理要求并非照搬传统银行或证券监管，而是基于虚拟资产行业特性形成的责任导向型治理模式，其核心原则包括：

责任可追溯（Accountability）
职能相互制衡（Checks & Balances）
决策与执行分离（Oversight vs Execution）
治理与风险相匹配（Proportionality）

换言之：
你业务风险越高，治理要求越重；
你触碰客户资产越深，董事会责任越大。

7.2 董事会与最高治理层（Board-Level Responsibility）

7.2.1 董事会的监管定位

在 VARA 体系下，董事会并非象征性机构，而是：

公司合规与风险的最终责任主体
VARA 问责的第一顺位对象

即便日常管理已授权给 CEO / 管理层，董事会仍需对以下事项承担不可转移的责任：

公司整体合规状态
风险管理框架的有效性
客户资产保护安排
重大违规或事件的处置

7.2.2 董事会必须履行的核心职责（制度级）

建议在《Board Charter》中明确以下职责：

批准并定期审阅：
- 公司战略
- 风险偏好声明（Risk Appetite Statement）
任命并监督：
- CEO / General Manager
- 合规官（CO）
- MLRO
确保：
- 三道防线有效运行
- 关键职能具备独立性
审阅并批准：
- 年度合规报告
- 重大风险事件处置方案

7.2.3 董事会会议与留痕要求

VARA 关注的不仅是“是否召开会议”，而是：

是否有 实质讨论
是否有 风险议题
是否有 跟进与整改闭环

建议最低标准（实务参考）：

董事会会议：至少 每季度一次
合规/风险专题议题：至少 每半年一次
会议记录：
- 明确记录决议
- 明确责任人
- 明确时间节点

7.3 董事会下设委员会（Board Committees）

7.3.1 是否必须设立委员会？

VARA 并未强制规定所有 VASP 必须设立多个委员会，但在以下情形下，强烈预期设立专门委员会：

涉及 Custody
涉及 Exchange
涉及 Lending / Leverage
面向零售客户

7.3.2 常见委员会设置（交付建议）

（一）风险与合规委员会（Risk & Compliance Committee）

审阅风险评估
监督 AML/CFT
监督合规官与 MLRO 工作

（二）审计委员会（Audit Committee）

对接外部审计
审阅财务报表
监督内控缺陷整改

（三）技术与信息安全委员会（如适用）

监督系统安全
审阅重大技术变更
监督外包技术风险

7.3.3 委员会治理文件要求

每一委员会建议具备：

Committee Charter
明确的职责范围
定期会议与记录

7.4 高级管理层（Senior Management）的角色

7.4.1 管理层的监管定位

在 VARA 框架下：

管理层是第一道防线的负责人
对业务行为承担直接责任

典型管理层角色包括：

CEO / General Manager
COO
CTO（或技术负责人）

7.4.2 CEO / General Manager 的特别责任

VARA 通常要求 CEO / GM：

对公司整体运营具有充分控制权
能清晰解释商业模式、风险点与缓释措施
在监管沟通中承担主要发言角色

⚠️ “名义 CEO、实控在他处”的结构，
是 VARA 审查中的重大负面因素。

7.5 “三道防线”体系（Three Lines of Defence）

7.5.1 第一防线：业务与运营（Business & Operations）

责任主体：

各业务部门负责人
产品负责人
运营团队

核心职责：

在日常经营中识别风险
按制度执行 KYC、交易监控
对异常情况进行初步处置

第一防线不是“合规的执行者”，
而是“风险的第一发现者”。

7.5.2 第二防线：合规、风险与 AML 职能

责任主体：

Compliance Officer
MLRO
Risk Officer（或等同职能）

核心职责：

制定并维护政策制度
独立于业务线
对第一防线进行监督与挑战

监管重点：

是否具备否决权或升级权
是否能直接向董事会汇报

7.5.3 第三防线：内部审计 / 独立审查

责任主体：

内部审计职能
或经批准的外部审计/审查方

核心职责：

独立评估前两道防线的有效性
出具审计报告
跟踪整改落实

⚠️ 即便内审外包，
责任仍在董事会，不在供应商。

7.6 合规官（Compliance Officer）的独立性要求

7.6.1 合规官的监管地位

在 VARA 体系下，合规官必须：

在组织结构中具备独立性
不得向业务线汇报
可直接向董事会或委员会汇报

7.6.2 合规官的核心职责（制度化表述）

维护合规手册
监督营销合规
监管变更跟踪
员工培训
与 VARA 的日常沟通

7.7 MLRO 的特殊责任与独立性

7.7.1 MLRO 的独立地位

MLRO 不应：

兼任销售或业务拓展角色
受业绩指标影响

7.7.2 MLRO 的关键监管职责

审阅 STR
决定是否向监管机构报告
维护 AML/CFT 制度

7.8 治理文件清单（交付级）

建议至少准备以下文件：

Board Charter
Committee Charters
Organisation Chart
Delegation of Authority
Three Lines of Defence Framework
Compliance Policy
AML/CFT Policy

7.9 常见治理失败点（监管经验总结）

情形	VARA 典型反应
董事会无实权	要求重构治理
合规官隶属业务	要求调整汇报线
MLRO 兼职销售	直接否决
无会议记录	视为治理缺失

7.10 本章交付级总结

在 VARA 体系下，公司治理不是“形式合规”，而是“责任工程”。

一个通过 VARA 审批的 VASP，必须做到：

决策有人
监督有人
出事有人负责

第 8 章｜关键岗位设置、人员资质与适当人选（Fit & Proper）

Key Roles, Competence & Fitness Requirements（高否决风险章节｜交付版）

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

本章定位（监管视角）
VARA 在多次公开与非公开沟通中反复强调：
“我们发牌照给人，而不仅是给公司。”

在 VARA 的审批逻辑中：

业务模式可以修改

系统可以重建

但关键人员不合适，项目不可补救

8.1 VARA 的“适当人选（Fit & Proper）”监管哲学

VARA 对关键人员的评估并非简单背景核查，而是一个多维度、持续性的适当性判断，核心关注以下四个维度：

诚信与品格（Integrity）
能力与经验（Competence & Experience）
时间投入与责任承担（Capacity & Commitment）
独立性与利益冲突管理（Independence & Conflicts）

该评估并非一次性完成，
而是在整个持牌期间持续有效。

8.2 VARA 重点关注的“关键岗位”范围

在 VARA 监管语境中，以下人员通常被认定为 Key Individuals / Key Management Personnel：

董事（Directors）
CEO / General Manager
Compliance Officer（CO）
Money Laundering Reporting Officer（MLRO）
Risk Officer（或等同职能）
技术负责人（CTO / IT Security Lead，如适用）

⚠️ 并非所有岗位都要求全职，但所有岗位都要求“可履职、可问责”。

8.3 董事（Directors）的适当性要求

8.3.1 董事的监管定位

在 VARA 体系下，董事被视为：

公司治理与合规的最终责任人
监管问责的首要对象

因此，董事并非“挂名角色”。

8.3.2 VARA 对董事的核心审查点

VARA 通常重点关注以下方面：

是否具备金融、科技、合规或相关管理经验
是否理解虚拟资产行业的核心风险
是否具备独立判断能力
是否能投入足够时间履职

⚠️ “一人多董事、长期不在岗”的结构，属于明显负面信号。

8.3.3 董事常见否决情形（经验总结）

情形	VARA 风险判断
董事对业务不了解	不适当
长期居住地不明	风险
多家 VASP 董事	潜在冲突
无会议参与记录	治理失效

8.4 CEO / General Manager 的资质要求（重点）

8.4.1 CEO 的监管地位

在 VARA 审批中，CEO / GM 通常被视为：

第一责任人
监管面谈的核心对象
业务、合规与风险的“交汇点”

8.4.2 VARA 对 CEO 的核心期待

VARA 期望 CEO：

能清晰、逻辑自洽地解释：
- 商业模式
- 风险来源
- 合规安排
理解并支持合规与风控职能
在公司内具备实质管理权

⚠️ “名义 CEO + 实控人幕后决策”的模式，极易被识别并否决。

8.4.3 CEO 常见审查问题（面谈方向）

公司最核心的三项风险是什么？
客户资产如何保护？
出现重大违规谁负责？
合规官是否有否决权？

8.5 合规官（Compliance Officer, CO）

8.5.1 合规官的独立性要求

VARA 明确要求：

合规官 不得隶属于业务部门
合规官 不得以业务指标考核
合规官 具备直接向董事会汇报的权利

8.5.2 合规官的能力要求

合规官应至少具备：

金融监管或合规相关经验
对虚拟资产监管框架的理解
制度制定与执行能力

并非强制要求持牌律师或会计师，但必须“懂监管、能落地”。

8.5.3 合规官常见否决点

情形	VARA 反应
兼职销售	直接否决
无独立汇报线	要求整改
不熟悉业务	延期审批

8.6 MLRO（反洗钱报告官）

8.6.1 MLRO 的监管特殊性

MLRO 在 VARA 体系中具备法定地位，其职责具有不可转移性。

VARA 关注 MLRO 是否：

能独立判断可疑交易
能不受商业压力影响
熟悉虚拟资产洗钱风险

8.6.2 MLRO 的核心职责（制度化）

审阅交易监控报告
决定是否提交 STR
维护 AML/CFT 制度
与监管机构沟通

8.6.3 MLRO 的兼职限制

强烈不建议 MLRO 同时担任：

销售
市场推广
客户关系管理

⚠️ MLRO 兼任业务职能，是 VARA 否决的高频原因。

8.7 风险管理职能（Risk Officer）

8.7.1 是否必须设立 Risk Officer？

VARA 未强制所有 VASP 设立独立 Risk Officer，但在以下情形下强烈预期：

Exchange
Custody
Lending & Borrowing
面向零售客户

8.7.2 风险职能的核心职责

风险识别与评估
风险限额与监控
压力测试
风险报告

8.8 技术负责人（CTO / IT Security）

8.8.1 技术负责人在 VARA 审批中的角色

VARA 会评估：

技术是否“可控”
是否存在单点故障
是否具备安全治理能力

8.8.2 技术负责人常见关注点

私钥管理
权限分层
灾备方案
外包技术治理

8.9 人员兼职、外包与集团共享（敏感问题）

8.9.1 兼职的可接受性

可以兼职，但必须可履职
必须披露所有外部职务
不得影响独立性

8.9.2 外包职能的监管立场

可外包（如 IT、内审）
责任不可外包
董事会仍需承担最终责任

8.10 人员适当性文件清单（交付级）

建议至少准备：

CV（详细）
身份与背景声明
犯罪与监管记录声明
职责说明（JD）
时间投入承诺书
利益冲突声明

8.11 常见失败案例总结（非常重要）

场景	结果
MLRO 不懂链上风险	延期或否决
CEO 说不清业务	高风险
合规官无实权	要求重构
人员频繁更换	严重负面

8.12 本章交付级总结

在 VARA 体系下，人员不是“资源”，而是“监管对象”。

一个成功的 VARA 项目，必须做到：

人选真实
职责清晰
权责匹配
可被持续监管

第 9 章｜AML/CFT 体系、风险评估与可疑交易报告（STR）

Anti-Money Laundering & Counter-Terrorist Financing Framework（深度实务版）

本章定位（监管视角）
VARA 明确将 AML/CFT 视为虚拟资产监管的核心支柱。

在审批中，VARA 重点不是“你有没有 AML 文件”，而是：

你的 AML 是否针对虚拟资产风险定制

是否能覆盖链上与链下风险

是否能真正运行并产出 STR

9.1 VARA AML/CFT 的法律与监管基础

VARA 的 AML/CFT 要求并非孤立存在，而是建立在以下三层框架之上：

UAE 联邦层面的 AML/CFT 法律与制裁制度
VARA 的虚拟资产专项监管规则与 Rulebooks
FATF（金融行动特别工作组）标准及其对 VASP 的解释性指引

对申请人而言，这意味着：
最低标准 = FATF；
实操标准 = VARA 的解释与执法口径。

9.2 风险为本方法（Risk-Based Approach, RBA）

9.2.1 VARA 对 RBA 的基本要求

VARA 明确要求 VASP 采用 风险为本方法，并在制度与实践中体现：

不同客户 ≠ 相同风险
不同产品 ≠ 相同控制
不同交易 ≠ 相同监控强度

“一刀切 AML” 在 VARA 体系中被视为合规失败。

9.2.2 必须完成的风险评估层级

在实务中，VARA 期望至少完成以下 四层风险评估：

企业级风险评估（Enterprise-Wide Risk Assessment, EWRA）
客户风险评估（Customer Risk Assessment）
产品 / 服务风险评估
地域与交易渠道风险评估

9.3 企业级风险评估（EWRA）

9.3.1 EWRA 的目的

EWRA 用于回答监管的一个核心问题：

“这家公司整体的洗钱与恐怖融资风险画像是什么？”

9.3.2 EWRA 需覆盖的核心维度

建议至少涵盖以下维度并形成书面报告：

业务模式风险（Exchange / Custody / Lending 等）
客户类型风险（零售 / 专业 / 机构）
地域风险（高风险司法辖区、制裁国家）
技术风险（匿名性、混币、跨链）
外包与第三方风险

9.3.3 EWRA 的监管要求

必须由 第二道防线（合规 / 风险）主导
需 董事会审阅并批准
至少 每年更新一次，或在重大变化时更新

9.4 客户尽职调查（CDD / EDD）

9.4.1 客户尽调的监管原则

VARA 要求：

在建立业务关系前完成 CDD
风险越高，尽调越深
持续监控，而非一次性核查

9.4.2 标准尽调（CDD）的基本要素

CDD 至少应包括：

客户身份识别与验证
实益所有人（UBO）识别
客户目的与业务性质了解
初始风险评级

9.4.3 强化尽调（EDD）的触发情形

以下情况通常触发 EDD：

高风险国家或地区
政治公众人物（PEP）
复杂或不透明结构
异常交易模式

EDD 措施可包括：

额外身份文件
资金来源（SoF）
财富来源（SoW）
高级管理层批准

9.5 虚拟资产特有的 AML 风险（重点）

9.5.1 链上匿名性与可追踪性并存

VARA 明确认识到：

区块链具备可追溯性
但通过混币、隐私工具可显著降低透明度

因此，VASP 必须：

具备 链上分析能力
能识别高风险地址、服务与模式

9.5.2 重点关注的链上风险场景

混币 / 隐私协议
跨链桥
DeFi 高风险池
被盗资金流转
制裁名单地址

9.6 交易监控体系（Transaction Monitoring）

9.6.1 监控覆盖范围

交易监控应覆盖：

链上交易
链下账户活动
法币出入金（如适用）

9.6.2 监控规则的监管期望

VARA 期望监控规则：

与业务模式匹配
可解释、可调整
有阈值与例外管理

“只部署工具、不设规则” ≠ 合规

9.7 可疑交易报告（STR）机制

9.7.1 STR 的核心监管逻辑

STR 的判断标准不是：

是否已确认违法
而是：
是否存在合理怀疑

9.7.2 STR 的内部流程（交付级）

建议制度中明确以下流程：

异常交易由系统或员工识别
升级至合规 / MLRO
MLRO 独立评估
决定是否提交 STR
留痕与保密

9.7.3 STR 的独立性与保密性

MLRO 不得受业务压力影响
提交 STR 的事实本身不得向客户披露（Tipping-off 禁止）

9.8 制裁合规（Sanctions Compliance）

9.8.1 制裁筛查要求

VASP 必须：

对客户、交易对手、地址进行制裁筛查
覆盖联合国及 UAE 适用制裁名单

9.8.2 命中制裁的处理

立即冻结相关交易或资产
及时向监管机构报告
保留完整记录

9.9 记录保存与审计

9.9.1 记录保存要求

AML/CFT 相关记录应：

完整
可追溯
在监管要求期限内保存

9.9.2 审计与独立测试

定期进行 AML/CFT 独立测试
审计发现需形成整改闭环

9.10 常见 AML 失败点（监管经验）

失败情形	VARA 反应
套用传统银行 AML	要求重写
无链上监控能力	否决或整改
MLRO 无独立性	严重负面
STR 从未提交	高风险信号

9.11 本章交付级总结

在 VARA 体系下，AML/CFT 不是合规成本，而是经营能力的一部分。

一个合格的 VASP 必须能够证明：

能识别风险
能监控交易
能在必要时向监管“说不”

第 10 章｜Travel Rule、虚拟资产转移与结算合规

Travel Rule, Transfer & Settlement Compliance Framework（深度实务版）

本章定位（监管视角）
在 VARA 体系中，Travel Rule 不只是 AML 的一个子模块，而是：

跨境合规能力的“硬指标”

技术与合规协同的试金石

VARA 通过 Travel Rule 判断一家 VASP 是否：

真正理解虚拟资产跨境风险

具备与其他 VASP 合作与对接的能力

能在高压场景下保持合规一致性

10.1 Travel Rule 的法律与监管背景（必须理解）

10.1.1 Travel Rule 的国际背景

Travel Rule 源自 FATF Recommendation 16，并被明确适用于 Virtual Asset Service Providers (VASPs)，其核心要求是：

在虚拟资产转移过程中，发送方与接收方的关键信息必须“随交易一同传递”，并可被监管机构获取。

10.1.2 VARA 对 Travel Rule 的态度

VARA 并未将 Travel Rule 视为“未来义务”，而是：

即刻适用
与 AML/CFT 同等重要
适用于链上与链下转移

⚠️ 任何声称“尚未实施 Travel Rule”的 VASP，
在 VARA 审批中都将被视为高风险或准备不足。

10.2 Travel Rule 的适用范围（VARA 口径）

10.2.1 哪些活动必须适用 Travel Rule？

在 VARA 监管框架下，Travel Rule 通常适用于：

Exchange（出入金、内部转账）
Transfer & Settlement
Custody（代客户发起转移）
Broker-Dealer（代表客户执行转移）

10.2.2 哪些场景可能被视为“低适用性”（但非豁免）

以下场景并非自动豁免，仅可能在风险评估后适用差异化控制：

自托管钱包（Unhosted Wallet）
低金额交易
内部系统转移（同一 VASP 内）

⚠️ VARA 关注的是：
你是否评估并控制了风险，而不是你是否“认为不适用”。

10.3 Travel Rule 的核心信息要素（实务层面）

10.3.1 发送方信息（Originator）

通常包括：

客户姓名
账户或钱包标识
地址或其他识别信息
官方身份编号（视风险）

10.3.2 接收方信息（Beneficiary）

通常包括：

接收方姓名
接收方账户或钱包地址

10.3.3 信息质量要求

VARA 关注的不是“是否收集”，而是：

信息是否准确
是否 可验证
是否 可在监管要求下提供

10.4 技术实现路径（VARA 的实务期待）

10.4.1 技术实现的基本原则

VARA 并未指定唯一技术方案，但强调以下原则：

信息可传递
信息可接收
信息可保存与调取
信息安全与隐私保护

10.4.2 常见技术路径（示例）

使用 Travel Rule Protocol（TRP）
与第三方 Travel Rule 服务商对接
双边或多边 VASP 信息交换机制

⚠️ “我们未来会接入” ≠ 合规
VARA 期望看到已实施或可立即启用的方案。

10.5 与非托管钱包（Unhosted Wallet）的交互

10.5.1 VARA 的监管立场

VARA 并未禁止与非托管钱包交互，但要求：

进行强化风险评估
采取额外控制措施

10.5.2 常见控制措施（实务示例）

钱包所有权声明
地址验证
交易限额
强化交易监控

10.6 Travel Rule 与 AML / STR 的衔接

10.6.1 数据一致性要求

VARA 期望：

Travel Rule 数据
CDD 数据
交易监控数据

三者之间 逻辑一致、可交叉验证。

10.6.2 Travel Rule 触发 STR 的情形

以下情况可能触发 STR 评估：

对手方拒绝提供信息
信息明显不一致
高频或结构性拆分交易
与高风险司法辖区相关

10.7 记录保存与审计要求

10.7.1 记录保存

Travel Rule 相关记录必须：

与交易记录关联
可按客户、时间、金额检索
在法定期限内保存

10.7.2 审计与测试

VARA 可能要求：

技术测试报告
抽样交易核查
第三方独立审查

10.8 常见失败点（监管实务总结）

失败情形	VARA 典型反应
未实施 Travel Rule	直接否决
技术方案不可运行	要求重构
与海外 VASP 无法对接	高风险
数据与 AML 不一致	重点审查

10.9 本章交付级总结

Travel Rule 是 VARA 判断 VASP 是否“国际化合规”的核心标志。

一个合格的 VASP 应能证明：

能跨 VASP、跨司法辖区协作
能在技术与合规之间形成闭环
能在压力场景下保持监管一致性

第 11 章｜客户资产保护、托管结构与资产隔离

Client Asset Protection, Custody Architecture & Segregation（核心强监管章节｜交付版）

本章定位（监管视角）
VARA 对客户资产保护的态度可以概括为一句话：
“任何无法在破产或事故中清晰区分‘谁的钱是谁的’的结构，都是不可接受的。”

因此，VARA 并不只审查“是否托管”，而是系统性审查资产控制、法律归属、技术权限、治理独立性与破产隔离。

11.1 VARA 对 Custody 的核心监管立场（必须先理解）

11.1.1 Custody 是“最高风险活动”

在 VARA 的 8 类虚拟资产活动中：

Custody（托管）被认定为最高风险类别
监管要求 显著高于 Exchange / Broker-Dealer / Advisory

原因在于：

Custody 直接接触客户资产
Custody 一旦失控，损失不可逆
Custody 失败会产生系统性风险

11.1.2 Custody 的“强制独立原则”（Absolute Separation）

VARA 的明确立场是：

任何从事 Custody 的实体，必须是独立法律实体，并持有独立的 Custody 牌照。

这意味着：

Custody 不能与 Exchange、Broker-Dealer、Lending 混在同一法律实体
即便同属一个集团，也必须：
- 法律独立
- 治理独立
- 资金与技术权限独立

⚠️ “同集团但不同部门”≠合规

11.2 Custody 与非 Custody 的边界界定（实务关键）

11.2.1 哪些行为会被认定为 Custody？

以下任一情形通常会触发 Custody 认定：

持有客户私钥或其组成部分
能单独或联合控制客户资产转移
为客户生成、管理或恢复私钥
为客户保管资产并承诺安全性

11.2.2 常见“误判为非 Custody”的情形

表面说法	VARA 实际判断
我们只是技术钱包	若控制私钥 → Custody
客户同意托管	同意不改变监管定性
我们不动资产	只要能动 → Custody
用 MPC 就不是托管	MPC 仍是 Custody

11.3 客户资产的法律归属与破产隔离（Legal Segregation）

11.3.1 法律归属的基本要求

VARA 要求 VASP 明确并证明：

客户资产 始终属于客户
不构成 VASP 的资产或负债
不可用于：
- 自营交易
- 抵押融资
- 偿还公司债务

11.3.2 破产隔离（Insolvency Protection）

在破产或清算情形下，必须能够证明：

客户资产 不进入破产财产池
债权人 无权追索客户资产

⚠️ VARA 极其关注：
“如果公司倒闭，客户的钱会发生什么？”

11.4 客户资产隔离的操作层面（Operational Segregation）

11.4.1 账面隔离（Accounting Segregation）

客户资产与公司资产分账核算
不得混用账户或钱包
定期对账并留痕

11.4.2 钱包隔离（Wallet Segregation）

常见合规做法包括：

客户资产钱包
公司自有资产钱包
手续费收入钱包

并明确：

钱包用途
钱包权限
资金流向规则

11.5 私钥管理与钱包架构（Technical Custody Controls）

11.5.1 私钥治理的监管关注点

VARA 关注的不只是“用什么技术”，而是：

谁能生成私钥
谁能使用私钥
谁能恢复私钥
谁在什么条件下能批准交易

11.5.2 常见钱包技术架构（示例）

冷钱包（Cold Storage）
热钱包（Hot Wallet）
MPC（Multi-Party Computation）

⚠️ 技术选型本身不决定合规性，治理设计才决定。

11.5.3 权限分层与多重控制

VARA 期望看到：

多签 / 多角色审批
权限最小化原则
关键操作需双重或多重授权

11.6 客户资产保险、准备金与风险缓释

11.6.1 是否必须购买保险？

VARA 未统一强制所有 Custody 必须购买保险，但在实务中：

对大型 Custodian
或面向零售客户

强烈预期存在以下任一或组合：

第三方保险
内部准备金
风险基金

11.6.2 保险与准备金的监管逻辑

监管关注的不是“买没买保险”，而是：

是否能覆盖主要风险
保险是否真实可执行
是否存在免责或重大除外条款

11.7 第三方托管与外包（Outsourced Custody）

11.7.1 是否可以外包托管？

原则上可以，但前提是：

第三方本身具备合规能力
VASP 对第三方具备监督与审计权
客户已被充分告知

11.7.2 外包不等于责任转移

VARA 的立场非常明确：

Custody 可以外包，但责任不可外包。

董事会与管理层仍需承担最终责任。

11.8 定期对账、审计与证明机制

11.8.1 对账要求

定期进行客户资产对账
识别并调查任何差异
对账结果需留痕并可审计

11.8.2 审计与独立验证

VARA 可能要求：

客户资产专项审计
钱包余额证明
私钥治理独立审查

11.9 Custody 常见失败结构（监管经验）

结构问题	VARA 反应
托管与交易同一实体	要求拆分
私钥权限集中	要求重构
客户资产可被挪用	直接否决
无破产隔离说明	不接受

11.10 本章交付级总结

Custody 在 VARA 体系中不是“功能模块”，而是“信任工程”。

一个可被 VARA 接受的 Custody 架构，必须做到：

法律上隔离
账面上隔离
技术上隔离
治理上隔离

第 12 章｜技术系统、信息安全与网络韧性

Technology, Information Security & Cyber Resilience（交付级深度版）

本章定位（监管视角）
VARA 并不要求 VASP“技术最先进”，但明确要求：
技术必须可控、可审计、可恢复、可持续。

监管关注的不是代码写得多漂亮，而是：

出问题能否被发现

出问题能否被控制

出问题能否被恢复

出问题谁来负责

12.1 VARA 对技术与信息安全的监管哲学

VARA 对技术与网络安全的核心监管理念可总结为四点：

技术即风险源：系统缺陷本身就是重大合规风险
安全是治理问题，不只是 IT 问题
预防优于补救，演练优于承诺
外包不等于免责

因此，技术与信息安全并非“后台模块”，而是董事会与高级管理层的责任事项。

12.2 技术治理与组织责任（IT Governance）

12.2.1 技术治理的组织结构要求

VARA 期望 VASP 明确并文件化以下内容：

技术职能的汇报线
技术负责人（CTO / IT Lead）的职责
技术与合规、风险之间的协作机制

在实务中，VARA 通常关注：

技术负责人是否具备决策权
是否能独立提出安全风险
是否能向管理层/董事会升级问题

12.2.2 技术治理文件（最低清单）

建议至少准备并持续维护：

IT Governance Policy
Information Security Policy
Change Management Policy
Access Control Policy
Incident Management Policy

12.3 系统架构设计与可审计性（System Architecture）

12.3.1 架构透明度要求

VARA 并不要求公开源代码，但明确要求：

提供 系统架构图（逻辑层 + 物理层）
说明关键模块之间的交互
明确数据流向与控制点

12.3.2 重点审查的系统模块

在 VARA 审查中，以下模块通常被重点关注：

用户账户系统
钱包与私钥管理系统
交易撮合与清算系统
风控与监控系统
日志与审计系统

12.3.3 可审计性（Auditability）

VARA 期望系统具备：

完整日志记录
操作可追溯
日志不可篡改
可按监管要求导出

“无法被审计的系统 = 不可被监管的系统”。

12.4 访问控制与权限管理（Access Control）

12.4.1 最小权限原则（Least Privilege）

VARA 关注是否落实：

角色分级
职责分离
临时权限审批与回收

12.4.2 高风险权限的特别控制

以下权限通常被视为 关键权限：

私钥访问
钱包转账审批
系统参数修改
日志删除

对上述权限，VARA 期望：

多人审批
双重验证
全程留痕

12.5 网络安全与防御措施（Cybersecurity Controls）

12.5.1 基础安全控制

VARA 期望至少实施以下基础控制：

防火墙与网络分段
加密（传输中与静态数据）
多因素认证（MFA）
安全补丁管理

12.5.2 渗透测试与漏洞管理

在审批与持续监管中，VARA 通常要求：

定期渗透测试（Penetration Testing）
漏洞评估（Vulnerability Assessment）
漏洞修复与验证记录

⚠️ 一次性测试 ≠ 合规
VARA 关注的是“持续安全管理能力”。

12.6 事件管理与网络安全事故响应

12.6.1 事件分类与响应机制

VASP 应建立明确的：

事件分级标准（Critical / High / Medium / Low）
响应流程
升级路径

12.6.2 重大安全事件的监管义务

在发生以下情形时，VARA 预期：

系统被入侵
客户资产风险
大规模服务中断

VASP 应：

立即采取控制措施
在规定时间内通知监管机构
提交事件分析与整改报告

12.7 业务连续性与灾难恢复（BCP / DR）

12.7.1 VARA 对 BCP/DR 的核心关注点

VARA 在审查 BCP/DR 时，重点不是文档长度，而是：

是否现实可行
是否与业务规模匹配
是否定期演练

12.7.2 关键指标（示例）

RTO（恢复时间目标）
RPO（恢复点目标）

这些指标需：

明确
与业务风险匹配
经管理层批准

12.7.3 演练与测试

VARA 强烈期望：

至少年度 BCP/DR 演练
演练结果记录
演练后的改进措施

12.8 云服务与第三方技术服务（Cloud & Third-Party IT）

12.8.1 使用云服务的监管立场

VARA 允许使用云服务，但要求：

明确数据所在地
明确访问与控制权
合同中包含审计与监管访问条款

12.8.2 第三方技术风险管理

VASP 应：

对第三方进行尽调
定期评估其安全能力
设定退出与替代方案

12.9 数据保护与隐私（Data Protection）

12.9.1 客户数据保护要求

VARA 要求：

客户数据仅用于合法目的
防止未授权访问
防止数据泄露或滥用

12.9.2 数据生命周期管理

应覆盖：

数据收集
数据存储
数据使用
数据销毁

12.10 常见技术失败点（监管经验总结）

技术问题	VARA 典型反应
架构描述不清	要求补件
无日志或日志不可审计	高风险
无 BCP/DR 演练	不接受
权限集中	要求重构

12.11 本章交付级总结

在 VARA 体系下，技术不是“成本中心”，而是“合规基础设施”。

一个可被 VARA 接受的技术体系，应当能够证明：

系统可被理解
风险可被控制
事故可被恢复
责任可被追溯

第 13 章｜外包管理、第三方风险与供应链治理

Outsourcing, Third-Party Risk & Supply Chain Governance（监管穿透章节｜交付版）

本章定位（监管视角）
VARA 的立场非常明确：
“你可以外包服务，但你不能外包责任。”

因此，监管关注的不是“你有没有外包”，而是：

外包了什么

为什么外包

谁在监督

出问题时你是否仍能控制局面

13.1 VARA 对外包的总体监管立场

13.1.1 外包是“被允许的”，但不是“自由的”

VARA 允许 VASP 在合理范围内外包部分职能，以支持业务效率和专业化，但前提是：

外包 不削弱监管目标
外包 不影响客户资产与数据安全
外包 不导致责任不清或问责断层

13.1.2 VARA 的三项核心外包原则

可控性（Control）
VASP 必须始终对外包活动保有实质控制权
可监督性（Oversight）
必须能持续监督、评估并审计外包方
可替代性（Substitutability）
外包方失效时，业务可平稳迁移或中断受控

13.2 可外包与不可外包的监管边界（极其关键）

13.2.1 原则上可外包的职能（示例）

在 VARA 监管实践中，以下职能通常可以外包，但需满足严格条件：

IT 基础设施与云服务
网络安全监测与渗透测试
内部审计（第三道防线）
客服支持（非决策性）
部分合规支持（非最终判断）

13.2.2 原则上不可外包的核心责任

以下责任 不得外包或转移：

董事会的最终治理责任
合规判断的最终决定权
MLRO 是否提交 STR 的决定
客户资产控制权（如 Custody）

⚠️ 即便操作层面外包，决策权也必须留在持牌实体内。

13.3 第三方风险分类与分级管理

13.3.1 VARA 期望的第三方分类方法

VARA 期望 VASP 对第三方进行风险分级管理，而非“一视同仁”。
实务中常见的分类包括：

关键外包方（Critical Service Providers）
重要外包方（Material Service Providers）
一般服务提供方（Non-Material Providers）

13.3.2 “关键外包方”的典型示例

核心交易系统提供商
钱包 / 私钥管理技术提供商
云服务基础设施商
托管服务提供方

对上述第三方，VARA 通常要求最高级别的尽调与监督。

13.4 第三方尽职调查（Third-Party Due Diligence）

13.4.1 尽调的基本目标

第三方尽调的目的不是“形式合规”，而是回答以下问题：

该第三方是否 具备能力
是否 具备合规意识
是否 具备财务与运营稳定性
是否 愿意接受监管穿透与审计

13.4.2 尽调的核心维度（交付级）

建议至少覆盖以下方面：

公司背景与所有权结构
技术与运营能力
信息安全与数据保护措施
合规与监管历史
财务稳健性
分包与再外包安排

13.5 外包合同的监管关键条款（必须写清）

13.5.1 VARA 强烈关注的合同条款

在外包协议中，VARA 通常重点审查是否包含以下条款：

监管访问权（Regulatory Access Right）
审计权（Audit Right）
数据所有权与保密条款
服务中断与应急安排
终止与退出机制

13.5.2 监管穿透与审计权

合同中应明确：

VARA 有权（直接或通过 VASP）
- 访问相关记录
- 审查外包活动
外包方不得以保密或商业理由拒绝

13.6 外包后的持续监督与绩效管理

13.6.1 持续监督的必要性

VARA 明确反对“签完合同就不管”的做法。
VASP 应建立：

定期评估机制
KPI / SLA 监控
风险与事件报告渠道

13.6.2 定期审查与报告

对关键外包方，建议：

至少年度全面评估
评估结果提交管理层或董事会
必要时调整或终止合作

13.7 再外包（Sub-outsourcing）的监管关注点

13.7.1 再外包的透明度要求

VARA 关注：

是否存在未经披露的再外包
再外包是否引入新的风险司法辖区
再外包是否削弱原有控制

13.7.2 再外包的控制措施

合同中需明确是否允许再外包
再外包需事先审批
再外包方需接受同等尽调与监督

13.8 外包失效与应急退出计划（Exit Strategy）

13.8.1 为何 Exit Strategy 是监管重点

VARA 的核心问题是：

“如果这个第三方明天倒闭，你怎么办？”

13.8.2 Exit Strategy 的关键要素

应至少包括：

业务迁移方案
数据与系统交接安排
客户沟通预案
临时替代方案

13.9 外包相关的记录保存与审计

13.9.1 必须保存的记录

尽调报告
合同文本
评估与审查记录
事件与整改记录

13.9.2 审计与监管检查

VARA 可要求：

提供外包管理全套文件
解释外包决策逻辑
说明监督与控制措施

13.10 常见外包失败点（监管经验总结）

失败情形	VARA 反应
核心系统完全外包且无控制	高风险
合同无审计权	不接受
再外包不披露	严重负面
无退出计划	要求重构

13.11 本章交付级总结

在 VARA 体系下，外包不是风险转移工具，而是风险放大器。

一个可被 VARA 接受的外包与第三方治理体系，必须做到：

风险看得见
权责说得清
出事兜得住
随时能“拔插”

第 14 章｜市场行为、营销推广与客户适当性

Conduct of Business, Marketing & Client Suitability（强消费者保护章节｜交付版）

本章定位（监管视角）
VARA 的一项明确监管目标是：
“虚拟资产不得以复杂性或创新之名，规避对客户的公平对待义务。”

因此，VARA 对市场行为的监管强度，不低于传统证券监管，在零售客户场景下甚至更为严格。

14.1 VARA 对 Conduct of Business 的基本监管原则

VARA 要求所有 VASP 在对外行为中遵循以下基本原则：

公平（Fairness）
透明（Transparency）
不误导（No Misleading Conduct）
以客户利益为先（Client Interest First）

⚠️ “客户已同意 / 客户自担风险”
不能作为不公平行为的免责理由。

14.2 客户分类与分层管理（Client Categorisation）

14.2.1 客户分类的重要性

VARA 并不允许所有客户被“同等对待”。
相反，监管要求 基于客户能力、经验与风险承受能力进行分层。

14.2.2 常见客户分类（实务参考）

在 VARA 实务中，常见分类包括：

零售客户（Retail Clients）
专业客户（Professional Clients）
机构客户（Institutional Clients）

⚠️ 是否允许某一类客户参与某项业务，
取决于你的牌照活动类型与内部控制能力。

14.2.3 专业客户的认定要求

VARA 关注的不是“客户自称专业”，而是：

是否具备足够资产规模
是否具备相关投资经验
是否理解产品风险

专业客户认定应：

有明确标准
有书面证明
可被监管复核

14.3 产品与服务的适当性评估（Suitability Assessment）

14.3.1 适当性义务的核心问题

VARA 要求 VASP 在提供产品或服务前回答：

“这个客户，是否适合这个产品？”

而不是：

“这个产品是否合法？”

14.3.2 适当性评估应涵盖的要素

适当性评估通常应包括：

客户的投资经验
财务状况与风险承受能力
投资目标
对虚拟资产的理解程度

14.3.3 不适当情形的处理

若评估结果显示产品或服务不适合客户：

不得推荐
或需明确风险警示
并保留客户确认记录

⚠️ “客户坚持要做” ≠ 可忽略适当性义务

14.4 高风险产品与服务的特别控制

14.4.1 VARA 认定的高风险场景（示例）

杠杆或借贷类产品
高波动性代币
复杂衍生结构
新发行或流动性不足资产

14.4.2 对高风险产品的监管预期

VARA 通常要求：

限制零售客户参与
加强风险披露
高级管理层批准
更严格的营销限制

14.5 营销与推广活动的合规要求（Marketing Conduct）

14.5.1 VARA 对营销的基本立场

VARA 明确禁止：

虚假或夸大宣传
保证收益或暗示保本
淡化风险、强调暴利

14.5.2 禁止性营销表述（示例）

以下表述通常被视为不合规：

“低风险高回报”
“稳赚不赔”
“监管背书 / 政府认可”
“错过即损失机会”

14.5.3 合规营销的基本要求

合规营销应：

内容真实、准确、可验证
风险披露清晰、醒目
与目标客户群体匹配

14.6 数字营销、社交媒体与 KOL 合作（重点）

14.6.1 VARA 对线上营销的关注

VARA 明确将以下行为纳入监管范围：

官网内容
App 内推送
社交媒体
KOL / Influencer 推广

⚠️ “是第三方说的” ≠ 免责

14.6.2 KOL / 推广合作的合规要求

VASP 必须：

对推广内容进行审核
确保披露合作关系
防止误导性表述

14.7 风险披露（Risk Disclosure）

14.7.1 风险披露的监管逻辑

VARA 要求风险披露：

在客户作出决策前完成
语言清晰、非技术性堆砌
针对具体产品与风险

14.7.2 常见风险披露内容

市场波动风险
流动性风险
技术与网络安全风险
法规变化风险

14.8 利益冲突管理（Conflicts of Interest）

14.8.1 VARA 对利益冲突的立场

VARA 并不禁止利益冲突的存在，但要求：

识别
披露
管理或避免

14.8.2 常见利益冲突场景

自营交易与客户交易
上币审核与商业利益
推广激励与客户利益

14.8.3 管理措施（示例）

信息隔离
决策回避
披露与客户确认

14.9 客户投诉与纠纷处理

14.9.1 投诉处理机制要求

VARA 要求：

明确投诉渠道
有处理时限
有记录与跟踪

14.9.2 投诉的监管意义

VARA 将投诉视为：

风险信号
市场行为问题的早期指标

14.10 常见 Conduct of Business 失败点

失败情形	VARA 反应
夸大收益宣传	严重负面
无客户分层	要求整改
KOL 误导推广	问责 VASP
风险披露形式化	不接受

14.11 本章交付级总结

在 VARA 体系下，市场行为不是“营销问题”，而是“合规底线”。

一个可被 VARA 接受的 Conduct of Business 框架，必须做到：

客户分得清
产品卖得对
风险说得明
推广守得住

第 15 章｜财务资源、资本要求与持续财务稳健性

Financial Resources, Capital Adequacy & Ongoing Financial Soundness（审慎监管核心章节｜交付版）

本章定位（监管视角）
VARA 的审慎监管理念可以概括为：
“虚拟资产风险不可预测，因此资本必须可预测、可验证、可持续。”

VARA 关注的不是“起步有多少钱”，而是：

资本是否与风险相匹配

是否能覆盖最坏情形

是否具备持续经营能力

15.1 VARA 的审慎监管逻辑（Capital Philosophy）

15.1.1 资本不是“门槛”，而是“缓冲垫”

在 VARA 体系中，资本的核心功能是：

吸收经营与操作风险损失
保障客户与市场信心
支撑业务连续性与合规投入

因此，资本要求并非一次性，而是贯穿整个持牌生命周期。

15.1.2 “与业务风险成比例”的原则

VARA 并未采用“一刀切”的资本数额，而是根据以下因素综合判断：

许可活动类别（8 大活动）
是否涉及 Custody
是否面向零售客户
交易量与资产规模
技术与运营复杂度

⚠️ 业务越复杂、风险越高，资本要求越重。

15.2 VARA 对最低资本与财务资源的基本要求

15.2.1 资本形式的基本要求

VARA 通常要求资本具备以下特征：

实缴（Paid-up）
无负担（Unencumbered）
可立即使用（Immediately Available）

不可接受的情形包括：

仅承诺未实缴
受限或已抵押资金
短期借款冒充资本

15.2.2 不同活动类型的资本差异（原则性说明）

在实务中（以监管经验为参考）：

Advisory / Broker-Dealer：
- 资本要求相对较低
Exchange / Transfer & Settlement：
- 中等至较高
Custody / Lending & Borrowing：
- 最高等级要求

⚠️ VARA 保留根据个案上调资本或附加保证金的权力。

15.3 持续财务稳健性（Ongoing Financial Soundness）

15.3.1 持牌后的持续义务

获得 VARA 牌照后，VASP 仍须持续满足：

最低资本要求
流动性充足性
费用与风险覆盖能力

资本不得在未获批准的情况下被抽走或削弱。

15.3.2 资本侵蚀的监管处理

若发生以下情形：

持续亏损
重大赔付
系统性事故

VARA 可能要求：

立即补充资本
限制业务规模
暂停部分活动

15.4 财务预测与商业可持续性（Financial Projections）

15.4.1 财务预测的监管目的

VARA 要求提交 中期财务预测（通常 3 年），目的并非考察“盈利能力”，而是：

判断业务是否可持续
判断资本是否足以支撑发展
判断是否存在过度激进扩张

15.4.2 财务预测的基本内容

通常包括：

利润表预测
现金流预测
资本变化分析
情景与压力测试

15.4.3 VARA 常见关注点

初期亏损是否可承受
收入假设是否合理
合规与技术成本是否被低估
扩张节奏是否与资本匹配

15.5 流动性管理与资金可得性

15.5.1 流动性的重要性

VARA 明确区分：

账面资本
实际可用流动性

监管关注的是后者。

15.5.2 流动性管理措施（示例）

保持一定比例现金或等同物
设定内部流动性预警指标
制定紧急融资或缩表方案

15.6 资金来源（Source of Funds, SoF）

15.6.1 资金来源透明度要求

VARA 要求申请人：

说明资本与营运资金来源
提供合法性证明
避免复杂、不透明结构

15.6.2 高风险资金来源示例

以下情况通常会触发深入审查：

加密资产直接作为资本
多层跨境注资
来自高风险司法辖区

15.7 资金用途与内部控制

15.7.1 资金用途的监管关注

VARA 关注：

资本是否用于支持持牌业务
是否被挪作非许可用途
是否存在关联方不当交易

15.7.2 内部控制措施

预算与审批制度
关联交易披露
财务报告与审计

15.8 审计、报告与监管沟通

15.8.1 财务审计要求

VARA 通常要求：

定期财务报表
经认可审计师审计
重大事项及时披露

15.8.2 财务事件的监管报告义务

以下事件通常需向 VARA 报告：

资本不足
流动性危机
重大财务损失

15.9 常见财务失败点（监管经验总结）

失败情形	VARA 反应
资本不足或不稳定	延期或否决
预测过度乐观	要求重做
资金来源不清	深度尽调
流动性管理缺失	附加条件

15.10 本章交付级总结

在 VARA 体系下，资本不是“数字游戏”，而是“信任背书”。

一个可被 VARA 接受的财务与资本框架，必须能够证明：

钱是真实的
钱是干净的
钱是够用的
钱是可持续的

第 16 章｜代币发行、上市（Listing）与产品治理

Token Issuance, Listing & Product Governance（高敏感产品监管章节｜交付版）

本章定位（监管视角）
VARA 对代币的核心监管态度是：
“代币不是代码，而是金融产品；发行与上市不是技术行为，而是受规管活动。”

因此，VARA 并不只关注“技术可行性”，而是系统性审查：

代币的经济与法律属性

发行与上市的决策机制

对客户的风险影响

持续治理与下架能力

16.1 VARA 对代币与产品治理的总体原则

VARA 对代币发行、上市与产品治理的总体原则可概括为四点：

事前审慎（Pre-launch Due Diligence）
持续监管（Ongoing Oversight）
风险透明（Risk Transparency）
可撤回性（Ability to Suspend / Delist）

⚠️ “一旦上线就无法控制”的产品，VARA 不会批准。

16.2 Issuance（Category 1）的监管边界与适用场景

16.2.1 Category 1 Issuance 的定位

在 VARA 的 8 大活动中，Issuance（Category 1） 适用于以下情形：

在迪拜（非 DIFC）向公众或特定群体发行虚拟资产
发行与某项目、平台或生态系统相关的代币
作为发行方或主要发行协调方

16.2.2 Issuance 不等同于“任何发币”

VARA 明确区分：

技术发行（Technical Minting）
受规管发行（Regulated Issuance）

只要满足以下任一情形，通常即构成受规管发行：

面向公众募集资金
代币具有投资或收益预期
发行活动由 VASP 主导或推广

16.3 代币分类与监管定性（Token Classification）

16.3.1 VARA 关注的代币属性维度

VARA 并不简单依赖代币名称，而是从以下维度进行综合判断：

功能属性（Utility / Payment / Governance）
经济属性（是否有收益、分红、回购）
权利属性（投票权、收益权、索偿权）
发行与分配方式

16.3.2 高风险代币特征（示例）

以下特征通常会被 VARA 视为高监管风险：

承诺或暗示收益
与发行方业绩直接挂钩
高度中心化控制
信息披露不足

16.4 上市（Listing）治理框架（Exchange 重点）

16.4.1 上市不是“商业决策”，而是“治理决策”

VARA 明确要求：
代币上市必须通过正式、可审计的治理流程。

16.4.2 上市委员会（Listing Committee）

实务中，VARA 通常期望 Exchange 设立：

独立的 Listing Committee
明确成员构成
明确职责与回避机制

16.4.3 上市评估的核心要素（交付级）

上市评估至少应覆盖：

项目背景与团队
代币经济模型
技术安全性
法律与合规风险
市场操纵与滥用风险

16.5 代币尽职调查（Token Due Diligence）

16.5.1 尽调的监管目的

VARA 关注的问题不是：

“这个项目是否成功？”

而是：

“这个项目的风险是否被识别、披露并可被管理？”

16.5.2 尽调应涵盖的关键领域

发行主体与控制结构
代币分配与解锁机制
智能合约安全审计
资金用途与治理安排

16.6 代币经济模型与风险评估

16.6.1 Tokenomics 的监管关注点

VARA 通常重点关注：

是否存在极端通胀或通缩机制
是否存在价格操纵空间
是否存在信息不对称

16.6.2 风险缓释措施（示例）

解锁期与锁仓安排
透明披露
持续监控与预警

16.7 风险披露与客户沟通（Issuance & Listing）

16.7.1 风险披露的最低要求

VARA 要求风险披露：

在发行或上市前完成
内容清晰、可理解
针对具体代币

16.7.2 不充分披露的监管后果

要求补充披露
暂停发行或交易
追究责任

16.8 持续监控、暂停与下架（Ongoing Monitoring & Delisting）

16.8.1 持续监控义务

上市后，VASP 仍须：

持续监控项目进展
评估风险变化
跟踪合规事件

16.8.2 暂停与下架机制

VARA 明确要求 VASP 具备：

暂停交易的权力
下架代币的能力
清晰的触发条件与流程

⚠️ “无法下架”在 VARA 体系中被视为严重治理缺陷。

16.9 利益冲突与独立性（Listing & Issuance）

16.9.1 常见冲突场景

Exchange 投资被上市项目
高管或关联方持有大量代币
上市费用与商业激励

16.9.2 管理措施

披露与回避
独立审查
决策留痕

16.10 常见失败点（监管经验总结）

失败情形	VARA 反应
上市无正式评估	不接受
风险披露不足	暂停
无下架机制	要求重构
利益冲突未管理	严重负面

16.11 本章交付级总结

在 VARA 体系下，代币治理是“持续责任”，不是“一次性审批”。

一个可被 VARA 接受的 Issuance / Listing 框架，必须做到：

发得清楚
上得审慎
管得住
下得了

第 17 章｜借贷、质押与杠杆业务（Lending & Borrowing）

Lending, Borrowing, Staking & Leverage Regulation（高风险业务强监管章节｜交付版）

本章定位（监管视角）
VARA 对借贷与杠杆的监管结论非常明确：
“所有‘承诺收益’或‘放大风险’的模式，必须被视为系统性风险源。”

因此，VARA 对 Lending & Borrowing 的审查深度，明显高于现货交易与经纪业务，并以“最坏情形”为设计基准。

17.1 VARA 对借贷与杠杆业务的总体监管立场

VARA 对该类业务的总体立场可概括为四点：

极高风险认定：借贷、杠杆、质押被列为高风险活动
强客户保护：尤其是零售客户
穿透式监管：不因“技术结构”而降低要求
可关闭性要求：必须能在极端情形下快速收缩或暂停

⚠️ 任何无法在市场崩盘中“快速止血”的设计，都会被 VARA 否决。

17.2 Lending & Borrowing 的业务边界与监管定性

17.2.1 构成 Lending & Borrowing 的典型情形

以下情形通常被 VARA 认定为 Lending & Borrowing 活动：

向客户提供加密资产或法币借贷
接受客户资产并支付利息或收益
提供保证金交易或杠杆放大
再质押（Rehypothecation）客户资产
质押挖矿并承诺固定或可预测回报

17.2.2 “非借贷”名义下的实质借贷（重点）

VARA 明确采取 实质重于形式（Substance over Form） 原则。
即便业务被命名为：

“Earn”
“Yield”
“Staking Service”
“Liquidity Program”

只要具备 资金集中 + 回报承诺 + 风险转移 的特征，
均可能被定性为 Lending & Borrowing。

17.3 零售客户的特别限制（Retail Client Protection）

17.3.1 VARA 对零售客户的基本态度

VARA 对零售客户参与借贷或杠杆业务采取 高度审慎甚至限制性态度。

在实务中，VARA 可能要求：

禁止零售客户参与某些产品
仅允许专业/机构客户
或施加严格的额度、杠杆与风险限制

17.3.2 零售客户保护措施（示例）

更严格的适当性评估
强化风险披露
冷静期（Cooling-off Period）
杠杆上限

17.4 抵押品管理（Collateral Management）

17.4.1 抵押品的合格性要求

VARA 通常关注：

抵押品类型（稳定币 vs 高波动资产）
抵押品流动性
抵押品集中度风险

17.4.2 抵押率与安全边际

监管期望 VASP：

设定初始抵押率（Initial Margin）
设定维持抵押率（Maintenance Margin）
留有足够安全边际以应对剧烈波动

⚠️ “最低可行抵押率”在 VARA 体系中被视为危险设计。

17.5 再质押（Rehypothecation）的监管态度（极其关键）

17.5.1 VARA 对再质押的基本立场

VARA 并未全面禁止再质押，但采取 高度限制与强披露 的立场：

必须获得客户明确同意
必须清晰披露风险
必须具备严格限额与用途控制

17.5.2 再质押的常见监管条件

仅限专业或机构客户
再质押比例上限
禁止用于高风险用途
持续监控与报告

17.6 清算、强平与风险处置机制（Liquidation Framework）

17.6.1 清算机制的监管重要性

VARA 在审查中通常重点提问：

“市场瞬间下跌 30%，你的系统会发生什么？”

17.6.2 清算机制的最低要求

自动化与人工兜底并存
明确触发条件
公平、可预测的清算顺序
防止系统性连锁反应

17.6.3 客户沟通与通知

提前披露清算规则
在可行情况下通知客户
事后提供清算说明

17.7 利息、收益与定价机制

17.7.1 利息与收益的监管关注点

VARA 关注：

利息是否与风险匹配
是否存在误导性“稳定收益”暗示
定价是否透明

17.7.2 禁止性情形（示例）

承诺固定无风险收益
模糊收益来源
隐藏费用或风险转嫁

17.8 风险披露与客户协议（Contractual Safeguards）

17.8.1 风险披露要求

风险披露必须：

针对具体产品
使用清晰语言
覆盖最坏情形

17.8.2 客户协议的监管期望

客户协议中应明确：

资产所有权
风险承担
再质押安排（如有）
清算与争议处理

17.9 持续监控、压力测试与限额管理

17.9.1 持续监控要求

抵押率实时监控
客户集中度监控
流动性风险监控

17.9.2 压力测试（Stress Testing）

VARA 通常期望：

定期压力测试
覆盖极端但合理场景
测试结果用于调整限额与政策

17.10 常见失败点（监管经验总结）

失败情形	VARA 反应
向零售客户提供高杠杆	高风险
清算机制不透明	不接受
再质押未披露	严重负面
收益表述误导	处罚风险

17.11 本章交付级总结

在 VARA 体系下，借贷与杠杆不是“增收工具”，而是“生存考验”。

一个可被 VARA 接受的 Lending & Borrowing 框架，必须做到：

风险算得清
杠杆控得住
清算跑得快
客户护得住

第 18 章｜内部控制、记录保存与监管报告

Internal Controls, Record-Keeping & Regulatory Reporting（持续监管核心章节｜交付版）

本章定位（监管视角）
VARA 的监管逻辑非常清晰：
“如果事情没有被记录下来，在监管视角中，它就没有发生。”

因此，VARA 不只看制度是否存在，而是看：

记录是否完整

是否可随时调取

是否经得起事后审查

18.1 VARA 对内部控制与记录保存的总体监管理念

VARA 将内部控制与记录保存视为：

治理是否有效的证据系统
风险是否被管理的事实基础
监管问责是否可执行的关键工具

⚠️ “口头流程 + 无记录”在 VARA 体系中等同于“无控制”。

18.2 内部控制框架（Internal Control Framework）

18.2.1 内部控制的基本目标

VARA 期望内部控制至少实现以下目标：

确保业务行为符合牌照范围
防止未经授权的操作
及时识别与纠正异常
支持准确、及时的监管报告

18.2.2 内部控制的核心组成（交付级）

建议在制度中明确以下模块：

权限与职责分离
审批与复核机制
系统控制与人工控制结合
异常升级与纠偏机制

18.3 记录保存（Record-Keeping）的范围与原则

18.3.1 VARA 要求保存的记录类型

VARA 通常要求 VASP 保存以下类别的记录（非穷尽）：

客户相关记录（KYC / CDD / EDD）
交易记录（链上与链下）
钱包与资产变动记录
合规与 AML 记录（STR、监控报告）
董事会与委员会会议记录
外包与第三方管理记录
内部审计与整改记录

18.3.2 记录保存的核心原则

所有记录应满足：

完整性（Completeness）
准确性（Accuracy）
可追溯性（Traceability）
不可篡改性（Integrity）

18.4 记录保存期限（Retention Period）

18.4.1 最低保存期限（原则性）

在 VARA 实务中，常见最低保存要求包括：

客户与交易记录：不少于 5–8 年（以适用法规为准）
AML / STR 相关记录：不少于 5 年
治理与审计记录：不少于 7 年

⚠️ 若存在调查、争议或监管要求，
记录需延长保存，直至事项完全结案。

18.4.2 电子记录与数据存储

VARA 接受电子化保存，但前提是：

数据安全
可快速检索
可在监管要求下导出

18.5 数据完整性与防篡改控制

18.5.1 防篡改措施（示例）

VARA 期望看到：

系统日志不可随意删除
关键记录具备访问控制
数据变更有审计轨迹

18.5.2 数据备份与恢复

定期数据备份
异地或隔离存储
定期恢复测试

18.6 监管报告义务（Regulatory Reporting）

18.6.1 报告义务的总体原则

VARA 要求 VASP：

主动报告
及时报告
真实完整报告

⚠️ “未被问到”不是不报告的理由。

18.6.2 常见定期报告类型（示例）

根据业务类型，VARA 可能要求：

定期合规报告
财务与资本充足性报告
风险与运营报告
AML/CFT 执行报告

18.6.3 重大事项即时报告（Event-Driven Reporting）

以下事件通常需在规定时间内报告 VARA：

重大系统故障或安全事件
客户资产风险或损失
重大合规违规
关键人员变动
资本或流动性不足

18.7 STR 与监管报告的衔接

18.7.1 STR 的保密性与留痕

STR 的提交事实不得向客户披露
内部需留存完整评估与决策记录

18.7.2 STR 与 VARA 沟通

在某些情形下，VARA 可能要求：

进一步解释 STR 背景
提供支持性记录
说明后续风险缓释措施

18.8 监管检查、问询与应答机制

18.8.1 VARA 的监管检查形式

VARA 可能通过以下方式开展监督：

书面问询（RFI）
现场或远程检查
专题审查（Thematic Review）

18.8.2 应答机制的监管期望

VASP 应具备：

明确的监管沟通负责人
内部信息协调机制
在限期内提交完整、准确回复

⚠️ 回复不完整或前后矛盾，往往比问题本身更严重。

18.9 内部审计与持续改进

18.9.1 内部审计的作用

内部审计是：

第三道防线
监管信心的重要来源

18.9.2 审计发现与整改闭环

VARA 期望：

审计发现被记录
整改措施明确
完成情况可追踪

18.10 常见记录与报告失败点（监管经验）

失败情形	VARA 反应
记录不完整	高风险
数据无法调取	不接受
重大事件迟报	严重负面
回复监管敷衍	加强监管

18.11 本章交付级总结

在 VARA 体系下，记录保存与报告不是“行政工作”，而是“合规生命线”。

一个可被 VARA 接受的内部控制与记录体系，必须做到：

事前有控制
事中有记录
事后能复盘
监管随时可查

第 19 章｜变更管理、重大事项申报与牌照持续合规

Change Management, Material Notifications & Ongoing Compliance（持牌后高风险章节｜交付版）

本章定位（监管视角）
VARA 的核心监管理念之一是：
“牌照不是一次性授权，而是持续条件授权。”

换言之：

你今天合规，不代表明天仍合规

任何可能影响风险画像的变化，都必须被监管知悉并评估

19.1 VARA 对“变更”的基本监管态度

19.1.1 变更不是禁止事项，但必须被管理

VARA 并不反对企业发展、调整或扩张，但前提是：

变更透明
变更 可评估
变更 不削弱监管目标

⚠️ “先改、再说、再补报”是 VARA 的高风险红线。

19.1.2 变更管理的三大原则

事前识别（Identify）
事前评估（Assess）
事前申报或获批（Notify / Obtain Approval）

19.2 何谓“重大事项”（Material Change）【极其关键】

VARA 采用 实质重于形式 原则。
是否构成重大事项，取决于：

是否可能影响公司风险、合规能力或监管判断。

19.2.1 通常被视为重大事项的变更（示例）

以下情形在实务中几乎必然被视为重大事项：

股东或实益所有人（UBO）变更
董事、CEO、CO、MLRO 等关键人员变更
业务模式或许可活动范围变更
客户类型变化（如新增零售客户）
Custody、Lending 等高风险活动新增或调整
技术架构重大调整
关键外包方变更

19.2.2 “看似不大、实则很大”的变更

表面变更	VARA 实务判断
更换云服务商	可能是重大
新增一种代币	视风险而定
集团内部重组	通常是重大
市场扩张	需评估

19.3 事前批准 vs 事后通知（Approval vs Notification）

19.3.1 何时必须事前批准（Prior Approval）

以下变更通常需要 事前获得 VARA 批准：

控股股东或 UBO 变更
新增或变更许可活动类别
Custody 架构或资产控制方式变更
关键治理结构重构

19.3.2 何时可事后通知（Post-Event Notification）

部分较低风险变更，可能允许：

在变更发生后
于规定时限内
向 VARA 提交通知与说明

⚠️ 是否“可事后通知”，
由 VARA 判断，而非企业自行认定。

19.4 变更评估（Change Impact Assessment）

19.4.1 变更前必须完成的内部评估

VARA 期望 VASP 在任何重大变更前完成书面评估，至少包括：

对合规的影响
对风险画像的影响
对客户的影响
对资本与资源的影响

19.4.2 评估的治理要求

由第二道防线（合规/风险）主导
重大变更需提交董事会
评估结果需留痕并可审计

19.5 关键人员变更的特殊要求

19.5.1 关键人员的范围

通常包括：

董事
CEO / General Manager
Compliance Officer
MLRO
关键技术负责人（如适用）

19.5.2 关键人员变更的监管期望

VARA 通常要求：

事前通知或批准
提交新任人员的 Fit & Proper 资料
说明过渡安排

⚠️ “临时空缺 + 事后再说”是高风险信号。

19.6 业务范围与客户结构变更

19.6.1 业务扩张的监管逻辑

VARA 并不自动允许“自然扩张”，而是关注：

是否超出原有风险假设
是否需要额外控制或资本
是否触发新的监管要求

19.6.2 零售客户相关变更（特别敏感）

任何涉及：

新增零售客户
放宽零售限制
推出面向零售的新产品

均通常需要 事前沟通甚至批准。

19.7 技术、外包与系统变更

19.7.1 技术变更的监管关注点

VARA 关注：

是否影响客户资产安全
是否影响系统可审计性
是否引入新风险

19.7.2 外包方变更

关键外包方变更通常视为重大事项
需重新尽调
需更新退出与应急方案

19.8 违规变更的监管后果（必须严肃对待）

19.8.1 常见违规变更情形

未经批准更换控股股东
未申报关键人员离任
擅自新增高风险业务

19.8.2 VARA 可能采取的措施

要求立即整改
限制或暂停业务
处以罚款
在严重情况下撤销牌照

19.9 持续合规（Ongoing Compliance）的制度化要求

19.9.1 持续合规不是“年度动作”

VARA 期望：

合规是日常运营的一部分
变更管理融入公司流程

19.9.2 建议的持续合规机制

变更识别清单
合规审批流程
定期合规自评
员工培训

19.10 常见失败点（监管经验总结）

失败情形	VARA 反应
未识别重大变更	严重负面
先实施后申报	高处罚风险
关键人员空缺	监管关注
合规未参与决策	要求整改

19.11 本章交付级总结

在 VARA 体系下，变更不是发展障碍，而是合规能力的试金石。

一个成熟的 VASP，必须做到：

改之前想清楚
想清楚再沟通
沟通完再行动

第 20 章｜监管检查、执法措施与处罚风险地图

Regulatory Inspections, Enforcement Powers & Risk Map（强执法章节｜交付版）

本章定位（监管视角）
VARA 的一项清晰立场是：
“合规不是‘承诺’，而是‘可被检查、可被验证、可被处罚’的持续状态。”

因此，VARA 通过检查与执法来回答三个问题：

你是否真的在按规则运营

出问题时你是否诚实、配合

风险是否被系统性管理

20.1 VARA 的监管检查权力与范围

20.1.1 VARA 的法定检查权

VARA 有权在任何合理时间内，对持牌或申请中的 VASP 进行：

文件检查
系统与数据检查
现场或远程检查
专题或突击检查

该权力通常涵盖：

公司本身
分支机构
关键外包方（通过穿透式监管）

20.1.2 检查对象与覆盖范围

监管检查可覆盖（但不限于）：

治理与组织结构
客户资产与 Custody
AML/CFT 与 STR
技术系统与网络安全
市场行为与营销
财务资源与资本
变更管理与持续合规

⚠️ “这不是我们重点”不能作为拒绝检查的理由。

20.2 VARA 监管检查的主要形式

20.2.1 文件审查（Desk-based Review）

要求提交指定材料
核对制度与记录
比对前后版本一致性

常见触发情形包括：

定期监管计划
风险信号
客户投诉
重大变更后

20.2.2 现场检查（On-site Inspection）

现场检查通常关注：

实际操作是否与制度一致
系统是否真实存在并运行
员工是否理解其职责

20.2.3 远程检查与专题审查

VARA 亦可能：

通过视频会议检查
针对某一主题开展专项审查（如 Custody、AML、Listing）

20.3 监管问询（RFI）与信息要求

20.3.1 RFI 的监管地位

监管问询（Request for Information, RFI）是 VARA 最常用、也是最关键的执法工具之一。

RFI 通常要求：

在限定时间内回复
提供完整、准确、可验证的信息

20.3.2 RFI 回复的监管期望

VARA 期望 RFI 回复：

内容完整
逻辑一致
有证据支持
不回避问题

⚠️ 敷衍、拖延或前后矛盾，往往会升级为执法行动。

20.4 VARA 的执法工具箱（Enforcement Toolkit）

20.4.1 轻度至中度执法措施

书面警告
整改要求（Remediation Order）
限期完成整改
加强监管（Enhanced Supervision）

20.4.2 严重执法措施

在情节严重或屡犯情况下，VARA 可：

限制或暂停部分业务
处以罚款
要求更换管理层
撤销牌照

20.4.3 处罚的决定因素

VARA 在决定处罚时通常考虑：

违规的性质与严重性
是否涉及客户损失
是否系统性问题
是否主动披露与配合

20.5 处罚风险地图（Risk Map）

20.5.1 高风险违规领域（红色区域）

以下领域在 VARA 执法中属于高风险红区：

客户资产挪用或控制失当
未经批准开展 Custody / Lending
严重 AML/CFT 缺陷
误导性营销面向零售客户

20.5.2 中风险违规领域（橙色区域）

记录保存不完整
技术控制薄弱
变更未及时申报
外包监督不足

20.5.3 低风险但可累积违规（黄色区域）

轻微报告迟延
培训记录不足
内部流程不一致

⚠️ 低风险违规反复出现，可能被认定为治理失败。

20.6 执法中的“加重因素”与“减轻因素”

20.6.1 加重因素（Aggravating Factors）

故意隐瞒或误导
多次违规
管理层知情不作为
对监管不配合

20.6.2 减轻因素（Mitigating Factors）

主动自查并报告
快速、有效整改
管理层高度参与
无客户损失

20.7 企业应对监管检查的最佳实践

20.7.1 检查前的准备

建立监管检查应对预案
指定统一对外沟通窗口
定期内部模拟检查

20.7.2 检查中的应对原则

如实回答
不猜测、不粉饰
不擅自承诺无法实现的整改

20.7.3 检查后的整改与跟进

制定明确整改计划
分配责任人
按期向 VARA 汇报进展

20.8 “自报问题”（Self-reporting）的监管价值

VARA 明确鼓励：

在发现重大问题后
主动、自愿、及时 向监管报告

在多数情况下，自报问题：

不会被视为承认违法
反而可能显著降低处罚风险

20.9 常见执法失败案例（经验总结）

情形	VARA 反应
拒绝或拖延检查	严重执法
反复小违规	升级监管
未披露重大事件	高额处罚
对外包失控	要求重构

20.10 本章交付级总结

在 VARA 体系下，真正的合规能力，体现在“被检查时的表现”。

一个成熟的 VASP，应当做到：

平时就像随时会被检查
文件永远可查
问题敢于承认
整改能够落地

第 21 章｜退出机制、业务终止与有序清盘

Wind-down, Orderly Exit & Business Termination（终局治理核心章节｜交付版）

本章定位（监管视角）
VARA 的明确立场是：
“任何不能被安全关闭的业务，都是不可被批准的业务。”

因此，VARA 要求 VASP 在尚未发生问题之前，就证明：

如何停止业务

如何保护客户

如何清算而不引发系统性风险

21.1 VARA 对“可退出性（Exitability）”的监管原则

VARA 对退出机制的三项核心原则：

预先规划（Pre-planned）
以客户为中心（Client-centric）
可执行（Executable under stress）

⚠️ “届时再看情况”在 VARA 体系中不可接受。

21.2 何时需要启动 Wind-down（触发条件）

21.2.1 常见触发情形（示例）

Wind-down 可能在以下情况下启动：

监管要求或牌照被撤销/不续
资本或流动性严重不足
持续经营能力丧失
重大系统性事故
董事会决定退出市场

21.2.2 触发机制的制度化要求

VARA 期望 VASP：

在制度中预先定义触发阈值
明确由谁判断、如何决策
决策需留痕并可审计

21.3 Wind-down 的总体目标与优先顺序

21.3.1 退出的首要目标

VARA 明确以下优先级（由高到低）：

保护客户资产与权益
维护市场稳定
遵守监管与法律义务
有序处置公司事务

21.3.2 不可接受的退出方式

突然停止服务、失联
无安排冻结客户资产
数据与记录缺失
逃避监管沟通

21.4 客户资产与资金的终局安排（最关键）

21.4.1 客户资产的基本原则

在 Wind-down 过程中，必须确保：

客户资产 不被挪用
客户资产 优先返还
返还过程 透明、可核查

21.4.2 资产返还的操作路径（示例）

确认客户余额
公告返还安排与时间表
提供多种返还方式（如链上转移）
处理无人认领或争议资产

21.4.3 Custody 业务的特别要求

对 Custody 类业务，VARA 通常要求：

提前规划资产迁移方案
明确第三方接收安排（如适用）
私钥与权限安全交接

21.5 未完成交易、借贷与合约的处理

21.5.1 未完成交易（Open Positions）

明确是否平仓或迁移
披露处理规则
防止选择性对待客户

21.5.2 借贷、质押与杠杆的退出处理

停止新增借贷
管理抵押与清算
避免引发连锁清算

21.6 人员、系统与外包的退出管理

21.6.1 关键人员与职责延续

VARA 关注：

Wind-down 期间谁负责
合规、AML、Custody 职能是否持续
关键岗位是否提前流失

21.6.2 系统与第三方的退出安排

系统保持可用直至完成清盘
第三方合同的终止与数据交接
云服务与托管的安全关闭

21.7 数据、记录与审计的终局保存

21.7.1 记录保存的持续义务

即便业务终止，VASP 仍需：

保存法定年限的记录
确保数据完整与可调取
配合后续监管或法律程序

21.7.2 数据隐私与销毁

非必要数据应安全销毁
敏感数据防止泄露
销毁过程留痕

21.8 对监管机构与客户的沟通

21.8.1 与 VARA 的沟通要求

及时通知 Wind-down 决定
提交 Wind-down 计划
定期汇报执行进度

21.8.2 客户沟通原则

及时、清晰、真实
不误导、不淡化风险
提供支持渠道

21.9 Wind-down 的资金与资源保障

21.9.1 退出成本的监管关注

VARA 会关注：

是否预留足够资源用于退出
是否依赖不确定融资
是否存在“资金用尽即停摆”的风险

21.9.2 资金安排示例

专项 Wind-down 预算
受限资金用于退出
保险或保证金（如适用）

21.10 常见退出失败点（监管经验）

失败情形	VARA 反应
无书面 Wind-down 计划	不接受
客户资产返还不清	高风险
关键人员提前离场	监管关注
对监管沟通不足	执法风险

21.11 本章交付级总结

在 VARA 体系下，“如何退出”与“如何进入”同等重要。

一个可被 VARA 接受的 Wind-down 框架，必须证明：

退出是可计划的
过程是可执行的
结果是可审计的
客户是被优先保护的

第 22 章｜全球合规协同、跨境监管与牌照定位

Global Regulatory Coordination, Cross-border Compliance & VARA Positioning（战略合规章节｜交付版）

本章定位（战略视角）
VARA 不是“离岸牌照”，也不是“万能通行证”。
它的真实价值在于：
成为中东及全球加密业务网络中的“核心枢纽牌照”。

22.1 VARA 在全球虚拟资产监管版图中的角色

22.1.1 VARA 的独特监管定位

VARA 的监管属性具有三重特征：

区域核心：中东（GCC）最成熟的加密监管之一
国际对齐：高度对标 FATF、IOSCO、FSB 原则
商业友好：允许多业务并行、清晰的活动分级许可

⚠️ VARA 的优势不在于“宽松”，而在于 “规则明确 + 执行可预期”。

22.1.2 VARA 与其他主流监管体系的比较定位

司法辖区	监管特征	VARA 对比
欧盟 MiCA	统一立法、严格资本	VARA 更灵活
英国 FCA	原则导向、审慎	VARA 更结构化
新加坡 MAS	高门槛、精选	VARA 商业友好
香港 SFC	投资者保护强	VARA 市场导向

22.2 跨境展业的核心监管原则（必须理解）

22.2.1 一个根本误区（必须纠正）

❌ “有 VARA 牌照 = 可以全球做业务”

✅ 正确理解是：
VARA 授权你在其认可的范围内、以合规方式参与跨境业务。

22.2.2 VARA 对跨境展业的基本逻辑

VARA 关注三点：

你从哪里运营（Substance）
你向哪里提供服务（Target Market）
是否触发当地监管（Local Perimeter）

22.3 跨境客户与市场定位管理

22.3.1 客户地域划分（监管视角）

VARA 期望 VASP 明确区分：

UAE 本地客户
GCC 区域客户
非中东海外客户

并在制度中说明：

哪些市场主动营销
哪些市场被动接受
哪些市场明确排除

22.3.2 被动跨境（Reverse Solicitation）

VARA 通常接受：

非 UAE 客户自行访问平台
无定向营销、无本地推广

但前提是：

有明确的市场限制声明
有 IP、语言、营销控制

22.4 VARA 与其他监管机构的协同关系

22.4.1 信息共享与监管协作

VARA 可能：

与其他监管机构交换信息
配合跨境调查
要求企业解释多地合规结构

22.4.2 对“监管套利”的明确态度

VARA 明确反对：

利用监管差异规避监管
空壳结构
虚假地域划分

⚠️ “最低监管成本结构”在 VARA 体系中是负面信号。

22.5 多牌照结构下的合规协同（实务重点）

22.5.1 常见多牌照组合模式

VARA + 欧盟 MiCA CASP
VARA + 英国 FCA 注册
VARA + 香港 SFC（虚拟资产相关）
VARA + 离岸 VASP（技术或辅助功能）

22.5.2 合规协同的核心要求

VARA 关注：

各牌照之间职责是否清晰
客户与资产是否正确分隔
是否存在监管真空

22.6 集团结构与监管穿透

22.6.1 VARA 的穿透式监管逻辑

VARA 会关注：

母公司与子公司关系
技术、资金、人员共享
实质控制权

22.6.2 集团合规失败的常见原因

情形	监管风险
共用钱包	极高
模糊资产归属	高
合规职能空心化	高
文件版本不一致	中

22.7 跨境 AML/CFT 的协调要求

22.7.1 统一 vs 本地化

VARA 通常接受：

集团级 AML 框架
- VARA 本地化补充制度

但不接受：

直接照搬他国制度
忽视 UAE 风险画像

22.7.2 STR 与跨境报告协调

STR 需遵循 UAE 要求
不得因总部在海外而延迟或不报
跨境 STR 需评估法律冲突

22.8 技术与数据跨境问题

22.8.1 数据存储与访问

VARA 关注：

数据是否安全
是否可被 VARA 调取
跨境访问是否受控

22.8.2 云与系统的跨境部署

允许云部署
但必须清晰控制权限
关键系统需可审计

22.9 VARA 牌照的战略价值总结

22.9.1 VARA 的“正确用法”

VARA 牌照最适合作为：

中东区域总部牌照
全球业务的监管锚点
机构级客户信任背书

22.9.2 不适合的定位方式

当作“最低成本牌照”
当作“规避其他监管的工具”
当作“无实质运营的通行证”

22.10 本章交付级总结

VARA 不是终点，而是全球合规版图中的“战略节点”。

一个成熟的 VARA 持牌结构，应当做到：

清楚自身全球定位
尊重各地监管边界
主动管理跨境风险
构建可持续的多牌照体系

第 23 章｜申请递交、监管问询（RFI）与审批节奏管理

Application Submission, RFI Handling & Approval Mastery（实战操盘章节｜交付版）

本章定位（审批视角）
VARA 的审批不是“考试”，而是一个持续对话过程。

成功项目的共同点只有一个：
监管在任何时点，都“看得懂你、信得过你、等得到你”。

23.1 VARA 真实审批逻辑（必须先纠正误解）

23.1.1 三个常见误区

❌ 文件越多越好
❌ 一次性“写到极致”
❌ RFI = 出问题了

23.1.2 VARA 的真实判断顺序

VARA 通常按以下顺序形成监管判断：

业务是否真实、可执行
风险是否被理解与控制
团队是否能持续合规
材料是否支撑上述判断

⚠️ 材料是“证据”，不是“表演”。

23.2 申请递交前的“节奏设计”（成功关键）

23.2.1 为什么很多项目卡在起跑线

失败原因往往不是不合规，而是：

材料之间逻辑不一致
技术、业务、合规不同步
没有“审批节奏管理”意识

23.2.2 递交前必须完成的三项校验

（1）监管一致性校验

业务说明 ↔ 风险评估
风控措施 ↔ 技术架构
人员配置 ↔ 业务复杂度

（2）可执行性校验

是否“写得到、做不到”
是否依赖未来不确定资源

（3）RFI 预判校验

哪些点监管一定会追问
证据是否已准备

23.3 正式递交阶段的策略要点

23.3.1 递交不等于“压满”

VARA 更偏好：

结构清晰
重点突出
风险诚实披露

而不是：

大而全但无重点
回避关键风险

23.3.2 材料版本管理（极其重要）

必须确保：

所有文件版本一致
图表、数字、口径统一
无“旧版本残留”

⚠️ 版本混乱是 RFI 的高频触发器。

23.4 监管问询（RFI）的本质与分类

23.4.1 RFI 不是坏消息

在 VARA 体系中：

没有 RFI 的项目极少
RFI 是正常审批步骤

23.4.2 RFI 的三种类型（实务拆解）

类型一：澄清型（Clarification）

“请进一步说明……”
风险低，节奏可控

类型二：补充证据型（Evidence-based）

要求截图、流程、日志
最常见、最关键

类型三：重构型（Reassessment）

要求重新评估业务或控制
节奏风险最高

23.5 RFI 应答的“黄金三原则”

23.5.1 原则一：逐问逐答，不合并

每个问题单独编号
不跳答、不泛答

23.5.2 原则二：先结论，后证据

推荐结构：

结论一句话
↓
简要解释
↓
证据/附件索引

23.5.3 原则三：不夸大、不承诺未知

VARA 非常警惕：

“未来一定会……”
“计划在后续完善……”

⚠️ 未兑现的承诺，会在后续监管中反噬。

23.6 RFI 应答节奏管理（实操核心）

23.6.1 时间不是越快越好

过快 → 草率、错误
过慢 → 不专业、不重视

23.6.2 推荐节奏（经验值）

收到 RFI 后 24–48 小时内确认收到
若需时间，主动说明预计回复时间
一次性提交“完整版本”

23.7 高发 RFI 问题清单（经验总结）

以下是 VARA RFI 的高频主题：

Custody 私钥控制细节
客户资产隔离证据
AML 交易监控规则
技术日志与审计轨迹
关键人员实际投入程度
外包方的实质控制

23.8 审批节奏失控的典型原因

情形	后果
反复修改同一问题	监管信心下降
回答前后矛盾	重新评估
技术证据跟不上	暂停审查
团队变动	节奏重置

23.9 终审阶段（Pre-Approval）的关键关注点

在接近批准时，VARA 通常重点关注：

是否存在未解决的高风险事项
团队是否稳定
技术是否“随时可上线”

⚠️ 临门一脚阶段，任何变更都需高度谨慎。

23.10 本章交付级总结

VARA 申请不是拼速度，而是拼“监管信任曲线”。

成功项目的特征是：

每一次递交都减少监管不确定性
每一次 RFI 都在“加分”
整个过程像一次专业合作

第 24 章｜处罚与合规风险地图（董事会版）

Enforcement Consequences & Compliance Risk Map（Board-Level View｜交付版）

本章定位（董事会视角）
董事会真正需要回答的问题不是：
“我们是否合规？”

而是：
“如果不合规，会发生什么？谁负责？代价多大？”

24.1 VARA 的处罚哲学（董事会必须理解）

24.1.1 处罚不是目的，纠偏才是目的

VARA 的执法并非“以罚代管”，其核心目标是：

修复风险
纠正治理失效
保护客户与市场

⚠️ 但在反复违规、管理层失职、故意规避的情况下，
VARA 会毫不犹豫升级处罚。

24.1.2 VARA 的处罚层级（从轻到重）

监管关注 / 非正式沟通
书面警告 / 整改指令
限制业务 / 加强监管
罚款 / 管理层问责
暂停或撤销牌照

24.2 合规风险地图（Risk Heatmap）——董事会总览

24.2.1 风险维度定义

董事会应从三个维度审视风险：

发生概率（Likelihood）
影响程度（Impact）
可恢复性（Recoverability）

24.2.2 VARA 重点风险领域热力图（示意）

风险领域	概率	影响	总体等级
客户资产控制	中	极高	●
AML/CFT 失效	中	高	●
未经批准变更	高	中	●
技术与系统缺陷	中	中	●
报告与记录缺失	高	低–中	●

● 红区 = 董事会必须重点监督
● 橙区 = 管理层重点管理
● 黄区 = 可控但需持续监测

24.3 红色风险区（Board-Level Critical Risks）

24.3.1 客户资产与 Custody 失控

风险表现：

钱包权限不清
客户资产与自有资产混用
私钥控制不透明

监管后果：

立即执法
可能暂停业务
高概率罚款或撤牌

24.3.2 AML/CFT 体系实质失效

风险表现：

STR 流于形式
交易监控规则失效
MLRO 缺乏独立性

监管后果：

强制整改
加强监管
管理层问责

24.4 橙色风险区（Management Accountability Risks）

24.4.1 未经批准的重大变更

典型情形：

股权或 UBO 变更未报
新业务先上线后申报

监管后果：

处罚概率高
监管信任下降

24.4.2 技术与外包治理不足

典型情形：

对关键外包缺乏实控
系统日志不完整

监管后果：

要求重构
延期审批或限制业务

24.5 黄色风险区（Operational & Cumulative Risks）

24.5.1 报告迟延与记录瑕疵

特点：

单次影响有限
累积后可能升级

董事会应对：

要求管理层建立指标
定期审阅合规 KPI

24.6 董事会的个人责任与问责边界

24.6.1 VARA 对董事的基本期望

VARA 并不要求董事：

亲自处理日常合规

但要求董事：

理解主要风险
监督管理层
在重大问题上作出判断

24.6.2 董事失职的高风险情形

对明显问题视而不见
明知违规仍批准
无视合规建议

⚠️ 在极端情况下，
个人董事可能面临监管限制或声誉风险。

24.7 可量化的合规后果（董事会决策用）

24.7.1 不合规的“真实成本”

直接罚款
业务中断损失
融资与合作受阻
品牌与声誉损害

24.7.2 “合规投资 vs 违规成本”的对比

项目	成本
合规团队与系统	可预测
一次重大违规	不可控
撤牌	近乎致命

24.8 董事会应采用的合规治理工具

24.8.1 建议的董事会工具包

合规风险季度报告
红区事项专项汇报
重大变更审批清单
独立合规意见

24.8.2 董事会“必须追问”的五个问题

客户资产是否绝对安全？
是否存在未经批准的变更？
STR 是否真实有效？
关键岗位是否稳定？
最坏情况下能否有序退出？

24.9 本章董事会级总结

合规不是“成本中心”，而是“存续条件”。

一个成熟的董事会，必须做到：

看懂风险地图
抓住红区问题
让管理层承担责任
在问题扩大前介入

第 25 章｜迪拜 VARA 在全球牌照版图中的战略定位

Global Licence Strategy & VARA Positioning（董事会战略章节｜交付版）

本章核心结论先行
VARA 不是终点牌照，而是“中东—全球加密业务网络”的战略枢纽牌照。

正确的问题不是：
“要不要 VARA？”

而是：
“VARA 应该在我们的全球牌照组合中扮演什么角色？”

25.1 全球虚拟资产牌照的三种战略定位

从全球实务看，加密/虚拟资产牌照通常承担三类战略角色：

25.1.1 本土零售型牌照（Retail-heavy）

特征：

面向本地公众
强投资者保护
商业灵活度有限

典型示例：

香港 SFC（零售阶段）
部分欧盟成员国 MiCA（零售导向）

25.1.2 护照/区域通行型牌照（Passporting）

特征：

可跨区域展业
规则统一
成本与复杂度高

典型示例：

欧盟 MiCA CASP

25.1.3 枢纽型 / 战略中台牌照（Hub Licence）

特征：

不追求“全球通行”
但成为业务、资本、技术、合规的协调中心

VARA 正是这一类型的典型代表。

25.2 VARA 的核心战略价值（董事会级）

25.2.1 VARA 的四大不可替代优势

中东资本与市场的制度入口
多业务并行许可（8 类活动）
监管预期明确、执行路径可预测
对机构级客户高度友好

⚠️ VARA 的价值不在“最低成本”，而在 “高确定性”。

25.2.2 VARA 最适合承载的功能

VARA 最适合用作：

中东区域总部（HQ）
全球 Custody / Clearing 中台
机构客户主承载实体
集团治理与合规锚点

25.3 VARA + 全球主流牌照的组合策略

25.3.1 VARA + 欧盟 MiCA（最强组合之一）

战略逻辑：

MiCA：欧盟零售与机构市场
VARA：中东机构、跨境资本、OTC

适用对象：

全球化交易所
机构级资产管理平台

25.3.2 VARA + 香港 SFC（亚太 + 中东）

战略逻辑：

香港：亚太投资者保护与声誉
VARA：中东机构流动性与产品灵活度

25.3.3 VARA + 新加坡 / 英国（合规品牌组合）

战略逻辑：

英/新：全球合规背书
VARA：商业落地与产品扩展

25.4 VARA 在集团结构中的“正确位置”

25.4.1 推荐的集团结构定位

在成熟结构中，VARA 实体通常：

不是最顶层控股公司
也不是纯技术外包公司
而是：
关键业务与风险承载实体

25.4.2 VARA 不适合承担的角色

空壳营销公司
仅做“牌照展示”
完全无实质运营

⚠️ 这类结构在 VARA 体系中会被快速识别并否定。

25.5 VARA 与资本、融资、并购的关系

25.5.1 投资人视角下的 VARA

在投资人尽调中，VARA 往往被视为：

“制度成熟但仍具增长潜力”的司法辖区
比纯离岸更可信
比高度成熟市场更灵活

25.5.2 VARA 对 M&A 的支持度

VARA 相对友好于：

股权交易（需审批）
战略投资
集团重组

前提是：

提前规划
透明沟通

25.6 VARA 的中长期战略适配性（5–10 年）

25.6.1 监管趋势判断

从已发布政策与执法方向看：

VARA 正在 稳步加强监管
但不是“急刹车式收紧”
更像 “成熟市场化演进”

25.6.2 对长期经营者的意义

长期主义者受益
短期套利者出清

VARA 正在筛选“留下来的人”。

25.7 董事会级“VARA 使用说明书”

25.7.1 VARA 的正确使用方式

作为全球战略节点
作为机构级业务承载
作为合规能力展示窗口

25.7.2 VARA 的错误使用方式

当作“最便宜牌照”
当作“监管洼地”
当作“无实质过渡牌照”

25.8 本章董事会级总结

VARA 的真正价值，不在于“你拿到了牌照”，
而在于“你知道把它放在哪里”。

一个成熟的全球加密机构，应当：

用 VARA 连接中东
用 MiCA / FCA / SFC 覆盖关键市场
用清晰结构赢得监管信任
用长期规划赢得资本

第 26 章｜《VARA 申请文件清单（Checklist）｜监管递交级（交付版）》

文件定位说明
本《VARA 申请文件清单（Checklist）》用于：

✅ 项目立项自检（Go / No-Go）

✅ 对内分工与进度管理

✅ 对外（董事会 / 投资人 / VARA）说明申请成熟度

清单按 VARA 实际审批逻辑 编排，而非“形式目录”，可直接作为：
-《Application Readiness Checklist》
-《Regulatory Submission Tracker》

26.1 申请主体与公司层面文件（Corporate & Legal）

26.1.1 UAE 实体设立文件（必须）

☐ 公司注册证书（Dubai Mainland / Free Zone，非 DIFC）
☐ 商业登记证（Trade Licence）
☐ 公司章程（MOA / AOA）
☐ 注册地址证明（Lease / Ejari / Flexi Desk Agreement）
☐ 公司组织架构图（Legal Structure Chart）

⚠️ VARA 会重点核查：
实体是否真实、是否具备实质运营条件（Substance）

26.1.2 股东与实益所有人（UBO）文件

☐ 股东名册（Share Register）
☐ 最终实益所有人声明（UBO Declaration）
☐ 股权结构穿透图（100% 穿透）
☐ 股东身份证明（护照）
☐ 股东地址证明
☐ 资金来源说明（Source of Funds / Source of Wealth）

26.2 业务与商业文件（Business & Operating Model）

26.2.1 业务模式说明书（Business Plan）

☐ 商业计划书（3–5 年）
- 业务描述
- 客户类型（机构 / 专业 / 是否零售）
- 收入模式
- 市场定位
☐ 拟申请的 VARA 活动类别说明（8 类中的哪几类）
☐ 不开展业务的明确排除声明（Negative Scope Statement）

26.2.2 产品与服务说明

☐ 产品/服务清单
☐ 客户旅程图（Customer Journey）
☐ 客户资产流转路径图
☐ 费用结构与定价说明

⚠️ “写了没做”比“没写”风险更高

26.3 治理结构与关键人员（Governance & Key Persons）

26.3.1 董事会与管理层

☐ 董事名单与简历
☐ CEO / General Manager 简历
☐ 职责分工说明（Roles & Responsibilities）
☐ 董事会章程（Board Charter）

26.3.2 合规与风控关键人员（重点审查）

☐ Compliance Officer（CO）任命文件
☐ MLRO 任命文件
☐ MLRO 独立性声明
☐ 关键人员 Fit & Proper 资料包
- 简历
- 无犯罪记录
- 监管历史声明

● 关键人员是否“真实在岗”是 VARA 的核心关注点

26.4 合规与风控制度文件（Policies & Manuals）

以下文件构成 VARA 审批核心包（约 60–70% 权重）

26.4.1 AML / CFT 体系（必须完整）

☐ AML/CFT Policy（UAE 本地化）
☐ 风险评估（Enterprise-Wide Risk Assessment）
☐ KYC / CDD / EDD 程序
☐ 交易监控规则说明
☐ STR 提交流程
☐ 制裁名单与黑名单管理

26.4.2 客户与市场行为

☐ 客户适当性与分类政策
☐ 客户投诉处理机制
☐ 利益冲突政策
☐ 市场营销与宣传合规政策

26.4.3 内部控制与治理

☐ 三道防线说明
☐ 内部控制政策
☐ 记录保存与数据管理政策
☐ 变更管理与重大事项申报制度

26.5 Custody、资产隔离与技术文件（Technical & Custody）

26.5.1 Custody 与资产控制（若适用）

☐ Custody 架构说明
☐ 钱包类型说明（Hot / Warm / Cold）
☐ 私钥管理机制
☐ Multi-signature / MPC 说明
☐ 客户资产隔离证明

● Custody 是 VARA 最敏感审查模块之一

26.5.2 技术系统文件

☐ IT 架构图
☐ 系统权限管理说明
☐ 日志与审计轨迹说明
☐ 网络安全与数据保护政策
☐ 灾备与业务连续性计划（BCP / DRP）

26.6 财务、资本与持续经营能力（Financial & Prudential）

26.6.1 财务文件

☐ 初始资本说明
☐ 财务预测（3 年）
☐ 运营成本预算
☐ Wind-down 预算

26.6.2 持续经营能力证明

☐ 流动性说明
☐ 资金来源稳定性分析
☐ 最坏情形下的应对能力说明

26.7 外包与第三方管理（Outsourcing）

☐ 外包清单
☐ 外包尽调文件
☐ 外包协议（草案或签署版）
☐ 外包风险评估
☐ 退出与替代方案

26.8 监管沟通与声明文件（Regulatory Statements）

☐ 向 VARA 的正式申请函
☐ 合规承诺声明（Undertaking）
☐ 无违规历史声明
☐ 信息真实完整声明

26.9 VARA 常见补件（RFI 高频）

建议提前准备（极大缩短审批周期）

☐ Custody 操作演示截图
☐ 系统后台截图
☐ 日志样本
☐ STR 模拟案例
☐ 客户资产隔离证明样本

26.10 Checklist 使用建议（仁港永胜实务经验）

✅ 申请前自检标准

☐ 所有“红区文件”齐备
☐ 关键人员已到位
☐ Custody 与资产路径无模糊点
☐ 没有“未来再补”的核心承诺

❌ 常见致命错误

文件齐，但逻辑不通
制度漂亮，但无法执行
技术存在，但无证据

Checklist 结论（一句话）

VARA 看的是：
你是不是已经在“像一家受监管机构那样运作”。

第 27 章｜仁港永胜交付方案

结论与行动建议｜可执行清单（Final Delivery & Action Plan）

本章定位
本章不是制度说明，也不是法规复述，
而是：
“如果现在就要做 VARA，我们下一步该怎么走。”

27.1 全文核心结论（Executive Conclusion）

基于对 UAE – Dubai VARA 最新监管框架、实务审批节奏及执法趋势的系统梳理，结论如下：

27.1.1 关于 VARA 牌照的本质判断

VARA 是中东地区最成熟、最可预期的虚拟资产监管体系之一
VARA 并非“宽松牌照”，而是规则清晰、执行确定
VARA 适合真实运营、长期合规、机构级业务

VARA 不适合投机型、空壳型、短期套利项目

27.1.2 关于“是否适合你”

VARA 特别适合以下类型的项目：

加密交易所 / OTC / Broker-Dealer
虚拟资产 Custody / 托管
机构级资管 / 借贷 / 清算
Token 发行与结构化项目（合规路径）
希望以迪拜作为中东及全球业务枢纽的集团

27.2 VARA 项目整体行动路线图（One-page Roadmap）

阶段一｜立项与监管定位（0–4 周）

明确申请活动类别（8 大类中哪些）
确认客户类型（机构 / 专业 / 是否零售）
设计集团结构与 VARA 实体定位
初步监管可行性判断（Go / No-Go）

关键产出：
《VARA 监管定位与牌照组合策略说明》

阶段二｜实质建设与材料编制（6–10 周）

UAE 实体设立与 Substance 规划
核心人员配置（CEO / CO / MLRO 等）
全套制度文件（0–26 章对应制度）
技术架构与 Custody 方案确认

关键产出：
《VARA 申请全套制度文件（递交版）》

阶段三｜正式递交与 RFI 管理（3–6 个月）

VARA 正式递交
RFI 预判与应答管理
技术与合规证据补充
监管沟通与节奏控制

关键产出：
《RFI 应答包 + 监管沟通纪要》

阶段四｜获批、上线与持续合规

Pre-Approval → Final Licence
上线前合规检查
持续监管与年度维护
变更管理与扩展规划

27.3 VARA 项目常见失败原因（必须提前规避）

失败原因	真实后果
把 VARA 当“低成本牌照”	项目被否
无实质运营	审批中止
Custody 不清晰	高风险
团队挂名	监管不信任
RFI 应答失控	周期无限拉长

90% 的失败并非法律问题，而是结构与策略问题

27.4 仁港永胜的交付方式（区别于一般顾问）

27.4.1 我们不是“材料代写方”

仁港永胜的角色是：

监管逻辑翻译者
审批节奏管理者
结构与风险设计者

我们关注的是：
如何让监管“点头”，而不是“文件好看”

27.4.2 我们的核心交付能力

VARA 全流程实操经验
多司法辖区（MiCA / SFC / FCA / MAS）协同能力
Custody / Exchange / OTC / 资管实务理解
可落地的制度与技术对齐能力

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

✅ 优势一｜交付级而非“咨询级”

所有内容可直接递交监管
非模板拼凑，而是监管视角重写

✅ 优势二｜真正理解 VARA 的“潜规则”

哪些点监管一定会问
哪些点可以谈
哪些点绝不能碰

✅ 优势三｜长期陪跑，而非一次性项目

获批只是开始
持续合规、扩展、变更才是长期价值

27.6 关于仁港永胜（服务商介绍）

仁港永胜（香港）有限公司
Rengangyongsheng (Hong Kong) Limited

我们是一家专注于：

全球金融与虚拟资产合规
监管牌照申请与持续监管支持
多司法辖区合规结构设计

的专业合规咨询机构。

27.7 联系方式（Contact）

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

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

总部地址：
香港特别行政区西九龙柯士甸道西 1 号
香港环球贸易广场（ICC）86 楼

办公地址：

香港湾仔轩尼诗道 253–261 号依时商业大厦 18 楼
深圳福田卓越世纪中心 1 号楼 11 楼
香港环球贸易广场 86 楼

联系人：

唐生（唐上永｜Tang Shangyong）

业务经理｜合规与监管许可负责人

香港 / WhatsApp：+852 9298 4213
深圳 / 微信：+86 159 2000 2080
邮箱：Drew@cnjrp.com
官网：www.jrp-hk.com

来访提示：请至少提前 24 小时预约。

注：本文所涉完整可编辑 Word / PDF 版本、制度模板、清单包交付件，可向仁港永胜唐生 有偿索取（用于监管递交与内部落地）。

27.8 免责声明（Disclaimer）

本指引仅用于合规研究、监管申请准备及专业咨询参考，不构成法律意见或投资建议。
具体监管要求以 UAE – Dubai VARA 最新法规、监管函件及个案审批结果为准。
仁港永胜不对因单独使用本资料而产生的任何直接或间接后果承担责任。

仁港永胜保留对本文内容更新与修订的权利。

全文讲解完

© 2026 仁港永胜（香港）有限公司 | Rengangyongsheng Compliance & Financial Licensing Solutions
——《阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照申请注册指引》（全文第 0–27 章｜已由 仁港永胜唐生 完整交付）——

如欲查询更多阿联酋·迪拜 UAE – Dubai VARA 虚拟资产服务提供商牌照申请注册指引有关的资料，请与我们仁港永胜的专业顾问联络，我们将为您提供免费咨询服务。[点击联系公司注册专业顾问]

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

上一页： 日本 Japan 加密资产交换业者注册（交易所 / 经纪等）牌照注册指引，Japan crypto license
下一页： 萨尔瓦多 El Salvador 加密交易/虚拟资产服务牌照申请注册指南