DORA 信息登记册怎么都对不上：修表格，还是做数据项目？
从被退回的 DORA 登记册行出发，逐一核对使用实体、合同、ICT 服务商、服务类型与功能，判断问题应由谁负责，以及工作是否已超出单次表格修补。
重点监测信号
- 被退回的文件或演练错误能指出具体 DORA 模板、栏位或无法对齐的关系
- 同一个实体、合同、服务商、服务或功能标识在不同模板或记录系统中不一致
- 下一次监管提交、整改会议或实施决定有明确日期
DORA 信息登记册对不上，并不自动等于需要买一套新系统。先找到被退回的那条关系：谁是实际使用 ICT 服务的金融实体，合同参考号是什么，服务商用哪个标识，这是什么 ICT 服务，又支撑哪项功能；然后再看哪个记录负责人无法稳定复现同一个值。 一处有权威来源的单元格错误，可以局部修正；同一组连接键在多份合同、多个实体或不同系统里持续冲突，才指向数据整改。
这项判断属于监管数据平台商务负责人。他会查看企业主动连接且有权访问的银行运营、金融科技合规和 ICT 外包 Telegram 群。真正值得停下来的 Signal，不是“DORA 表坏了”，而是有人说出具体模板或关系，并且下一次监管提交、试运行或整改会议已经有日期。晚一天看到，买方可能已经把数据工作交给别人，或完成了范围确认；但把每一份退回的工作簿都当成平台项目，同样会把时间浪费在格式错误上。
先定义登记册记录，再判断哪里坏了
DORA，即 Regulation (EU) 2022/2554，要求金融实体维护和更新一份信息登记册，记录其使用 ICT 第三方服务商所提供 ICT 服务的合同安排。第 28 条规定，登记册要在实体层级维护；适用时，还要覆盖次级合并（sub-consolidated）和合并层级。登记册还要区分哪些合同支持关键或重要功能，哪些不支持。
Commission Implementing Regulation (EU) 2024/2956 给出了标准模板。条例序言把它们描述成预设栏位、行数不固定、通过特定键连接的开放式表格。连接不同模板的关键包括：
- 合同安排参考号；
- 金融实体或 ICT 第三方服务商的标识；
- 功能标识；
- ICT 服务类型。
所以，一份表每格都填满，仍可能无法通过校验。合同可能已经出现在 B_02.01，服务商已经出现在 B_05.01，功能也已经出现在 B_06.01，但 B_02.02 的一行仍然无法把三者稳定地连在一起。坏掉的是关系，不是空格数量。
把退回的那一行当作分流地图
下面是示意性复合消息，不是实际银行、监管提交、客户或主管机构回复。
“RoI 文件退回了。B_02.02 的 provider ID 和合同清单对不上，截止日很近。”
这里的 RoI 是 register of information，即信息登记册。
另一个授权群里，稍后又出现一句：
“集团云合同。三个实体在用，一家共享服务公司签的。各国 function code 还不一样，不确定这行该放哪个 LEI。”
这组消息值得复核，因为它给出了模板、服务商连接错误、多个使用实体和时间窗口。但它还不是一个合格项目：不知道合并层级、退回的栏位代码、服务商标识、合同层级、ICT 服务类型、关键性、数据源、分包链、提交路径、预算与决策人。
先取得一份获准查看的校验结果，原样保留模板号、栏位号和错误文字，再按以下关系找负责人：
| 错误位置 | 官方模板要连接什么 | 第一份要看的材料 | 最先确认的负责人 |
|---|---|---|---|
| 实体 | B_02.02 中实际使用 ICT 服务的金融实体及其 LEI | 合并范围、使用实体 LEI、B_04.01 的实体记录 | 监管报送或集团数据治理 |
| 合同 | B_02.01 中为独立合同、主合同或关联合同分配的唯一参考号 | 已签合同、主合同与订单层级、内部合同号 | 采购或合同管理 |
| 服务商 | B_02.02 与 B_05.01 共用的 ICT 第三方服务商标识 | 法定名称、适用的 LEI 或 EUID、直接签约方 | 第三方风险或供应商主数据负责人 |
| 服务与功能 | 一项 ICT 服务类型与该金融实体的功能标识 | 服务描述、附件 III 服务类型、持牌活动及 B_06.01 功能记录 | ICT 服务负责人和业务功能负责人 |
签合同的实体，不一定就是使用服务的金融实体。B_03.01 的填写说明明确考虑了两者不同的情况，集团结构下尤其常见。如果共享服务公司代表三个受监管实体签云合同，直接把签约方标识复制到所有“使用实体”栏位，表面整齐，关系却可能是错的。
沿一条关系查到底
回到上面的复合消息。假设退回项指向 B_02.02，也就是合同安排的具体信息模板。这一行需要同时组合合同参考号、使用服务的金融实体 LEI、服务商标识、功能标识和 ICT 服务类型等值。
先看合同参考号。B_02.01 要求内部参考号具有唯一性、随时间保持一致，并在整份登记册里一致使用。它可以代表独立合同、总括或主合同，也可以代表订单等后续安排；从属于这些合同的服务水平协议本身，不作为这里所说的合同参考号。
不要马上改表，先依次验证：
- 该合同号在合同库与 B_02.01 中，是否都指向同一份主合同或订单？
- “使用实体”LEI 是否属于真正接收该服务的金融实体，而不只是代签合同的集团公司？
- 服务商标识是否在 B_05.01 指向同一个法定主体，也确实是合同中的直接服务提供方？
- 功能标识是否能在 B_06.01 对应到同一个实体 LEI、持牌活动与功能组合？
- ICT 服务类型是否准确描述这份合同为该项功能提供的服务？
如果第二项和第四项只在某个国家失败，最先要找的是实体与功能负责人，重排服务商栏位解决不了问题。如果采购、供应商风险和报送文件对同一份合同给出不同编号，那么不稳定的是合同键。即便一个公式能让今天的导出通过，这也已经不只是表格排版。
判断修正是否应停在工作簿里
同时满足以下条件时，局部修表比较合理：
- 已经知道退回的模板、栏位和受影响行；
- 一份权威来源与一位明确负责人能确认修正值；
- 修正后，所有相关模板仍使用同一组参考号；
- 下一次导出或另一个实体不会再次生成同类错误。
如果团队每次都要人工重建关系，数据整改项目就更合理。例如：合同参考号在多个系统间变化，一个法定服务商有数条主数据，多个集团实体对同一服务使用互不兼容的映射，或每次提交前都要临时拼出功能标识。这些不是几颗“坏单元格”，而是源记录无法稳定生成官方关系。
问题严重不等于有外部预算，问题小也不等于无需外部服务。只有失败模式、负责人和决定日期都明确后，商务沟通才进入项目范围。
报价前先问清六件事
讨论平台、迁移或托管数据服务前，先问：
- 失败发生在哪个登记册层级：实体、次级合并还是合并？
- 被退回的是哪个模板、哪个栏位代码，校验信息原文是什么？
- 不一致的是使用实体、合同、服务商、服务类型还是功能？
- 这条关系两端各自以哪个系统为权威来源？
- 谁能批准修改标识或映射？
- 下一次试运行、监管要求、整改会议或正式提交是哪天？
这些问题不替代法律解释，也不能保证主管机构接受修正后的登记册。它们只负责分清：买方需要一处有责任人的修正、系统之间的对账规则、主数据清理，还是一套可重复生成登记册的过程。
如果遇到的是另一类合规材料请求，SOC 2 上线审核需求分流展示了所需材料怎样改变服务路线。群里只有监管说法、没有实际退回信息或模板时，先用官方来源阶梯找对证据。
群讨论用来发现窗口，不能用来认证错误
TOP Prospect 可以连接用户主动授权的 Telegram 群讨论片段，保留原文、来源和时间，清理明确重复项，并把复合讨论排入人工复核。它不能访问登记册、验证模板、认定法定主体、解释 DORA、联系发言人或确认采购项目。
工具做到“让残缺请求可以被查看”就停下。商务负责人仍要取得获准查看的校验结果、找到记录负责人并确认决定日期。合规变化如何形成商业窗口，可继续阅读监管驱动需求信号。
第一次复核的结论应该很窄：如果一位负责人能从权威来源对齐一行，而且所有相关模板继续使用一致的连接键，就把它交给受控修正；如果没人能稳定重现“实体—合同—服务商—服务—功能”这条关系，就进入数据发现沟通。工作簿被退回只是症状；这条关系能否重复生成，才决定它是不是一个项目。
常见问题
DORA 信息登记册是什么？
它记录金融实体使用 ICT 第三方服务商所提供 ICT 服务的合同安排。DORA 第 28 条要求金融实体在实体层级以及适用的次级合并、合并层级维护并更新该登记册。
哪些值连接 DORA 登记册的不同模板？
实施条例（EU）2024/2956 列出四类连接键：合同安排参考号、金融实体与 ICT 第三方服务商标识、功能标识以及 ICT 服务类型。
什么情况下，被退回的 DORA 表格只需局部修正？
如果出错行和负责人明确、权威来源一致、修正不会破坏相关模板，而且下一次导出不会再次生成同一错误，就可能只是局部修正。
什么情况下，DORA 登记册整改已经是数据项目？
当标识在多个实体或系统之间冲突、合同层级不稳定、服务商主数据重复，或服务与功能的映射每次都要人工重建时，更接近数据项目。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
