TARGET2：支付基础设施恢复的问责测试

摘要

• TARGET2 的结算服务在 2020 年 10 月 23 日约 14:40（欧洲中部时间）不可用。同区域恢复未能成功，应急模块不可用，欧元系统将服务转移至备用区域。经过一系列部分恢复和 SWIFT 面向服务器的手动重启后，FIN 消息处理于次日上午约 01:20 全面恢复。
• 直接触发因素是第三方网络设备中的软件缺陷，在准备周末网络工作时由配置参数激活。这一事实并未将运营责任转移给供应商。运营商控制着变更分类、时机、测试、回滚准备、服务架构、故障转移升级和参与者沟通。
• 公开影响记录支持延迟和拒绝的支付流量、流动性转移中断、辅助系统影响、对账工作以及异常流动性行为的证据。但它不支持可靠的总体财务损失数字。超过 900 笔被拒绝交易中约 120 亿欧元是支付金额，而非已证实的损失；隔夜存款减少约 4000 亿欧元是一种流动性流量比较，而非损害。
• 一项独立审查发现 2020 年五起 TARGET 服务事件中存在 40 个问题，包括 17 个高优先级发现。其最重要的结论是系统性的：变更管理、连续性规划、故障转移测试、文档、沟通、治理和控制框架未能形成一个充分整合的运营系统。
• 欧元系统接受了审查的总体结论，并制定了 155 项补救措施。截至 2025 年 7 月，它报告称还有一项措施待实施。后来的服务证据显示了有意义的变化，包括一个独立风险委员会和在 2025 年另一次中断期间可用的应急结算，但也表明批发支付韧性仍然是一项持续的问责义务，而非一次性的结束证书。

一个恢复具有公共后果的支付系统

TARGET2 是事发时欧元系统用于欧元支付的实时全额结算系统。商业银行、中央银行和市场基础设施使用它来以中央银行货币结算高价值和紧迫的义务。因此，该系统既不是普通的公司应用程序，也不是用户可以简单放弃数小时的便利渠道。其可用性影响了银行的流动性状况、辅助系统、证券结算资金以及银行传递给客户的付款完成情况。

规模解释了这一区别的重要性。《TARGET 2020 年度报告》指出，TARGET2 当年处理了 8870 万笔交易，价值 465.8 万亿欧元，平均每个工作日处理 345,006 笔付款，金额达 1.8 万亿欧元。它占欧元大额支付系统结算价值的约 90%。大部分交易量并非中央银行转移自有资金：83% 是归类为第三方转账的客户和银行间付款，而辅助系统流量也占据了重要份额。

这种公共角色改变了问责标准。对缺陷交换机给出技术正确的解释是必要的，但还不够。运营商必须能够证明：风险变更已适当分类和测试，冗余站点确实可恢复，在恢复目标到期前可做出故障转移决策，参与者知道该做什么，以及日终义务已得到控制。证据还必须允许监督机构和受影响的参与者区分不可避免的剩余风险与可预防的控制失败。

TARGET2 在纸面上拥有复杂的韧性设计。它跨越两个区域的四个站点运行，每个区域两个站点。该结构既提供了活动区域内的辅助站点，也提供了一个备用区域。一个单独的应急模块（通常称为 ECONS）旨在当正常结算不可用时支持关键付款。该事件测试了所有三个层面：组件冗余、同区域恢复和跨区域恢复。其中两个层面未能及时产生运营结果，第三个层面仅在正常工作日被延长至深夜后才恢复服务。

核心教训并非复杂基础设施永远不会失败。而是冗余是一种可问责的主张。只有当类似生产的测试、明确的决策权、训练有素的运营商、可接触的参与者以及实际恢复的证据使其在压力下成立时，才能被视为已证实。

事件时间线，恢复边界保持明确

第一份公开运营记录是 ECB 的10 月 23 日事件通报。它记录称所有结算服务在大约 14:40 不可用。支付指令、辅助系统指令以及进出 TARGET2-Securities 和 TARGET Instant Payment Settlement 的流动性转移无法处理。信息和控制模块——许多参与者通过该主要界面监控和管理活动——也不可用。

更详细的AMI-Pay 与 AMI-SeCo 联合事件演示提供了一个适合审计的序列，但仍保留了一些每分钟的技术细节未公布。第一次 TARGET2 危机管理员电话会议发生在 15:15，即服务中断后 35 分钟。随后在 15:30 发出了第一次参与者沟通。到 16:30，ECONS 已被报告不可用。运营商继续尝试在活动区域内恢复。

大约在 20:30，即中断开始近六小时后，欧元系统得出结论认为同区域恢复不可行，并决定将 TARGET2 移至意大利区域。技术性跨区域故障转移在大约 22:30 完成。这一里程碑并不意味着所有支付流量都已恢复。辅助系统和应用对应用流量在约 23:10 恢复。FIN 流量恢复后又停止，因为连接 SWIFT 的服务器需要手动重启。FIN 消息处理在 10 月 24 日星期六约 01:20 全面恢复。

欧元系统延长了操作时间表。客户支付截止时间设定为 03:00，银行间截止时间为 03:30。其记录称，所有排队指令，包括来自 T2S 的流动性转移，都在 03:30 价值日期关闭前处理完毕。大约在 04:15 发现常备融资便利模块存在阻塞。下一个价值日期在 05:10 开启，10 月 26 日星期一的夜间结算于 05:55 开始。在应对过程中，运营人员举行了 17 次危机电话会议，并通过市场信息分发和 RSS 渠道发送了 15 条参与者消息。

持续时间需要谨慎，因为公开文件使用了不同的终点。ECB 的独立审查公告将中断描述为持续“近 10 小时”。后来的外部审查使用了约 11 小时。从 14:40 到 01:20 全面 FIN 处理计算约为 10 小时 40 分钟，而技术性跨区域完成在 22:30 则产生较短的间隔，最终日终关闭则产生更长的间隔。一旦说明了所测量的服务边界，这些描述就是一致的。它们不应被合并成一个错误精确的数字。

时间线还防止了相反的误区。说 TARGET2 只是失去了工作日且从未结算其排队指令会产生误导。官方记录称价值日期保持开放，待处理指令已处理。将日终完成称为成功的连续性结果同样具有误导性。关键服务中断了数小时，截止时间被移动，一些参与者无法重新发送流量，下游客户文件被延迟。账本的恢复并不能消除达到该状态所需的运营中断。

设备缺陷是触发因素，而非全部原因

ECB 的事后更新将中央银行内部网络中第三方网络设备的软件缺陷确定为根本技术原因。欧元系统声明该缺陷并非网络事件，已采取纠正措施，且 TARGET2 和 T2S 在 10 月 26 日和 27 日正常运行。少数支付调查仍在对账中。

后来的独立分析提供了控制背景。为了准备在即将到来的周末激活新的交换机，工程师在 4CBnet-NG 网络中引入了一个配置参数。该参数在八台设备中的六台上运行正常。在受影响的设备上，它触发了软件行为，导致网络连接不稳定，并在活动区域的两个站点间级联。供应商的技术支持部门自 2020 年 5 月起就已经知晓该缺陷，但问题未出现在运营商可获得的相关手册或发布说明中。

这一序列产生了两个不同的问责命题。第一个已确认：潜在的供应商缺陷由生产网络变更激活。第二个是得到支持的制度推论：中断的持续时间和广度取决于运营商围绕该缺陷所控制的防御措施。供应商可以控制源代码、缺陷披露和技术支持。它无法控制系统所有者是否将网络变更归类为可能产生业务影响、是否安排在服务时间内、是否在代表性环境中测试、是否验证回滚、是否保护两个站点免受共因故障影响，或者在恢复目标内升级到备用区域。

受欧元系统委托并以节略形式发布的德勤外部审查发现，每个防御点都存在弱点。被视为无业务影响的变更并非总有记录的理由。测试证据不完整。某些对网络、硬件、电力和冷却基础设施的变更可能被当作标准和低风险处理，尽管它们有能力中断服务。审查发现没有功能性的网络变更测试环境，这意味着重要变更可以直接进入生产。它还发现对供应商发布信息审查存在缺陷。

因此，正确的因果模型是分层的。供应商缺陷解释了交换机为何出现意外行为。变更治理解释了该行为为何在未得到充分控制的情况下进入生产。架构和故障转移准备解释了为何一个变更域中的故障会影响活动区域的两个站点并阻碍同区域恢复。危机治理解释了选择备用区域所花费的时间。沟通和参与者准备解释了为何技术恢复并未立即恢复所有支付流。这些层面均不需要推测个人动机。它们是公开审查中记录的控制领域。

名义冗余遭遇共因故障

此次中断暴露了韧性主张中反复出现的弱点：两个组件或两个站点看起来可能是冗余的，但却共享一条故障路径。活动区域的两个站点都依赖于受影响的网络环境。因此，尝试的恢复遇到了相同的不稳定条件，而非避开它。当危机管理人员首次寻求应急选项时，ECONS 也不可用。到运营人员决定使用备用区域时，用于系统重要性支付系统的两小时恢复基准已经过去。

问题不仅仅在于故障转移需要时间。审查发现，故障转移场景定义不一致，且通常是针对特定组件或静态的，而非整体性的。主站点和辅助站点在功能上并不总是相同。没有足够明确的触发时期来强制在恢复时间目标到期前做出决策。TARGET2 的故障转移测试与站点轮换挂钩，审查报告称在 2019 年和 2020 年轮换期间未进行此类测试。测试报告没有可靠地将经验教训汇总为持续改进。

早前的一起事件提供了一个有用但有限的反事实。2020 年 8 月 11 日，TARGET2 遭遇了另一次中断，运营商在 15:45 启动了同区域故障转移。新站点在大约 16:43 技术上可用，尽管剩余服务的恢复耗时更长。年度报告中的比较表明，同区域恢复在某些故障条件下可能有效。它也说明了为何一次成功的测试或先前的故障转移不能证明面对共因网络故障时的韧性。一个有效的控制集需要消除两个活动区域站点、削弱管理接口、使应急通道不可用并强制做出有时间限制的跨区域决策的场景。

反事实应被框定为一种控制测试，而非声称某个未观察到的决策肯定会防止所有延迟。如果配置已在功能代表性的网络环境中测试过，供应商缺陷可能在生产之前就被发现。如果站点与相同的变更效应隔离，辅助站点可能仍可用。如果危机规则要求尽早做出跨区域决策以保护两小时目标，支付处理可能更快恢复。如果 ECONS 的准备情况和参与者演练更充分，关键流量可能在正常服务恢复期间持续进行。每个假设在技术上都有审查建议的支持，但公开记录无法确定每个控制可能节省的确切分钟数或交易量。

这是反事实问责的适当标准。它识别出谁控制了缺失的防御措施，以及该防御措施旨在保护的可观察结果。它不会将一个合理的替代方案变成虚构的重建。

支付损害比损失估算更广泛

公共支付中断会造成多种损害，不应简化为单一的货币数字。第一种是时间性的：已接受或预期的支付晚于发起方、受益方或相关系统计划的时间。第二种与流动性相关：银行无法在账户间转移现金、为证券活动提供资金、结算辅助系统头寸或按计划存放准备金。第三种是操作性的：员工必须监控渠道、延长营业时间、重新发送指令、核对报表并调查例外情况。第四种与信心相关：参与者发现应急和沟通路径比预期更弱。

事件演示报告称，中断发生时，当日约 65% 的流量和 85% 的周转量已结算。与前两个周五相比，日周转量下降 10% 至 15%，流量下降 3% 至 5%。超过 900 笔交易被拒绝，总支付金额约 120 亿欧元。据报道，几个主要国家组件以及辅助系统和银行间流量受到的影响最大。这些是流量中断的重要指标。它们并非 120 亿欧元消失或成为经济损失的证据。

参与者记录增加了汇总量无法揭示的后果。一些银行和辅助系统无法重新发送消息，因为其自身系统无法做到或已关闭。关键的辅助系统义务已结算，但 SEPA 流量的自动清算所文件缺失，延迟了向最终受益人的转账。一些 T2S 直接参与者遇到了抵押品重新分配问题。数十个支付异常需要对账。即使本金最终得到结算，这些也是可信的操作损害形式。

流动性行为也发生了变化。11 家银行使用了边际贷款便利，总额 1900 万欧元。银行存入的隔夜存款比正常模式减少约 4000 亿欧元，因为转移超额准备金的机会受到限制。这 4000 亿欧元特别容易被误用。它是中央银行流动性配置的变化，而非对损害、损失或冻结客户资金的公开估计。来源并未量化放弃的利息、参与者人员配备费用、客户赔偿或间接商业成本。

对证券基础设施的影响是选择性的而非全面的。根据《T2S 2020 年度报告》，T2S 中的证券结算仍可用，但 T2S 与 TARGET2 之间的流动性转移无法处理。T2S 延长了自身时间表，在 03:30 关闭，并在 06:05 开始下一次夜间结算。这一区别很重要：该事件并未使所有证券记录不可用，但损害了现金流动性，而顺畅的券款对付和抵押品操作依赖于现金流动性。

为本分析审查的所有可获取公开记录均未提供经过验证的总体经济损失数字、延迟最终受益人的完整计数或逐参与者的赔偿计划。负责任的报道应将此视为未知数。一个系统可能造成严重破坏而没有产生可发布的损失总额，并且缺少该总额不应被误认为没有损害的证据。

谁控制了哪些

当按功能而非仅按机构名称分配控制权时，问责性变得更加清晰。

运营商自身的治理结构也是审查的一部分。第一级职能由管理委员会承担，第二级由市场基础设施委员会承担，第三级由服务提供中央银行承担。德勤将决策描述为集中在高层，委员会格局复杂。文档并不总能确定完整的职责。具有足够权力的中央第二道防线控制职能和总体内部控制框架尚未完全到位。一些先前识别的监督问题关闭时间过长。

这并不意味着每个参与者都是被动的，或者每个下游延迟都受到集中控制。缺乏重新发送能力的银行控制着自身这一本地弱点。已关闭的辅助系统控制着自身可用性的一部分。参与者也被期望监控特定的信息渠道。然而，这些责任并不能取消基础设施运营商的职责。运营商选择了沟通架构、提供了应急规则、设定了服务日历并代表了共享平台的韧性。问责是并行的，而非一方弱点可免除另一方责任的竞赛。

供应商关系遵循同样的逻辑。已知但未披露的软件缺陷是一个严重的供应商控制事实。公开记录没有指明供应商、披露合同、显示是否违反了咨询义务，或者说明欧元系统是否获得了赔偿。这些未知因素阻止了对供应商责任的法律判断。但它们并不阻止这样的运营判断：系统所有者需要能够遏制供应商缺陷的独立控制措施。

监管基准与公开法律记录的局限性

在中断发生时，TARGET2 根据《欧洲中央银行关于系统重要性支付系统监督要求的法规》作为系统重要性支付系统进行治理。第 15 条要求建立稳健的运营风险框架、业务连续性安排以及一个辅助站点。这些安排的设计应使得关键信息技术系统能够在破坏性事件后两小时内恢复，且结算能够在工作日结束前完成。计划需至少每年测试和审查一次。该法规还要求管理来自关键参与者、其他基础设施和服务提供商的风险。

国际基准是一致的。CPMI-IOSCO《金融市场基础设施原则》原则 17 要求识别内部和外部运营风险、适当的系统和控制、一个辅助站点、在两小时内恢复关键操作以及在中断日结束前完成结算。它还涉及关键服务提供商和相关基础设施带来的风险。这些条款将恢复时间纳入治理目标，而不仅仅是技术性能指标。

根据公开时间线，全面支付处理未在两小时内恢复。同区域站点和应急模块不可用，而跨区域决策在中断开始后数小时才作出。这是将表现与监管基准进行比较的有力依据。但本身并非正式裁决违规的证据。此处审查的材料不包含对十月事件处以罚款的公开执法决定、分配责任的法院判决，或解决所有合规要素的监管认定。

制度背景使证据尤为重要。ECB 的监督政策描述解释称，欧元系统收集信息、根据标准评估系统并在必要时推动变革。TARGET 服务也在欧元系统内运营。运营和监督职能是分开的，但它们存在于同一个更广泛的公共机构内。断言此案中监督独立性受到损害将是推测性的。尽管如此，要求可见的角色分离、有据可查的质疑和关闭证据是合理的，以便公众不必仅依赖机构保证。

支付赔偿是另一个需要精确对待的领域。当时适用的《TARGET2 指南》包含了一项针对因技术故障无法在同一工作日结算的已接受支付指令的赔偿方案。它涉及管理费、利息赔偿、排除条款以及已接受赔偿与其他索赔之间的关系。由于欧元系统表示所有排队指令在延长的价值日期关闭前已处理，公开事件记录并未确定有多少指令（如有）符合条件、是否提出索赔或支付了何种赔偿。被拒绝的消息和下游文件也可能引发与中央系统中已接受指令不同的法律问题。

因此，法律问责有一个有记录的下限和一个未记录的结果。下限是两小时恢复设计目标、日终结算、年度测试和服务提供商风险管理。仍然未知的结果包括执法处理、私人索赔、赔偿金额以及对供应商的合同追索。可信的评估应同时说明两者。

独立审查将事件转化为系统诊断

欧元系统委托德勤审查 2020 年发生的五起重大 TARGET 服务信息技术事件。工作从 2020 年 12 月下旬持续到 2021 年 3 月，采用了文档、访谈和测试，并遵循定义的保证方法。已发布的报告因安全和客户保密原因被删节和编辑。它并非对所有控制的通用审计。这些范围限制很重要，但它们并未削弱审查确实证实的问题的重要性。

审查报告了 40 项发现：17 项评为高优先级，17 项中优先级，6 项低优先级，无评为非常高优先级。它将其分为六个广泛的问题领域：变更和发布管理；业务连续性管理；故障转移和恢复测试；沟通协议；治理；以及数据中心和信息技术运营。十月事件涉及所有六个领域。

业务连续性文档支离破碎，有时过时。详细角色定义不一致，培训证明不足。审查未收到涵盖 TARGET2 和 T2S 的有效、当前的业务影响分析。可用的 T2S 分析可追溯到 2015 年服务启动前，且未保持更新。没有更新的影响分析，恢复优先级、依赖关系和可容忍中断假设就无法可靠地与当前业务现实挂钩。

变更管理缺乏共同且丰富证据的生命周期。审查发现风险评估、分类、测试文档、审批和实施规划存在弱点。在运营时间内进行的变更并非总是得到与其可能影响相称的处理。回滚准备和基础设施依赖需要更强的控制。供应商发布信息以及缺乏代表性的网络测试环境增加了对作为最终测试的生产行为的依赖。

沟通在危机治理内部比在参与者外围更有效。审查发现内部危机电话和协调总体有效。在外部，一些参与者不知道 TARGET2 网站或未订阅其 RSS 频道。来自国家中央银行的消息可能不一致，且沟通并不总是告知参与者应采取何种行动。经验教训并非总是有正式负责人和完成日期。

文档和配置管理贯穿所有这些领域。审查发现运营材料支离破碎或过时，且没有能够连接资产、所有者、依赖关系和变更的全面配置管理数据库。控制证据有时不可用。这一缺陷很重要，因为复杂故障后的问责取决于重构哪个组件发生了变更、谁拥有它、哪些服务依赖于它、进行了何种测试以及谁批准接受了剩余风险。

因此，审查最重要的结果并非 40 个孤立缺陷的列表。而是证明关键支付基础设施周围的防御措施未被作为一个连贯的系统进行管理。设备缺陷变成了生产中断；共因依赖破坏了本地冗余；不明确的触发点消耗了恢复时间；沟通弱点降低了参与者能动性；支离破碎的证据使保证更加困难。该诊断为跨治理的补救提供了理由，而不仅仅是更换或修补网络设备。

修复计划及其指标能证明和不能证明什么

欧元系统对独立审查的正式回应接受了报告的总体结论和建议。接受是一个重要的问责步骤，因为它避免将该事件视为不可重复的供应商异常。更困难的步骤是将建议转化为可观察和可测试的控制措施。

已发布的《TARGET 服务行动计划》通过六个与审查对应的工作流来实现。变更管理行动包括标准化生命周期、更强的风险和安全性评估、通用文档、明确的回滚检查、对维护窗口外变更的更高级别审批以及专用网络测试环境的分析。连续性行动包括修订后的危机程序、危机管理员指南、员工培训、整体连续性安排以及业务影响分析和连续性计划的年度审查。

故障转移行动与十月证据特别相关。它们要求明确角色、定义测试频率、保护两小时目标的决策触发器、更具代表性的场景、通用测试报告、定期交易测试和参与者模拟。沟通行动寻求更快速的事实通知、更好的状态和订阅渠道、与关键参与者群体的直接联系、跨中央银行和证券存管机构对齐的消息，以及正式的事后学习。治理和技术行动涵盖更简单的运营模式、法律清单、被授权的风险和控制职能、更好的监控、备用区域监控访问、第三方规则、可审计的运营和带有已识别所有者的配置数据库。

行动计划还报告了运营变化，而非仅仅是承诺。ECONS 激活程序已实施，员工已接受培训。危机指导已修订，使决策者考虑早期应急激活，并根据两小时恢复目标限制停机时间。引入了中央银行与应急网络连接的定期检查，以及定期交易测试和更广泛的演练。这些是直接针对失效路径的控制措施。

进度报告随后提供了中间证据。一份2022 年 12 月实施更新汇总了来自外部审查、监督发现和内部审计的 155 项行动。市场基础设施委员会每月监控工作；内部审计和首席监督员评估支持证据；管理委员会每六个月收到报告。截至 2022 年 3 月 31 日，评估人员已审查了 79 项行动：58 项已关闭，21 项需要更多证据或增强。截至 9 月 30 日，委员会报告 155 项中的 121 项已完成，16 项按计划进行，18 项延迟，许多是因为它们依赖于 TARGET2-T2S 整合计划。

“由管理层完成”与“评估后关闭”之间的区别至关重要。项目团队可以完成一项行动，而不证明控制措施有效。因此，2022 年报告采用内部审计和监督进行证据审查比简单完成百分比更有力。它还披露了延误，而非默默重置基准。

到 2023 年底，《T2S 2023 年度报告》称超过 90% 的计划措施已实施，其余预计在 2024 年完成。2025 年 7 月，管理委员会公布的决策表示 155 项行动中仅有一项仍需实施，并且内部审计委员会将继续监督。委员会结束了年度报告周期。这是持续计划执行的有力证据。但它并非证明所有 155 项行动到 2025 年 7 月都已关闭，因为委员会明确保留了一个待办项。

治理也在持续演变。2025 年 9 月，管理委员会披露，最初于 2021 年要求的 TARGET 服务治理组织审查已完成，进一步措施将在 2027 年之前报告。后续工作不应自动与单独剩余行动混为一谈，后者的主题在公开通知中未说明。但它确实表明“计划报告结束”并不等同于“治理改进结束”。

后续运营才是真正的耐久性测试

政策文件可以显示控制措施已设计和分配。只有后续运营才能显示它们是否仍然可用。《TARGET 2023 年度报告》记录称，整合后的 T2 服务在 2023 年未遭受完全中断，尽管经历了较小的事件。它还报告称，在修订后的风险和控制框架支持下，于 2023 年底成立了独立的 TARGET 服务风险委员会。这是相关证据，表明 2020 年后发现的第二道防线治理弱点已得到制度性回应。

一次更严峻的测试发生在 2025 年 2 月 27 日。于 2026 年发布的《TARGET 服务 2025 年度报告》描述了另一次硬件和存储故障，该故障使 T2 和 T2S 中断了数小时。T2 不可用约 10 小时，T2S 约 8 小时。关键硬件及其冗余发生故障。初始诊断集中在数据库问题上，这延迟了切换区域的决定。服务在 18:00 后恢复，工作日约在午夜关闭。

2025 年的事件不能被视为同一网络缺陷的重复，也不证明 2020 年行动计划全面失败。其价值在于作为一次实时压力测试。ECONS 在后来中断期间支持了关键 T2 支付，证明 2020 年 10 月不可用的应急能力在操作上已变得有用。同时，T2 和 T2S 的同时中断使得抵押品调动困难并延迟了相关流程。事后审查产生了 20 项行动；报告称大多数在 2025 年第四季度前完成，而少数非时间关键项仍在进行中。

这种混合结果比胜利声明或失败声明更具信息量。应急通道处理了关键支付，但诊断和备用区域恢复再次消耗了大量时间。系统展示了改进的能力，但也暴露了残余依赖。持久的问责需要两个事实都保持可见。

这项工作在 2026 年仍在进行中。2026 年 5 月 AMI-Pay 会议成果记录了关于营业日延长以及 2025 年事件后使用 ECONS 的咨询。欧元系统和国家中央银行仍在确定在 ECONS 上处理大多数关键支付需要多少小时，以及何时应开始准备在那里结束当日业务。参与者还强调了避免重复指令及其对内部系统产生不利影响的必要性。这不是未解决的 2020 年行动的证据。而是证明应急结算是涉及运营商和参与者行为的运营生态系统，并且其程序必须在真实事件后继续进行完善。

已确认的事实、有支持的推断和未知因素

已确认的事实。TARGET2 结算服务在 2020 年 10 月 23 日约 14:40 不可用。信息和控制模块、涉及 T2S 和 TIPS 的流动性转移、正常支付结算以及辅助系统指令受到影响。同区域恢复未能恢复服务，ECONS 在初始响应期间不可用，欧元系统在约 20:30 选择了跨区域故障转移。全面 FIN 处理在约 01:20 恢复。价值日期被延长，运营商称所有剩余排队指令在 03:30 关闭前已处理完毕。

同样已确认的是，一个配置参数激活了第三方网络设备中的软件缺陷，供应商已知晓该缺陷，且该缺陷未在相关发布材料中向运营商记录。该事件未被归因于网络攻击。公开报告记录了被拒绝的流量、延迟的下游文件、受限的流动性转移、对账工作以及改变的隔夜存款行为。独立审查记录了 2020 年事件中的 40 项发现，欧元系统制定了 155 项补救措施，其中一项在 2025 年 7 月仍待实施。

有支持的推断。中断的规模和持续时间并非仅由设备缺陷决定。变更评估、代表性测试、共因隔离、故障转移触发器、应急准备和参与者沟通方面的弱点移除或延迟了运营商控制下的防御措施。这一推断得到了外部审查及其发现与行动计划直接对应的支持。

同样可以合理推断，与未恢复的日期相比，保留价值日期并处理所有排队指令减少了结算最终性和本金风险后果。来源不允许量化这一减少。同样，2025 年 ECONS 的成功使用支持了 2020 年后应急能力得到改善的推断，但它并未隔离出是哪项行动带来了改善，也未证明现在涵盖了所有场景。

未知因素。公开记录未指明设备供应商名称，未披露其合同，也未显示是否寻求了合同救济。它未提供完整的配置日志、所有内部决策记录、参与者级别的排队信息或每家银行无法重新发送流量的确切原因。节略的审查隐瞒了敏感的技术和客户信息。这些限制阻止了对个人行动和法律责任的完整重建。

总经济成本未知。没有经过验证的客户损失、流动性成本、员工加班、机会成本、赔偿、索赔或供应商追偿的汇总数据。公开来源未确定十月事件是否产生了正式监管违规决定、制裁或法庭案件。它们也未指明 2025 年 7 月通知中 155 项行动中的最后剩余项，也未为每个已关闭行动提供公开测试证据。这些缺失应保持可见，而非用估计来填补。

批发支付基础设施的持久问责测试

该事件支持一个可应用于 TARGET 服务和其他系统重要性支付平台的实践测试。只有当以下命题能够用证据而非保证来回答时，问责才是持久的。

第一，运营商能否将每项关键服务映射到其拥有的基础设施和依赖关系？当前的配置数据库应连接设备、软件、站点、网络、供应商、业务服务、负责所有者和恢复程序。对网络参数的更改必须揭示其可能影响的所有服务和冗余域。

第二，变更决策是否与可能的服务影响相称？分类不应使基础网络、电力、存储或冷却工作因看似常规而被视为低风险。证据应包括业务影响推理、代表性测试、同行评审、批准的实施方案窗口、监控、停止条件和经过演练的回滚。

第三，冗余在重要场景下是否独立？当一个变更或控制平面可同时禁用两个站点时，两个站点并不能提供两层防御。测试应包括活动区域丢失、管理接口丢失、连接服务降级以及名义应急路径的故障。在恢复依赖等价性的情况下，生产和备份配置应在功能上等价。

第四，危机治理是否强制在恢复目标到期前做出决策？升级规则应明确谁可以调用同区域、备用区域和应急处理，他们需要什么证据，以及最晚决策时间。两小时恢复目标不能被允许在超过两小时后继续诊断而不选择备用路径的委员会实现。

第五，参与者能否根据沟通采取行动？状态消息必须及时、可访问且在操作上具体。它应说明哪些服务受到影响、参与者应停止或继续什么、消息是否需要重新发送、适用哪个截止时间以及下一次更新何时到达。关键群体需要经过测试的联系途径，而不仅仅是一些用户不知道存在的网页。

第六，应急处理能否处理现实的关键流量？ECONS 或任何后续能力应与中央银行、商业银行和辅助系统一起，使用真实消息模式和现实流量进行测试。测试应涵盖重复避免、流动性、抵押品约束、日终关闭以及向正常服务的过渡。仅连接性是不够的。

第七，是否通过完整支付链衡量损害和例外情况？运营商指标应区分排队、拒绝、重新发送、重复、延迟和最终结算的指令。它们应捕捉辅助文件、流动性转移、对账案例和下游受益人延迟，而不会将支付本金错误标记为财务损失。

第八，独立控制职能是否对关闭提出质疑？管理层完成、第二道防线验证、内部审计评估和监督关闭是不同的阶段。高优先级行动应保留负责人、截止日期和证据，直至独立审查员确认运营，而不仅仅是设计。

第九，法律和参与者救济措施是否可见？公共基础设施无需披露敏感索赔，但应解释适用的赔偿框架、在法律允许情况下的总体索赔处理，以及是否追究了供应商或参与者的责任。沉默不应被转化为认为没有可用或需要的救济措施。

第十，机构是否在下一次事件后再次学习？后续失败应与先前的控制承诺进行比较。改进应急使用的证据值得肯定；诊断或故障转移的重复延迟值得审查。已完成的项目应成为维持的运营基线，而非档案。

这些测试避免了两个无益的极端。一种将每次中断视为韧性投入失败的证据，这对复杂系统来说是一个不可能的标准。另一种接受架构图、行动数量和高年度可用性作为连续性有效的证明。可辩护的中间地带要求严格但可衡量：失败会发生，负责机构必须证明预防是相称的、恢复是及时的、损害受到控制、决策是可重构的，并且同样的弱点不会未受挑战地持续存在。

结论

2020 年 10 月 TARGET2 中断始于第三方软件缺陷，但由于运营商的多个防御措施同时失效而成为问责事件。生产网络变更激活了缺陷。活动区域的两个站点都暴露在风险中。同区域恢复和应急结算不可用。跨区域故障转移在数小时的尝试恢复后才进行。沟通未能使每个参与者做好准备应对，工作日不得不延长至周六早晨。

欧元系统最终处理了排队指令并保留了价值日期，委托了独立审查，接受了系统性诊断，并推行了大规模的补救计划，且进行了外部进度报告。这些是实质性的问责行动。后来成立独立风险委员会以及在 2025 年另一次中断期间运营使用 ECONS 增加了证据表明一些重要控制措施发生了改变。

该记录并非宣布韧性已经完成的基础。155 项行动中的一项在 2025 年 7 月仍未关闭，治理措施继续按后续时间表进行，2025 年的事件暴露了诊断、冗余和同步服务依赖方面的新困难。该记录也不是凭空捏造官方证据未建立的损失、法律违规或个人责任的基础。

TARGET2 将恢复本身作为了测试。对于共享支付基础设施，确定缺陷组件或报告年度可用性并不能满足问责要求。只有当具有实际控制权的机构能够证明变更得到控制、故障转移决策保护了承诺的恢复时间、应急通道与真实参与者一起工作、延迟支付和流动性影响被诚实衡量、监督能够质疑运营商，并且修复措施能够经受住下一次运营冲击时，问责才得到满足。