监管机构如何审计加密货币交易所:他们检查什么以及如何准备

目录

• 为什么大多数交易所在首次审计中失败
• 监管审计的四种类型
• AML/KYC 控制:让大多数交易所翻船的环节
• 储备金验证与偿付能力证明
• 网络安全与渗透测试
• 运营控制与治理
• 记录保存:最枯燥却最重要的部分
• 审计失败会怎样
• 真正有效的审计前检查清单
• 技术栈如何决定审计成败

在审计真正开始之前,合规要求清单会告诉你检查人员期望看到哪些已配置到位的内容。

为什么大多数交易所在首次审计中失败

我要告诉你一件应该让你有点紧张的事:大约 60% 的加密货币交易所在首次正式监管审计中都会收到重大发现(material findings)。不是无关紧要的观察意见,而是重大发现——那种可能拖延你的牌照审批、限制你的运营,甚至触发执法行动的问题。

我们一次次目睹这样的情况发生。一个团队搭建了扎实的交易平台,撮合引擎运转良好,营销也做起来了,甚至注册了数千名用户。然后监管机构上门进行首次检查,一切戛然而止,因为交易所拿不出六个月前的基本交易记录,或者存档的 AML 政策与系统实际执行的方式对不上。

问题通常不在技术能力,而在准备不足。大多数交易所运营者把合规文档当成打勾任务——为了拿牌照写一次,然后就抛在脑后。而监管机构把它看作一个活的系统,应当随时反映你的实际运营状况。

差距就在这里:你的牌照申请描述的是你计划做什么,审计检查的是你实际做了什么。如果两者对不上,你就有麻烦了。

好消息是?每一个常见的审计失败点都是可以预防的。你只需要知道他们在找什么。

监管审计的四种类型

并非所有审计都一样,弄清自己面对的是哪一种,会改变你的准备方式。

1. 牌照发放前检查

有些监管机构在发放牌照之前,会派检查人员核实你的陈述。迪拜的 VARA 在颁发正式牌照前会进行实地评估。新加坡的 MAS 会开展技术风险评估。MiCA 框架下欧盟各成员国的主管当局也越来越多地在授权前进行实地走访。

他们查什么:你的实际运营是否与申请中描述的一致?你点名的高管是否真的在这里任职?技术栈是真实存在还是纸上谈兵?

2. 例行监管审计

获得牌照后,大多数监管机构会安排定期审计——通常是每年一次或每 18 个月一次。法国 AMF、德国 BaFin 和 MAS 都会开展例行监管审查。

他们查什么:对牌照条件的持续合规情况。你是否维持了自己承诺的控制措施?AML 报告是否按时提交?是否妥善报告了各类事件?

3. 专题审查

监管机构有时会选定一个特定主题,就该主题对多家交易所进行审计。2025 年底,ESMA 针对欧盟六个国家的加密货币交易所客户资产隔离实践开展了一次专题审查。FCA 也对金融推广行为做过类似的审查。

他们查什么:对某一个特定领域进行深入检查。你可能其他方面全都满分,却仍然在他们决定放在显微镜下审视的那个主题上被狠狠敲打。

4. 有因调查

某些事情引发了怀疑——客户投诉、银行提交的可疑活动报告、市场监测标记的异常交易模式,或者举报人。监管机构带着具体的问题上门,态度也远没有那么友善。

他们查什么:引发调查的那件事。这类审计目标明确、节奏快,而且触发执法行动的概率要高得多。

如果想更全面地了解各司法辖区的牌照要求,请参阅我们的加密货币交易所牌照指南。

AML/KYC 控制:让大多数交易所翻船的环节

如果你的交易所会在审计中失败,大概率就是栽在这里。AML/KYC 是监管机构经验最丰富、预期最明确、对漏洞最没有耐心的领域。

审计师实际检查的内容如下:

客户身份识别与验证

他们会抽取一批客户账户样本——通常从不同的风险类别中抽取 20 到 50 个——并逐一追溯你的开户流程。你是否收集了所需文件?是否完成了验证?你的 KYC 系统是否标记了任何异常?验证耗时多久?有没有人在验证完成之前就开始交易?

致命问题是:“给我看一个在开户环节被拒绝的客户,并解释原因。“如果你拿不出被拒绝的案例,审计师会认定你谁都放行——这意味着你的控制措施形同虚设。

交易监测

审计师会查看你的交易监测规则,然后对它们进行测试。他们会问:“什么会触发可疑活动警报?”然后查看你的警报日志。接着,他们会把你的警报与数据中实际存在的可疑模式交叉核对。

常见失败点:纸面上的规则与系统实际行为不符。如果你的政策写明要监测分拆交易(structuring,即把大额交易拆分成多笔小额交易以规避阈值),但你的监测系统里实际上没有分拆交易规则,那就是一项重大发现。

SAR 提交记录

你提交过多少份可疑活动报告(SAR)?什么时候提交的?触发原因是什么?结果如何?

SAR 为零是一面危险信号。这不代表你干净——代表你根本没有在看。任何有一定交易量的交易所都会遇到可疑活动。审计师深知这一点。如果你声称从未见过任何可疑情况,他们会挖得更深。

强化尽职调查(EDD)

高风险客户——政治公众人物(PEP)、来自高风险司法辖区的客户、大额交易者——应当有记录在案的额外审查。审计师会调取你的高风险客户名单,检查 EDD 是否真的执行过。

我们已经在 KYC 合规指南中完整介绍了 KYC 与 AML 合规在实践中的全貌。请在审计之前读它,而不是审计之后。

制裁名单筛查

你是否在根据 OFAC、欧盟和联合国的制裁名单进行筛查?名单多久更新一次?命中时会发生什么?给我看一个命中的案例,以及你当时是怎么处理的。

制裁筛查必须是持续的,而不仅仅在开户时进行。如果某个客户在已通过验证之后被列入制裁名单,你的系统必须能捕捉到。你的合规模块应当至少每天根据更新后的名单执行批量重新筛查。

储备金验证与偿付能力证明

FTX 事件之后,监管机构极其关注交易所是否真正持有其声称持有的资产。多个司法辖区现已要求定期出具储备金证明(proof-of-reserves)鉴证报告。

审计师检查的内容:

• 资产隔离。 客户资金是否与运营资金分开存放?你能否在钱包层面清晰地证明隔离?大多数监管机构希望看到客户资产与公司资产使用独立的热钱包和冷钱包。
• 1:1 足额支撑。 你的客户负债总额(你欠用户的)是否与资产总额(你实际持有的)相符?审计师会将你的内部账本与链上余额进行比对。
• 第三方鉴证。 部分司法辖区要求由独立会计师事务所进行储备金证明审计。即使在非强制地区,做了也会让你领先一步。Armanino 和 Mazars(在其停止此类业务之前)等公司曾为大型交易所提供过这类服务。
• 冷存储验证。 审计师可能要求你用冷存储钱包签名一条消息,以证明你控制着这些钱包。请提前准备好操作流程。你肯定不想在监管机构坐进你办公室的时候,手忙脚乱地去找硬件钱包的密钥。

最常见的错误:

把客户存款挪作运营资金。哪怕是暂时的。哪怕你打算还回去。如果审计师发现客户的 BTC 被转入了交易所的运营钱包——无论出于什么原因——那都是一项重大发现,在某些司法辖区甚至可能构成刑事犯罪。

网络安全与渗透测试

监管机构越来越期望交易所的安全体系能够媲美传统金融机构。VARA 的技术评估尤其细致。MiCA 要求 CASP 具备”健全的 ICT 风险管理”。

审计师希望看到的内容:

• 渗透测试报告。 上一次渗透测试是什么时候?谁做的?发现了什么?你修复了什么?每年一次渗透测试是最低预期。有些监管机构还希望在年度渗透测试之外,看到每季度的漏洞扫描。
• 事件响应计划。 不只是一份文档,而是一个经过演练的计划。审计师可能会问你上一次桌面推演(tabletop exercise)的情况,甚至问你上一次真实发生的安全事件。“我们从未发生过任何事件”并不能让人安心——它反而暗示你没有检测能力。
• 访问控制。 谁有生产系统的访问权限?权限如何授予和回收?是否有多因素认证?管理操作是否有审计日志?
• 密钥管理。 私钥如何生成、存储、轮换和恢复?是否有多重签名要求?是否使用硬件安全模块(HSM)?

你的安全架构应当能产出可直接用于审计的文档。如果不能,你就得在每次审计前花上数周手工整理。

关于强健安全体系的技术细节,我们的安全架构深度解析有具体说明。

审计轨迹问题:

平台上的每一个操作——无论是管理操作还是其他操作——都应被记录。审计师会要求查看特定事件的日志:“给我看你们热钱包过去 30 天的访问日志。""给我看针对这个用户账户的每一次管理操作。""给我看你们手续费配置的变更日志。”

如果你拿不出这些日志,审计师无法判断是真的什么都没发生,还是发生了但你们没有记录。他们会按最坏的情况认定。

你的管理后台是第一道防线。它需要记录每一个操作,包括时间戳、操作者身份、IP 地址,以及任何变更的前后状态。

运营控制与治理

监管机构希望看到你的交易所由称职的人员运营,职责明确、监督到位。

董事会与管理层结构:

• 谁对合规负最终责任?点名。
• 董事会(或同等的监督机构)是否定期收到合规报告?
• 合规问题是否有成文的升级上报路径?
• 管理层中是否有人曾受到过监管处罚?(他们会去查的。)

政策与流程:

审计师会索要你的全套政策文档。至少包括:

• AML/CFT 政策
• KYC 流程
• 风险管理框架
• 事件响应政策
• 业务连续性 / 灾难恢复计划
• 投诉处理流程
• 利益冲突政策
• 市场滥用 / 监测政策
• 数据保护 / 隐私政策

每份政策都应有版本号、负责人、上次审查日期,以及员工培训的证据。两年前写好之后再没更新过的政策,是一面危险信号。

变更管理:

自上次审计以来,你是否上线过新产品或新功能?审计师希望看到你在上线之前(而不是之后)评估过合规影响。“我们六个月前上线了杠杆交易”之后如果对接下来的合规审查问题沉默以对,那就是一项发现。

记录保存:最枯燥却最重要的部分

在交易所建设过程中,记录保存得到的关注最少,却在审计中制造最多麻烦。以下是你需要留存的内容——以及留存期限。

交易记录: 每一笔交易、充值、提现和内部转账。大多数司法辖区要求保存 5 到 7 年。MiCA 规定 5 年。VARA 要求 8 年。MAS 要求业务关系结束后再保存 5 年。

KYC 记录: 所有身份文件、验证结果、EDD 档案以及持续监测记录。留存期限与交易记录相同。

通信记录: 客户支持沟通记录、内部合规沟通记录,以及与可疑活动调查相关的任何通信。是的,这意味着你需要归档客服工单和内部聊天记录。

系统日志: 访问日志、错误日志、变更日志和安全事件日志。至少保存 2 年,但 5 年更稳妥。

格式很重要。 记录必须可检索,并能在合理时间内提供。“数据都在我们数据库里,但需要两周才能导出来”是不可接受的。审计师期望你在收到请求后的 24 到 48 小时内提供特定记录。

从第一天起就把记录留存策略内建到系统架构中。在你已经每年定期清理数据之后,再回头补做五年留存……那可不是一场你想和监管机构进行的对话。

审计失败会怎样

审计结果通常分为四类:

1. 无保留意见附观察项。 你通过了。审计师指出了一些可改进之处,但没有需要立即行动的问题。低调庆祝一下,然后在下次审计前把观察项整改掉。

2. 保留意见附重大发现。 你基本通过,但存在不符合要求的特定领域。你会收到一份整改时间表——通常每项发现给 30 到 90 天。按时完成整改,否则后果自负。

3. 否定意见。 你没通过。存在多项重大发现,甚至可能是系统性问题。监管机构可能会限制你的运营(暂停新用户注册、降低交易量),直到整改完成并验证通过。你大概率还会面临一次提前的跟进审计。

4. 牌照吊销或暂停。 最坏的情况。你的发现严重到让监管机构质疑你是否还应该继续运营。在极端情况下,尤其是当客户资产面临风险时,监管机构可以强制立即暂停业务。

趋势同样重要。如果你第一次审计有 3 项发现,第二次审计变成 5 项,这是个糟糕的信号。监管机构希望看到随时间的改善。情况越来越差,说明管理层没有把合规当回事。

真正有效的审计前检查清单

审计前六周,从这里开始:

第 6-5 周:文档审查

• 调出每一份政策文档。检查版本号和上次审查日期
• 更新所有超过 12 个月未更新的政策
• 验证政策与系统实际行为一致(要实测,不要只读文档)
• 确保所有必需的政策都已具备(参见上文”运营控制”部分的清单)

第 4-3 周:系统测试

• 用样本数据跑一遍你自己的交易监测规则。它们能正确触发吗?
• 随机抽取 30 个客户账户,完整追溯其 KYC 流程
• 检查你的 SAR 提交日志是否完整且为最新
• 验证你能否在 24 小时内提供任意日期范围的交易记录
• 测试你的管理后台审计轨迹——你能否展示过去 6 个月的每一次管理操作?

第 2-1 周:人员准备

• 向你的合规负责人简报可能被问到的问题和举证要求
• 向你的 CTO/技术负责人简报他们可能面对的网络安全问题
• 确保关键人员在审计窗口期内都在岗(不要安排休假)
• 准备一个资料室(实体或虚拟的),把所有文档按主题整理好

审计当天:

• 指定一名对接人,负责管理审计师的各项请求
• 及时响应数据请求。响应速度体现专业程度
• 如果不知道某个问题的答案,就直说。不要猜。“我们今天下班前回复您”好过一个错误答案
• 记录审计师问的每一个问题。他们的问题会告诉你他们关注的重点

技术栈如何决定审计成败

有一点很少有人强调:你的交易所软件是审计成败的最关键因素。不是你的合规团队(虽然他们很重要),不是你的政策文件(虽然那些也重要),而是你的技术。

为什么?因为审计师不在乎你的政策怎么写,他们在乎你的系统怎么做。而他们验证的方式就是从你的系统里调数据。

你的技术栈需要支持的能力:

• 内建审计轨迹。 每一个用户操作、管理操作、系统事件和配置变更都应被不可篡改地记录。如果你的交易所软件不记录管理操作,你就无法证明治理到位。
• 按需报告。 审计师会索要交易报告、KYC 状态报告、SAR 提交记录和系统访问日志。如果生成一份报告需要工程师忙活好几天,你就麻烦了。优秀的交易所软件自带合规报告功能。
• KYC/AML 集成。 你的身份验证、交易监测和制裁筛查应当集成在平台之内——而不是事后外挂。审计师会检查集成点的缝隙。
• 基础设施层面的资产隔离。 你的钱包架构应当在设计上强制实现客户资金与运营资金的隔离,而不是靠政策约束。如果一次人为失误就可能让资金混在一起,那是设计缺陷。
• 可配置的合规规则。 不同司法辖区有不同的阈值、报告要求和监测预期。你的系统应当让你无需定制开发就能完成这些配置。

那些轻松通过审计的交易所,其技术栈会把合规证据当作日常运营的副产品自动生成。如果你的团队需要手工汇编审计证据,那说明你的架构出了问题。

---

参考资料与延伸阅读

• FATF 虚拟资产风险为本方法指引 — 金融行动特别工作组(FATF)
• MiCA 条例 — 第五章:CASP 义务 — 欧洲议会
• VARA 合规与风险管理规则手册 — 迪拜虚拟资产监管局(VARA)
• MAS 技术风险管理指引 — 新加坡金融管理局(MAS)
• IOSCO 关于加密资产交易平台相关问题、风险与监管考量的报告 — IOSCO