合规指南
您提交了。您等待了。随后反馈文件到了，里面有一个您从未见过的规则代码，却没有用通俗语言解释它是什么意思。本文根据 ESAs 实际发布的内容，而不是网上的猜测，将拒绝代码映射到其原因。
更正已于 2026 年 7 月 14 日重写。本文早期版本将登记册描述为从 “B00” 到 “B06” 的表格，但这并不是登记册的结构。真实结构是 Commission Implementing Regulation (EU) 2024/2956 中规定的 15 个官方模板，即 B_01.01 至 B_99.01。该版本还声称存在由 “117 条 EBA 规则” 构成的验证引擎、一张拒绝频率表、一个虚构的 CSV 文件命名约定、CSV 文件必须位于 ZIP 根目录的说法，以及某支付机构提交失败的完整示例。这些内容均无法找到来源，现已全部删除。以下每一项拒绝原因现在均可追溯至 ITS 或已发布的 ESA 文件；并且，早期版本列出的若干原因，根据 ESAs 自己发布的证据，实际上根本不会导致拒绝。
⚡ TL;DR
ESAs 已发布其在信息登记册报告中看到的最常见错误，并附有一列说明每项错误是否会导致拒绝。其中有 7 项会导致拒绝：外键违规（807）、缺失主键（805）、申报指标问题（808）、非 DORA 文件或大小写错误的文件（720）、与文件名不匹配的 entityID（714）、报告文件结构问题（103），以及不在分类标准中的表头代码（801）。有 5 类常见错误不会导致拒绝，包括缺失强制值和 LEI 错误。如果您陷入反复重新提交的循环，最快的出路是先修复这 7 类会导致拒绝的问题，并理解单个无法解析的文件可能会连锁触发大量外键错误，而这些外键错误本身并没有独立原因。
提交后实际会发生什么
您的提交是一个报告包。EBA 在其关于为 DORA 准备普通 CSV 报告包的指南中规定了该报告包的结构。ZIP 以报告主体命名，内部包含一个 reports 文件夹和一个 META-INF 文件夹。reports 文件夹包含 report.json、parameters.csv、FilingIndicators.csv，以及每张表对应的一个 CSV。META-INF 包含 reportPackage.json。
ZIP 命名模式
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip
EBA 自己给出的示例：
DUMMYLEI123456789012.CON_IT_DORA010100_DORA_2024-12-31_20240821141632000.zip
报告主体是您的 LEI。.CON 或 .IND 标识合并提交或单体提交。并且 parameters.csv 内的 entityID 参数必须与之匹配：如果不匹配，ESAs 会触发错误 714，而 714 会导致拒绝。
随后，检查会分层运行。EBA 在一份文件中对此作出说明，该文件的完整标题是：EBA 针对 RoI 报告适用的技术检查、验证规则和业务检查概览。技术检查关注报告包本身：结构是否正确，文件名是否正确，编码是否为 UTF-8。数据点模型规则关注表格：表头代码是否在分类标准中，关键列是否已填写，外键是否能够解析。业务规则关注内容：该 LEI 是否真实，该 EUID 是否存在。
⚠️ ESAs 对其自身文件提出的一项注意事项
已发布的观察结果附有明确提示：该材料反映的是 ESAs 报告基础设施的设计，并且“主管机构在其用于收集金融实体信息登记册的报告解决方案中实施的验证检查和反馈消息，可能不同于这些幻灯片中说明的内容”。您实际提交申报的是您所在 NCA 的门户。请结合其技术指南一并阅读。
ESAs 实际看到的错误，以及哪些会导致拒收
2025 年 4 月，ESAs 发布了一组来自信息登记册报告测试的观察结果，并于 2025 年 5 月更新，按规则代码列出了最常见的错误。关键是，该清单包含一列，说明每项错误是否会导致拒收。我们在下方复现该映射，因为它重新排列了大多数整改计划一开始设定的优先级。
这种重新排序比听起来更重要。整改计划几乎总是从数据入手，因为糟糕的数据看起来像是严重问题，而文件名似乎无关紧要。按照 ESAs 自己的映射，情况恰恰相反。如果团队先花两周清理服务提供商记录，再去修正一个大小写错误，那么再次提交时仍会因同一原因被退回。
| 规则代码 | 说明 | 导致驳回 |
|---|---|---|
| 807 | 违反外键约束 | 是 |
| 805 | 缺少主键 | 是 |
| 808 | 缺少申报指标，或大小写错误 | 是 |
| 720 | 报告了非 DORA 文件，或大小写错误 | 是 |
| 714 | entityID 参数与文件名不匹配 | 是 |
| 103 | 报告文件结构、内容 | 是 |
| 801 | 所有表头代码必须在分类标准中 | 是 |
| v8886_m, v8850_m, v8885_m, v8884_m, v8888_m, v88889_m | 缺少必填值 | 否 |
| VR_71, VR_23, VR_12, VR_77 | 报告的 LEI 错误 | 否 |
| 806 | 对于开放表，不能报告相同的键值 | 否 |
| VR_72 | 在 BRIS 中未找到 EUID 代码 | 否 |
| v8826_m | LEI 掩码有效性 | 否 |
请再看一遍那张表。缺失强制值不会被拒收。错误的 LEI 不会被拒收。无效的 LEI 掩码不会被拒收。未在商业登记互联系统中找到的 EUID 不会被拒收。开放表中的重复键不会被拒收。这些都是真实的数据质量问题，也都会反馈给您，且您的主管机构在其自己的门户中可能会有不同看法，但根据 ESAs 已发布的映射，它们并不是导致您的包被退回的原因。真正导致包被退回的是结构：键、引用、文件名、填报指示符、编码和表头。
807：外键违规及其背后的级联问题
外键违规是 ESAs 表中的第一行，并且会导致拒收。信息登记册是关系型的：ITS 第 5 条列出的 15 个模板，会通过您分配的标识符相互引用。其中最重要的是合同安排参考编号。第 5 条和 Annex I 说明明确规定，对于每项与直接 ICT 第三方服务提供商订立的合同安排，实体“应分配一个唯一的‘合同安排参考编号’，以明确识别该合同安排本身”。
ESAs 自己给出的 807 失败示例是：一个合同安排参考编号出现在 B_07.01（评估模板）中，但没有出现在 B_02.01（合同安排一般信息）中。该值是存在的，只是无法解析。
没人提醒您的级联问题
下面这个部分会让团队陷入反复重新提交的循环，而且直接来自 ESAs 的幻灯片。如果一张表根本无法集成，那么对该表的每一个引用都会失败。他们举例说明会阻止表集成的情况包括：801 错误，即表头列代码未在分类标准中定义；以及 805 错误，即键列为空。其关于后果的说明是：“那么许多 FK 都可能失败，其他表也会引用加载失败的表。这是预期行为，数据库系统会因此失败。”
2025 年 5 月 1 日新增的规则 809，正是为了解决这个问题。如果 CSV 无法解析，因为内容中的列数与表头不匹配，ESAs 指出，如果我们一开始就无法集成目标表文件，“提交方很难理解这就是 807 的原因”。因此，现在 809 会直接告诉您。
实际后果：当您收到包含 50 个 807 的反馈文件时，不要一开始就修 50 个引用。请先查找 801、805 或 809。单个无法解析或无法加载的表，可能会生成任意数量的下游外键错误，而这些错误本身没有独立原因；修复上游的一个问题即可全部清除。
打包、文件名和填报指示符
7 个拒收代码中有 4 个与数据无关，而是与包本身有关。一旦您知道规则，它们也是最容易修复的，但这些规则并不直观。
这是该报告制度最令人恼火、也最难自圆其说的部分。小写文件名或大写填报指示符本身，并不能保护任何一个消费者；这些规则主要还得通过阅读幻灯片来发现。正确的做法是把它们一次性编码进生成包的任何工具中，然后就再也不用为它们分心。
720：文件名和大小写
表文件必须使用小写命名，例如 b_01.01.csv。ESAs 的幻灯片显示，小写文件名会被接受，大写文件名会被拒收，额外或错误的文件名也会被拒收。规则 720 放宽后，现在缺失文件会被接受，但不应出现在包中的文件仍会导致包被退回。
808：填报指示符
这一项会影响那些合乎情理地认为“如果某个模板没有内容可报，就应该说明这一点”的人。规则并不是这样。所有 DORA 模板都被视为预期模板。模板 ID 必须以大写形式出现在 FilingIndicators.csv 中，因此是 B_01.01，而不是 b_01.01，即使 CSV 文件本身采用小写文件名。每个已报告的模板 ID 都必须声明为 true，其中 1 可作为 true 值。如果模板没有任何内容可填，可以空表报告。但是，按 ESAs 的说法，“已报告的模板 ID 如果声明为 false 或取值为 0，将因 808 填报指示符错误而被拒收”。
714：entityID 必须与文件名匹配
parameters.csv 中的 entityID 参数必须与 ZIP 文件名中的报告主体一致。parameters.csv 的表头行也必须正确：2025 年 5 月 1 日新增的规则 723 要求表头只能由 name 和 value 组成，并且按此顺序排列，因为在 XBRL 标准中，名称出现在值之前。
103 和 306：结构与编码
103 是报告文件结构检查。306 是编码检查：包中的每个文件都必须是 UTF-8。该项于 2025 年 5 月 1 日被移至失败规则，理由是非规范 UTF-8 文件会导致文本数据损坏。带字节顺序标记的 UTF-8 可以接受。
⚠️ 两个广为流传但并不正确的说法
列顺序并不重要。 ESAs 明确说明，在表格 CSV 中，“列名可以按任意顺序出现”，并发布了一个交换了两列位置的有效示例。列名区分大小写且为小写，表头行不得包含空单元格，但列的顺序是自由的。
CSV 并不位于 ZIP 的根目录。 报告包包含一个
CSV 并不位于 ZIP 的根目录。 报告包包含一个
reports 文件夹和一个 META-INF 文件夹。扁平的 CSV 归档并不是门户预期的结构。数据类型：让所有人踩坑的 eba_ 前缀
EBA 的打包指南为各列规定了七项数据类型规则。这些规则很简短，值得逐字阅读，因为第三项规则正是大量本可避免的麻烦的来源。
如果您的登记册保存在电子表格中，仅这一条规则就足以说明，应当用脚本导出，而不是手工编辑。人们会按照阅读习惯输入国家代码，而分类法要求采用带所有者前缀的形式。没有人能在整个申报季中对成千上万个单元格持续保持这种纪律。
| 类型 | 分类法要求 |
|---|---|
| 字符串（字母数字） | 字符串值。如果其中包含分隔符字符，即逗号，则该值必须用双引号括起来。 |
| 日期 | 必须采用 yyyy-mm-dd 格式。 |
| 枚举（封闭选项集） | 必须是带注释模板下拉列表中的值，并且带有所有者前缀 eba_。EBA 给出的国家示例是 eba_GA:AT。这是整个包中最容易被误解的一条规则：单独的 AT，或单词 Austria，都不是分类法所期望的枚举值。 |
| 布尔值 | 必须为 true 或 false，或 1 或 0。 |
| 货币 | 必须以单位表示，而不是以千或百万表示。EBA 的示例是 2540100.23。 |
| 整数 | 必须为整数。 |
| 键列 | 如果该列是键，则必须填写。空的键列会触发规则 805，且 805 会拒收。 |
ITS 附件 I 中的说明从概念上描述了国家字段，即 ISO 3166-1 alpha-2 代码，以及货币字段，即 ISO 4217 字母代码。这是字段的含义，并不是您在 CSV 中输入的内容。在报告包中，枚举值带有所有者前缀，这就是为什么 EBA 给出的国家值示例是 eba_GA:AT，而不是 AT。parameters.csv 中的基础货币在 EBA 示例中显示为 iso4217:EUR。如果您的导出写入的是人类可读代码，分类法将无法识别。
LEI 和 EUID：不会导致拒收的真实问题
ITS 第 3(5) 条要求金融实体使用“有效且处于活动状态的法人实体识别编码（LEI）或欧洲唯一标识符……（‘EUID’），并在可获得的情况下同时使用这两种标识符，识别其所有作为法人的 ICT 第三方服务提供商，但以商业身份行事的个人除外”。第 3(6) 条通过直接服务提供商，将同一要求延伸至实际支撑关键或重要职能相关服务的分包商。
请注意“valid and active”这几个词。结构上正确但已经失效的 LEI 并不是有效在用的 LEI。ESAs 会针对 GLEIF 数据库的缓存副本运行业务校验规则，因此错误的 LEI 会被发现。它会以 VR_71、VR_23、VR_12 和 VR_77 等代码反馈。根据 ESAs 已发布的映射，这类问题不会导致提交被拒绝，但这并不是放任错误不改的理由：信息登记册必须准确，ITS 第 3(3) 条要求您定期审查，并“及时纠正发现的任何错误或不一致”。
LEI 掩码，精确定义
EBA 适用的规则 v8826_m 是一个正则表达式：^[A-Z0-9]{18}[0-9]{2}$。18 个 A 到 Z 或 0 到 9 的字符，后接 2 个数字。总共 20 个字符。请注意，前 18 个字符可以是字母或数字，因此凡是坚持 LEI 开头字符必须是字母的描述，就实际校验器强制执行的掩码而言都是错误的。
EUID 不是 LEI 的另一个名称
EUID 是来自商业登记互联系统的欧洲唯一标识符。当上报的 EUID 在该系统中找不到时，就会触发 VR_72。ESAs 列出了可避免的原因：把 LEI 标记为 EUID，以及上报的 EUID 不符合 EUID 模式。它们提出的两个简单检查是：EUID 应包含一个点，并且应以 EEA 国家/地区的两字母 ISO 代码开头。在其公布的测试统计中，无效 EUID 格式在 EUID 结果类别中占比远高于其他类别，使“已找到”和“未找到”两类都相形见绌。
有一个后果值得明确说明，因为它来自 ITS，而不是来自校验器：在第三国设立的服务提供商仅使用 LEI 识别，因为 EUID 是欧洲标识符。给 US 或印度服务提供商填入一个看起来像 EUID 的值是行不通的。
一旦知道这些代码不会导致拒绝，您可能会想把它们留到明年再处理。不要这样做。标识符治理是信息登记册中成本最低的质量工作：在录入时做一次 GLEIF 查询只需几秒，而事后查清哪些服务提供商带着已失效标识符，可能要耗费某个人一周的时间。
必填值和重复键
必填值规则采用 v8886_m 等形式，它们是数据点模型中的条件断言。ESAs 给出的示例大意是，对于 B_07.01，c0080 列为必填，并展示了两种不同的失败方式：该列完全从文件中缺失，或者该列存在但未填写值。两者都会产生相同代码。
规则 806 是重复键规则：对于开放表，不能上报相同的键值。如果您将同一个键上报两次，就会被标记。根据 ESAs 的映射，这两类问题都不会导致拒绝。两者都是真正的数据质量失败。ITS 第 3(4) 条规定了您的信息登记册数据必须满足的六项原则：准确性、完整性、一致性、完好性、统一性和有效性。一个虽然通过门户、却违反这些原则的信息登记册，除了拿到一张回执，并没有真正达成任何目标。
一条容易出错的结构性规则。 ITS 第 4(2) 条：“金融实体应为每个数据元素填写单一值。对于某一特定数据元素，如有多个有效值，金融实体应在相应模板中为每个有效值增加一行。”两个国家/地区，两行。不是在一个单元格里填两个国家/地区。
提交前检查清单
在申报前运行这项检查。它不能发现所有问题，也不能替代您的 NCA 实际运行的规则集，但它覆盖了会导致拒绝的 7 个代码及其背后的结构性规则。
第一次逐项完成需要一个下午，此后只需几分钟，因为其中大多数是您的导出流程的属性，而不是今年数据本身的属性。这种不对称，正是应修复流水线而不是修补包文件的全部理由。
包和文件名
- ZIP 名称遵循
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip模式，其中您的 LEI 作为报告主体。 parameters.csv中的entityID与 ZIP 文件名中的报告主体一致。不一致属于规则 714，714 会拒绝。- 表文件名使用小写，例如
b_01.01.csv。EBA 幻灯片显示，使用大写文件名会根据规则 720 被拒绝。 - 包中包含
reports文件夹，以及带有reportPackage.json的META-INF文件夹。CSV 文件不能散放在 ZIP 根目录下。 - 包中不得包含非 DORA 文件。多余或错误的文件名会根据 720 被拒绝。
- 每个文件均为 UTF-8。自 2025 年 5 月 1 日起，非 UTF-8 文件属于规则 306，并会失败。带 BOM 的 UTF-8 可被接受。
报送指示符
FilingIndicators.csv以大写列出模板 ID，例如B_01.01。- 每个已报告的模板 ID 均声明为
true（或1）。声明为false或0的模板 ID 会根据规则 808 被拒绝。 - 没有可报告内容的模板应作为空表包含在内，不能省略，也不能声明为 false。
键和引用
- 每个键列均已填充。空键属于规则 805，并会被拒绝。
- 每个外键都能解析。EBA 的示例是：B_07.01 中存在的合同安排参考编号，如果在 B_02.01 中不存在，会因 807 而失败。
- 表头行不得包含空单元格，也不得包含分类体系中不存在的列代码。两者都属于规则 801，且某个表上的 801 失败可能会在指向该表的其他表中级联引发一系列 807。
- 每个 CSV 中的行数和逗号数量都与表头匹配。解析失败属于规则 809，并会产生同样的下游级联问题。
数据类型
- 日期格式为
yyyy-mm-dd。 - 每个枚举值都带有
eba_所有者前缀。 - 货币金额按单位填写，而不是按千为单位。
- 包含逗号的值需要加引号。
标识符
- 每个 LEI 都符合 EBA 适用的掩码：
^[A-Z0-9]{18}[0-9]{2}$，即 18 个 A 至 Z 或 0 至 9 的字符，后接两位数字。 - LEI 会对照 GLEIF 进行检查，因为 ESA 会基于 GLEIF 数据库的缓存副本运行商业规则。
- EUID 不是 LEI。EBA 的指引是，EUID 包含一个点，并以 EEA 国家/地区的两字母 ISO 代码开头。
当拒绝信号指向更深层问题
如果您修正后相同错误仍反复出现，问题通常不在执行层面，而在于信息登记册是在一个无法保持其结构稳定的工具中组装的。
首次申报被拒一两次是正常且并不罕见的，任何人都不应把它理解为团队失败。第四次、第五次被拒，就说明流程本身存在问题。到那时，明智的做法是停止修改输出文件，转而查看数据存放在哪里。
信息登记册是一个关系型数据集。合同安排参考编号是多个模板指向的键。根据 ITS，功能标识符必须针对金融实体 LEI、持牌活动和功能的每一种组合保持唯一，ITS 还给出了这一点的完整示例。一个 ICT 服务供应链中的所有服务提供商必须共享同一个合同安排参考编号和同一种 ICT 服务类型。层级是自然数，直接服务提供商始终为 1，分包商始终大于 1。这些都是完整性约束。电子表格不会强制执行完整性约束，它只存储文本。
| 必须成立的规则 | 在电子表格中 | 在对信息登记册建模的系统中 |
|---|---|---|
| 每个外键都能解析 | 通过查询公式人工检查。当一个选项卡中的标识符被编辑而其他选项卡未同步时，会悄无声息地出错。 | 该引用是记录之间的关系，因此不能指向空对象。 |
| 关键列永不为空 | 没有任何机制阻止空单元格。 | 缺少键的记录无法保存。 |
| 枚举值带有 eba_ 前缀 | 下拉列表会提示取值，自由文本可以覆盖它。 | 用户选择的是业务语言标签；代码在导出时应用。 |
| 错误在申报前发现 | 由门户在提交尝试之后发现。 | 在生成包之前，通过对数据模型执行校验发现。 |
这正是 Venvera 信息登记册模块所做的事情。服务提供商、合同安排、实体、功能、供应链和评估是相互链接的记录，而不是一个个选项卡。用户使用业务语言工作，生成申报包时再应用 ESA 代码。完整性视图会在导出前显示校验问题，每个问题都标注其所属模板和字段，并标记为错误或警告。导出会按照 ITS (EU) 2024/2956 表结构，基于全部 15 个官方模板 B_01.01 到 B_99.01 生成 xBRL-CSV 包。可以在服务提供商表单中通过 GLEIF API 查询服务提供商，返回已注册的法定名称和注册状态，因此失效的 LEI 会在您录入时就可见，而不是等到反馈文件中才发现。
我们不会声称这能保证被接受。规则集有版本管理，ESAs 会对其进行修改，您的 NCA 可能运行自己的检查，ESAs 自己也明确说明了这一点。数据模型带给您的，是将导致拒收的那类结构性错误在很大程度上从设计上排除，而不是事后再测试。
常见问题
信息登记册中最常见的错误都会导致被拒收吗？
不会，这也是 ESAs 已发布观察中最有用的一点。在 ESAs 列出的十二类最常见错误中，有五类被标注为不会导致拒收：强制值缺失、报告了错误的 LEI、开放表中的键值相同、在 BRIS 中找不到 EUID，以及 LEI 掩码有效性。会导致拒收的七类错误包括外键违规 (807)、主键缺失 (805)、filing indicator 问题 (808)、非 DORA 文件或大小写错误的文件 (720)、与文件名不匹配的 entityID (714)、报告文件结构问题 (103)，以及不在 taxonomy 中的表头代码 (801)。ESAs 还提醒，各国家主管机构在其自身报告解决方案中实施的检查和反馈消息，可能不同于该文件中描述的内容。
反馈文件中的规则代码是什么意思？
它们是报告系统所应用的具体校验规则的标识符。100、700 和 800 段的数字代码，是对报送包进行的技术和结构性检查。v8826_m 这类格式的代码，是以断言形式表达的数据点模型规则，因此 v8826_m 表示某个值必须匹配 LEI 掩码的规则。VR_71 这类格式的代码是业务校验规则。EBA 会在其校验规则包中发布规则集，并在关于常见问题的幻灯片中，通过示例逐步说明常见规则。
为什么一个损坏的文件会产生数十个外键错误？
因为它破坏的那张表根本没有加载成功。ESAs 解释称，如果某个模板无法集成，例如表头列代码不在 taxonomy 中 (801)、键列为空 (805)，或 CSV 无法解析 (809)，那么所有引用该失败表的其他表，也会在外键检查中以 807 失败。他们对此的说明是，这是预期行为，数据库系统也会出于同样原因失败。因此，应先排查 801、805 和 809 错误：一大批 807 往往只有一个上游原因。
空模板可以不放入报送包吗？
不可以。根据规则 808，所有 DORA 模板都应提供，模板 ID 必须以大写形式出现在 FilingIndicators.csv 中，并且每个已报告的模板 ID 都必须声明为 true。没有内容需要报告的模板，应作为空表提交，而不是省略，也不是声明为 false。这里还有一个最低要求：2025 年 5 月 1 日引入的规则 724，是因为如果一个报送包中所有文件都为空，将不会产生任何审计发现；ESAs 指出，即使没有外部服务提供商合同的实体，也至少需要报告 B_01 模板。
如果 ICT 服务提供商没有 LEI 怎么办？
ITS 要求，对于作为法人的每一家 ICT 第三方服务提供商，都提供有效且处于有效状态的 LEI 或 European Unique Identifier (EUID)，在两者均可取得时还需同时提供；以商业身份行事的个人除外。在第三国设立的服务提供商仅使用 LEI 识别，因为 EUID 是欧洲识别符。不要在 LEI 字段中填写占位符，也不要在 EUID 字段中填写 LEI：ESAs 将被标记为 EUID 的 LEI 列为导致 VR_72 错误的可避免原因之一；在其发布的数据中，无效的 EUID 格式是 EUID 问题中数量最多的类别。
主要来源
- Commission Implementing Regulation (EU) 2024/2956。DORA 第 28(9) 条项下关于信息登记册标准模板的 ITS。第 1 条定义了直接服务提供商、ICT 服务供应链和层级。第 2 条规定层级判定规则。第 3 条规定通用模板要求、六项数据质量原则以及 LEI 和 EUID 要求。第 4 条规定数据格式规则。第 5 条列出 15 个模板，从 B_01.01 到 B_99.01。
- ESAs，“向 ESAs 报送 RoI 的观察结果。已识别的关键共性问题”（最初发布于 2025 年 4 月 16 日，更新于 2025 年 5 月 16 日）。错误代码表、拒收或不拒收映射、外键级联、申报指标规则、LEI 掩码、EUID 指引以及 2025 年 5 月 1 日新增规则的来源。
- EBA，“为 DORA 准备 plain csv 报送包”。ZIP 命名模式、包文件夹结构、report.json、parameters.csv 和 FilingIndicators.csv 的内容，以及包括
eba_负责人前缀在内的七项数据类型规则的来源。 - EBA 验证规则包。已发布的规则集。该规则集按版本管理，适用的有效规则取决于当时生效的分类法和报告框架版本。
- EBA，“信息登记册报送常见问题”（更新于 2025 年 3 月 28 日）。
- EBA，“DORA 信息登记册报送准备”。索引页，包含技术包、数据点模型、分类法以及上述文件。
- Regulation (EU) 2022/2554 (DORA)，第 28(3) 条规定维护信息登记册的义务，第 28(9) 条规定模板授权。
- 背景资料：我们的15 个官方模板指南以及配套的模板参考（CSV）。
本文仅供参考，不构成法律或监管建议。资料来源已于 2026 年 7 月 14 日核对。ESAs 指出，各国家主管机构实施的验证检查和反馈消息可能与 ESAs 发布的内容不同，且规则集按版本管理。每次提交前，请与您的 NCA 确认分类法版本和当时生效的规则。
