欧盟数字运营弹性法案（DORA）管到谁头上？从银行到加密服务商的责任链拆解

一部”出事了找谁”的法律

欧盟《数字运营弹性法案》（DORA，Regulation (EU) 2022/2554）自 2025 年 1 月起适用。它不问你的商业模式赚不赚钱，只回答一个问题：当 ICT 系统出问题——宕机、被攻击、数据丢失、供应商掉链子——金融机构有没有能力继续提供服务、快速把故障隔离、把事件报告上去、并且做压力测试。传统上这类规则管的是银行和券商自己的机房，DORA 的突破在于：它顺着外包链条往上追，把为金融机构提供服务的 ICT 第三方也纳入监督。对关注 RWA 和稳定币的读者来说，这条责任链值得逐环读一遍，因为很多代币化产品的”单点故障”恰恰藏在链条上游，而产品宣传页从不提它。

责任链的三层结构

第一层是金融机构本身。银行、基金管理公司、支付机构要建立 ICT 风险治理框架，登记所有外包给第三方的 ICT 服务，并按统一模板向监管报送。对 RWA 的意义：如果一只代币化货币基金的运作依赖某家链上记账服务商，这家服务商必须出现在基金机构向监管提交的外包登记里。登记本身不担保什么，但”敢登记”和”敢被检查”意味着这条依赖关系已经进入了监管视野。

第二层是 ICT 第三方服务商的分层。所有服务提供者都要接受客户的风险管控，但 DORA 创设了一个特殊类别：关键 ICT 第三方服务商（CTTP）。由欧盟三家金融监管机构的联合委员会认定，标准是服务规模、对金融体系的依赖度、市场集中度、跨境影响。一旦被认定为 CTTP，就直接接受欧洲监管机构的监督：事件报告、审计配合、退出计划、集中度限制。目前多家头部云服务与数据分析公司已进入这个名单，具体名单以监管机构最新公布为准，引用前应核对。

第三层是测试与信息共享。金融机构要做基于威胁的穿透测试，可以委托外部测试团队；同时行业被鼓励共享网络威胁情报。链条的意思很直白：单家机构看不懂的故障，靠行业拼图来补。

它和 MiCA 怎么分工

MiCA 管发行方——储备、赎回、披露、牌照；DORA 管运营——只要一个机构属于 MiFID、支付、电子货币等金融法规覆盖的实体，无论它是否碰加密资产，系统可用性都要达标。交叉点在稳定币：一家按 MiCA 领了牌照的电子货币机构发行欧元稳定币，储备投资由 MiCA 约束，而它用来记账、清算、跑节点的基础设施供应商则落在 DORA 的外包登记里。于是做尽职调查时有了两张清单：MiCA 侧看发行方文件，DORA 侧问一句——这家产品的结算链、预言机、托管接口、云环境分别由谁提供，这些名字出现在机构的 ICT 外包登记里吗？

对用户的三个实际含义

第一，供应商集中是被监管承认的系统性风险。DORA 专门设了集中度评估，说明欧盟监管认为”很多金融机构依赖同一家云”本身就是风险因子——用户在比较两个 RWA 产品时，如果它们的链下基础设施指向同一个云加同一个预言机，表面的多样性其实是同一个故障域。第二，故障报告正在变成可查信号。DORA 框架下重大 ICT 事件要按流程上报，行业也逐步出现事件聚合报告，把一家服务商的故障历史当尽调材料正在变得可行。第三，退出计划不再是客套话。CTTP 层面的要求是：即使服务商消失，客户也能有序迁移。对应到产品端，值得核对的是服务商名单与迁移条款——如果一家代币化基金的估值或转让完全绑定某个单一闭源系统，而合同里没有替代安排，DORA 的退出逻辑提醒你这个结构本身就登记在”需管理”的风险里。

DORA 的执行细则、CTTP 名单和各家机构的登记内容都在持续更新，本文不写死任何名单或日期。本文是法规机制科普，不构成投资建议，也不代表任何产品因涉及受监管服务商就更安全。