运营韧性不是口号：三家银行的实战经验

李培基 · 特约作者 · 风险管理顾问 · 2026-07-01

从"做预案"到"做压测"

传统的业务连续性计划（BCP）建立在一个假设上：我们可以防止中断发生。运营韧性的逻辑恰好相反——中断一定会发生，问题是发生之后多快能恢复、对客户的影响控制在什么范围内。

这个思路转变在2022年前后被英国和欧盟的监管机构正式制度化。英国审慎监管局（PRA）要求银行必须识别"重要业务服务"（Important Business Services），为每项服务设定"影响容忍度"——即最大可容忍的中断时长和范围，并通过场景压测证明自己能在容忍度以内恢复。欧央行（ECB）在同一时期推出了数字运营韧性法案（DORA），覆盖整个欧盟金融体系。

换句话说，监管不再只问"你有没有预案"，而是要看"你压测过没有，结果怎么样"。

三个辖区，三种打法

不同监管辖区对运营韧性的要求各有侧重，但核心框架一致：识别关键服务、设定容忍度、场景压测、第三方风险管理。

英国PRA的路径最为系统化。银行须先识别哪些业务服务一旦中断会对客户或金融稳定造成"不可容忍的伤害"，然后为每项服务定义具体的恢复时间目标。2025年3月是PRA设定的达标期限，要求银行必须在此前证明自身能在影响容忍度以内恢复所有重要业务服务。多家英资银行为此投入了超过18个月的专项改造。

新加坡金管局（MAS）走的是场景驱动路线。MAS要求银行对关键业务服务定期开展"严重但可信"的中断场景模拟，包括核心系统宕机、主要云服务商断供、跨境支付链路中断等。测试结果须向监管报告，恢复不达标的需限期整改。2025年，MAS进一步将压测要求从年度频率提升至半年度。

澳大利亚APRA则在2025年7月正式实施CPS 230标准，将运营韧性、业务连续性和第三方风险管理整合为一个统一框架。CPS 230的特点是明确要求银行对第四方风险（即供应商的供应商）进行评估，这在全球监管中属于较为前沿的要求。

技术投入：韧性不便宜

运营韧性需要实打实的技术底座支撑。摩根大通每年的技术支出超过150亿美元，其中相当比例用于系统冗余、灾备切换和自动化恢复能力建设。该行在2024年的投资者日上披露，其核心交易系统的自动故障切换能力已覆盖95%以上的关键路径，目标恢复时间从小时级缩短至分钟级。

对中小银行而言，这个投入门槛极高。但监管的期望并不因规模而降低——CPS 230对小型银行给予了更长的过渡期，但最终达标要求一致。

第三方风险：被忽视的单点故障

银行对云服务商和金融科技公司的依赖度持续上升，第三方风险已成为运营韧性的最大盲区之一。全球主要银行的核心系统越来越集中在少数几家云服务商上，AWS、Azure和GCP三家的市场份额合计超过65%。一旦某一家出现区域性故障，波及范围远超单个银行。

2024年7月的CrowdStrike事件是一次全球性的实物教训——一次安全软件更新导致全球大量Windows系统蓝屏，多家银行的柜面系统和ATM网络受到影响。事后复盘中，多家银行承认其对关键第三方的依赖链缺乏端到端的可视化管理。

DORA对此有明确回应：要求金融机构建立关键第三方ICT服务商的监督框架，包括退出策略和替代方案。部分欧洲银行已开始执行"多云策略"——核心系统同时部署在两家以上云服务商，确保单一供应商故障不会导致服务完全中断。

对国内银行的现实意义

国内银行业在业务连续性管理上已有较好基础，但"韧性"视角的引入仍处于早期。差异主要体现在两个方面：一是"影响容忍度"的量化——多数国内银行的BCP仍以定性描述为主，缺乏按业务服务逐项设定的可量化恢复目标；二是第三方风险的系统性评估——对核心系统供应商的依赖关系缺乏完整映射，特别是在国产化替代进程中，新供应商的韧性能力尚未经过充分验证。

英国PRA的"影响容忍度"概念值得借鉴：不是所有系统都需要同等级别的投入，关键是识别出哪些服务中断后果最严重，把有限资源集中在最重要的地方。