2026年10月20日，Google Cloud伦敦区域发生电力事件，部分网络服务出现间歇性故障。Revolut的银行卡支付、ATM取款及应用服务受到影响，Lloyds、HSBC等金融机构也报告服务异常。

故障于英国时间早上约6时08分开始，多数服务在约六小时内恢复。受影响者不只包括银行，还涉及英国法院、医疗、物流等公共服务。部分并不位于英国、但依赖伦敦基础设施的应用同样出现异常。Google表示将发布事故分析报告。reuters.com

这不是一个普通的“服务器宕机”故事。

它更像一次现实版压力测试：当多家金融机构依赖同一家云服务商、同一地理区域，甚至同一可用区时，单点基础设施事故可以迅速演变为跨机构、跨行业的系统性中断。

对于计划进入新加坡、香港、澳大利亚、英国或欧盟市场的亚洲金融科技公司，这次事件至少带来七项合规预警。

一、事故暴露的不是“云不可靠”，而是架构假设未经验证

云服务商通常提供多个可用区、自动扩容、数据备份和灾难恢复工具。因此，许多机构会产生一种错误印象：

既然系统部署在大型云平台，就已经具备运营韧性。

实际上，“使用云服务”与“具备可验证的恢复能力”是两回事。

如果核心账本、客户身份验证、银行卡授权、交易监测、客户通知及后台管理全部依赖同一云区域，那么即使每个系统单独符合内部技术标准，它们仍可能在区域级故障中同时失效。

此次事故尤其说明了三个问题：

同一地区的多个系统可能存在共同故障点；

应用服务恢复，不代表支付、身份验证和数据同步能够同步恢复；

服务商承诺的高可用性，不等于金融机构能够满足监管要求的恢复时间。

真正需要审查的不是“云服务商是否可靠”，而是：

如果该云区域在今天完全不可用，我们还能维持哪些关键金融服务？

二、“多可用区”不等于“跨区域容灾”

很多金融科技公司在供应商问卷中填写“已采用高可用架构”，实际部署却可能仍局限于同一个云区域。

以下三种架构的风险并不相同：

因此，金融机构不应只问“是否部署在多个可用区”，还应继续问：

这些可用区是否共享电力、网络、身份验证或控制平面？

备用环境是否位于另一个独立区域？

数据能否在符合监管要求的前提下跨区域复制？

切换需要人工审批还是可以自动完成？

最近一次完整切换测试是什么时候？

备用区域能否承受正常业务的全部交易量？

如果这些问题没有经过实际测试，所谓的“跨区域容灾”可能只是架构图上的一条虚线。

三、亚洲监管机构已经把云风险纳入运营韧性监管

1. 新加坡：外包不转移金融机构责任

MAS的科技风险管理框架要求金融机构保障关键IT系统的可靠性、可用性及可恢复性，并采取措施保护客户信息。其第三方风险管理要求也强调，金融机构必须确保外部服务受到适当治理和控制，遵守科技风险、业务连续性及运营风险要求。mas.gov.sg

这意味着，新加坡持牌机构不能仅以“Google、AWS或Microsoft负责基础设施”为由解释服务中断。

监管关注的是持牌机构自身是否：

识别了关键服务及其技术依赖；

对云服务商进行了持续风险评估；

制定并测试了恢复方案；

能够及时通知客户和监管机构；

保留足够能力监督外包安排。

对于申请大型支付机构牌照、资本市场服务牌照或数字支付代币相关牌照的企业，云架构、外包治理和业务连续性已经不是纯技术附件，而是牌照评估的重要组成部分。

2. 香港：云采用必须与运营韧性、科技风险及外包治理衔接

HKMA发布的云应用实践指引明确联系了运营韧性、科技风险管理及外包监管要求，包括OR-2、TM-G-1及SA-2等监管模块。HKMA亦持续发布与运营韧性相关的行业良好实践。brdr.hkma.gov.hk

香港银行或为银行提供关键服务的金融科技公司，应特别注意：

云架构是否支持关键业务在中断期间继续运行；

集团层面的全球云合同是否充分覆盖香港实体；

境外技术团队是否能在香港营业时间及时处理事故；

客户资料跨境复制及备用区域安排是否合法；

银行能否获得足够的审计、测试及事故资料。

对于银行的技术供应商而言，即使自身不是HKMA直接监管对象，也可能通过银行的采购尽调、审计权及合同义务受到“穿透式”影响。

3. 澳大利亚：董事会对服务商风险承担最终责任

APRA的CPS 230要求受监管机构管理运营风险、在中断期间维持关键业务，并有效管理重要服务商风险。董事会对运营风险管理承担最终责任，并应获得足够信息履行监督职责。APRA也明确表示，云计算安排需要符合CPS 230对重要服务商的要求。apra.gov.au

因此，董事会不应只收到“系统已恢复”的事故简报，还应了解：

中断是否超过内部影响容忍度；

哪些客户及产品受到影响；

是否存在监管报告义务；

备用环境为何未能避免中断；

同类故障是否可能再次发生；

管理层将在什么期限内完成整改。

四、最危险的不是单一云服务商，而是“看不见的集中度”

传统的供应商清单通常只能显示机构与哪些公司签署了合同，却无法完整识别技术集中度。

例如，一家支付机构可能分别采购：

云基础设施；

身份验证服务；

反洗钱筛查系统；

客服平台；

数据分析工具；

AI模型接口。

表面上看，这些服务来自六家供应商；但六家供应商的底层系统可能全部部署在同一个云区域。

这就形成了“第四方集中度”：

机构没有直接选择共同基础设施，但多个关键供应商通过底层云平台形成了共同故障点。

因此，供应商管理不能止于一级合同关系。金融机构至少应识别：

供应商使用的云服务商；

主要及备用部署区域；

关键分包商和数据处理者；

身份、域名、网络及密钥管理依赖；

多个供应商之间是否存在共同基础设施。

这一问题对AI金融服务尤其重要。某些机构虽然在不同云上部署业务系统，但模型调用、向量数据库、内容过滤或身份授权仍集中于同一平台。一旦该平台发生故障，AI客服、欺诈监测及自动化合规流程可能同时失效。

五、“客户资金安全”与“服务具有韧性”是两个问题

服务中断后，企业通常会第一时间声明：

客户资金和数据安全未受影响。

这一声明当然重要，但它不能完整回答监管机构的问题。

资金没有遗失，并不表示客户能够：

使用银行卡付款；

从ATM提取现金；

查询账户余额；

取消或修改付款指令；

提交欺诈申诉；

在市场剧烈波动时平仓；

及时赎回电子货币或稳定币。

对于支付、投资和数字资产平台，可用性本身就是客户保护的一部分。

如果客户在紧急情况下无法访问资金，即使资产最终没有损失，也可能引发投诉、补偿、声誉和监管风险。

因此，事故沟通不能只强调“资金安全”，还应说明：

哪些服务受到影响；

中断开始及恢复时间；

哪些交易可能被延迟、重复或拒绝；

客户是否需要重新提交指令；

如何处理相关费用和损失；

客户可以通过哪些替代渠道获得服务。

六、面向亚洲金融科技公司的七项合规整改建议

建议一：建立“关键业务—系统—供应商—区域”四层地图

不要只制作供应商名单。应把每项关键业务映射到：

客户服务；

应用系统；

技术和数据组件；

云服务商、区域、可用区及分包商。

管理层应能够直观看见：某个云区域中断后，会同时影响哪些产品、客户和司法辖区。

建议二：为关键服务设定可验证的RTO、RPO及影响容忍度

RTO：服务必须在多长时间内恢复；

RPO：机构最多可以承受多少数据损失；

影响容忍度：客户、市场及机构能够承受多大程度和多长时间的中断。

这些指标不能只存在于合同或政策文件中，而应与真实系统配置、人员安排和测试结果一致。

如果业务承诺两小时恢复，但完整数据同步需要八小时，该承诺便缺乏可信度。

建议三：至少测试一次完整跨区域切换

桌面演练不能替代实际切换。

测试应覆盖：

数据复制和一致性；

身份及权限系统；

加密密钥；

域名与网络流量切换；

银行、卡组织及支付通道连接；

反洗钱和制裁筛查；

客户通知；

对账及重复交易处理。

如果关键支付系统只能在云服务商正常运行时才能启动备用环境，便不能称为真正独立的灾备能力。

建议四：设计“降级运行模式”

并非所有服务都必须在事故期间保持完整功能。机构可以预先划分：

必须继续运行的关键服务；

可以降低限额运行的服务；

可以暂时停止的非关键功能。

例如，在部分系统失效时，可以保留余额查询、小额支付及客户冻结账户能力，同时暂停高风险转账、复杂投资交易或新客户开户。

但降级模式必须提前经过法律、合规、风控及客户保护评估，不能由技术团队在事故发生后临时决定。

建议五：重写云服务和关键供应商合同

合同至少应明确：

事故通知时限；

根因分析及整改报告；

审计权和监管访问权；

分包商变更通知；

数据可携带性；

业务连续性测试参与权；

数据返还和安全删除；

服务终止后的过渡支持；

严重事故中的优先恢复安排。

服务水平赔偿通常只覆盖部分费用，无法替代监管责任或客户损失安排。

建议六：为支付、合规和客服分别设置人工应急流程

自动化程度越高，越需要准备人工接管。

机构应明确：

谁可以启动应急模式；

谁可以提高或降低交易限额；

谁负责监管通知；

谁决定暂停服务；

谁审批客户补偿；

谁负责在社交媒体和应用内发布信息。

同时，应确保联系方式、操作手册和必要凭证在主要云环境不可用时仍然可以访问。

建议七：把云中断纳入董事会风险指标

董事会不需要管理技术细节，但需要看到能够支持决策的信息，例如：

关键业务的恢复测试通过率；

未满足RTO或RPO的系统数量；

对单一云区域的依赖程度；

重要供应商整改事项；

尚未测试的退出计划；

事故及“险些发生事故”的趋势；

客户投诉和补偿情况。

如果董事会只看到总体系统可用率，可能会掩盖关键服务的真实脆弱性。

七、给准备申请牌照或接受银行尽调的企业：监管真正想看的证据

在牌照申请、银行开户、合作银行尽调或机构融资过程中，仅提交以下材料通常已经不够：

云服务商认证证书；

标准业务连续性政策；

未经测试的灾备架构图；

通用型供应商风险问卷；

合同中的可用率承诺。

监管机构、银行和专业投资者更可能要求看到：

最近一次切换测试的结果；

未通过事项及整改期限；

实际恢复时间与目标的差异；

关键供应商和第四方依赖地图；

董事会或风险委员会的审议记录；

客户沟通和监管报告演练；

可执行的退出及数据迁移计划。

换言之，未来的监管问题不再只是：

“你是否制定了业务连续性计划？”

而是：

“请证明这套计划在核心基础设施失效时确实能够运行。”

八、建议开展一次“云区域完全失效”桌面路演

亚洲金融机构可以围绕以下情景开展董事会或管理层演练：

周一上午9时，主要云区域因电力及网络事件完全不可用。银行卡授权、客户登录、AML监测和客服系统同时受阻，云服务商无法承诺恢复时间。社交媒体已出现大量投诉，合作银行要求在30分钟内说明情况。

管理层需要在演练中回答：

谁在十分钟内确认事故级别？

谁有权启动备用区域？

哪些服务必须继续，哪些可以暂停？

未完成的付款如何识别和对账？

是否触发监管或合作银行通知？

客户公告由谁审批？

如果备用环境也依赖同一身份系统怎么办？

六小时后仍未恢复，是否启动供应商退出安排？

董事会何时收到报告？

如何保存事故证据并开展事后复盘？

如果团队无法在演练中给出明确答案，真实事故中通常也无法及时作出决定。

结语：云上的责任，仍然属于持牌机构

英国此次故障并不意味着金融机构应当放弃云服务。

恰恰相反，云仍然可以提供传统自建数据中心难以实现的扩展能力、安全工具和跨区域部署选择。问题在于，机构是否把这些能力真正转化为经过测试的运营韧性。

对亚洲金融科技公司而言，最重要的结论是：

把系统部署到全球大型云平台，可以转移部分技术工作，但不能转移监管责任。

未来无论是在新加坡申请支付或数字资产牌照、在香港服务银行客户，还是进入澳大利亚、英国及欧盟市场，监管机构都会越来越关注三件事：

关键服务能否持续；

机构是否看得见集中度；

管理层能否证明恢复和退出计划确实可执行。

一次电力故障可能只持续几个小时，但如果它暴露出治理、架构和应急机制的系统性缺口，其监管后果可能持续数年。