作为第三方支付公司，网易支付系统每天有数亿的资金在流通，同时还要处理更大量的用户备付金，在业务持续发展的基础上，我们需要守护资金安全的底线，任何微小的资金风险暴露，最终都可能带来难以承受的财务损失，因此资金安全一直是支付研发团队长期关注的问题。

近年来发生的几起重大金融安全事件

我们来回顾一下近年来流传较广的几起金融安全事件，以及这些事件造成的重大损失。

2018年，上海一家银行在内部核算过程中，发现有人利用该银行网银漏洞骗取3000万元贷款。警方调查发现，仅有高中学历的马某于2018年初发现该银行存单质押贷款业务存在漏洞，通过简单的数据包篡改，使银行系统误以为他持有高额存单，从而批准他的贷款申请。随后半年时间，马某利用该漏洞骗取3000万元贷款，经后续追偿，该银行损失仍在1500余万元。

2019年1月20日，拼多多曝出重大BUG的消息在朋友圈疯传，网上盛传平台一夜之间损失200亿。拼多多回应称，有黑灰团伙通过过期优惠券漏洞盗取平台数千万优惠券，牟取不当利益，实际最终经济损失可能不足千万元。整个漏洞从曝光到被大面积利用历时数小时，造成经济损失超千万元。

2020年1月7日，京东向用户发放的200元优惠券因使用规则错误而被大量使用。据网上报道，该优惠券被约24万笔订单使用，总价值约7000万元。事后，京东收回了使用该优惠券支付的订单。实际损失金额尚未公布，但结合京东的赔偿方案评估，整个事件造成的损失可能在数千万，这还不包括该事件给京东造成的声誉损失。

从以上案例我们可以看出，金融安全事件不仅可能带来巨大的经济损失，还常常造成公司无形资产，包括社会形象的损失。

财务风险的主要来源

网易支付作为第三方支付公司，主要的金融业务包括充值、交易、提现、结算、转账等；而这些业务往往是金融风险事件发生的主要场景。要应对或规避金融风险，需要对可能导致金融风险的根本原因有更全面的了解。

下面是交易流程的简化图，展示了交易的主要步骤和所涉及的主要系统。

根据风险发生的地点，可将风险进行如下分类，针对不同地点的风险，需采取不同的应对措施。

系统边界（包括系统内部和外部边界）

返回码解析异常问题解决未知状态（操作异常、请求超时等）的错误码为业务成功或业务失败；典型案例：退款请求，银行返回操作失败。不同于明确的退款失败，此错误可能是银行内部系统处理超时导致的。实际退款业务可能已经完成，如果网关系统识别为业务失败，并进行冲销等操作，将造成资金损失。

序列号重用问题：客户端因序列轮换等原因重用业务序列号，服务端因重复序列号幂等性返回业务结果；典型案例：网关系统使用重复的业务序列号调用银行系统进行扣款操作，银行过去已经完成该业务序列号对应订单的扣款，幂等性返回扣款成功结果，导致两笔交易只到账一笔资金，造成资金损失。

金额单位差异问题：部分机构以分作为金额单位，与日元不同，导致两个系统金额有差异；典型案例：A银行以分作为单位，网关发起扣款100元指令，因单位换算处理不正确，导致实际到账金额为1元，资产损失99元。

安全问题

资金安全理念

绝大多数金融风险事件都是在平台建设、升级过程中由于技术原因引发的，如果能通过一定的技术和流程规避问题，或者在功能上线前提前发现问题，就可以将金融风险事件消灭在萌芽状态，因此提升防范和规避​​能力是金融安全体系建设非常重要的一环。

我们不能指望生产环境万无一失，同样需要为金融风险事件的发生做好准备。如何建立完备的监控体系来发现风险事件，避免疏漏，保证问题发现的及时性，成为了重中之重。如上文提到的拼多多案例，几个小时的风险暴露导致数千万美元的损失。如果发现时间控制在一小时甚至几分钟之内，同样的风险事件可能将损失控制在百万甚至十万之内。如果有实时熔断能力，0损失也是有可能的；因此，监控和发现能力是应对金融风险事件的必备能力。

当风险事件发现时，是否有相应的应急预案、是否有快速的应急处置能力，决定了能否控制和降低事件造成的损失和影响。

风险事件结束后，要及时总结回顾，深入分析各层级的改进空间并推动落地；回顾与反馈能力使得整个安全体系不断迭代改进，能够应对各种新的风险。

网易支付资金保障体系建设

网易支付在预防规避能力、监控检测能力、应急处置能力、审核反馈能力等不断迭代升级的基础上，逐步完善自身的资金安全体系。

预防和避免能力发展过程

对于所有涉及资金运作的项目，在需求阶段，需求方需要明确各个场景下的资金流向，包括正常业务场景与异常流程，明确资金验证方案，明确业务监控要求；在设计阶段，针对所有跨系统资金运作设计一致性保障方案，并提供验证与监控措施；在研发阶段，严格遵循安全研发规范进行研发，应用安全框架减少逻辑遗漏，按照代码指南进行代码检查，提升代码质量；在测试阶段，按照测试规范设计并执行资金安全测试用例，并将相关用例固化为自动化用例，确保长期可靠性，验证资金验证方案的有效性；在部署运行阶段，采用准实时验证机制，确保及时发现资金安全问题，制定应急预案应对各类资金安全事件，并通过定期演练确保预案的有效性。此外，对已经发生的安全事件进行详细的回顾和总结，制定改进计划，消除类似的风险。

研发规范

制定基金安全开发和测试规范，为安全研发提供技术指导。

针对不同服务类型，列举了常见的财务风险及应对措施：

外部接口服务

内部接口服务

制定统一的详细设计文档模板，确保详细设计包括并发控制设计、幂等性控制设计、数据一致性保证设计、资金验证设计等。

一致性框架

支付系统中有很多场景需要保证数据的一致性，根据不同的业务场景采用不同的一致性保证方式，除了基于数据库ACID特性实现的强一致性之外，网易支付还开发了两套最终一致性框架，分别应用于不同的场景。

在实际业务场景中，往往需要混合应用多种一致性框架来实现业务目标。以最常见的订单支付流程为例，一个精简的支付流程包括会计服务和订单服务。会计服务实现资金从客户到商户的转移，订单服务实现订单状态到支付成功转移并通知商户。在这个过程中，我们使用TCC框架保证会计服务和订单服务的一致性，使用数据库保证会计服务中余额变化和余额明细的一致性。使用MCC保证订单支付结果通知给商户，从而实现订单服务和商户服务的一致性。

监控和发现功能

监控与发现能力建设主要围绕财务数据的余额核查、信息流数据的一致性比对、业务数据的异常波动三个方向。

同时，时效性也是监控能力建设需要关注的核心点。对于同一个事故场景，发现的时效性越高，事故影响范围就越小，企业遭受的损失也就越小。支付核查系统的时效性在近几年的建设过程中不断迭代提升，从最初的每日核查，到每隔几分钟进行批量核查，再到现在的准实时核查。

帐户对帐

账务对账系统是支付领域最早建立的资金对账系统，包括资金余额核对、虚拟资金流与信息流核对、虚拟资金流与实物资金流核对等功能。

通用对账系统

对账系统解决了支付系统与外部系统之间的对账问题，但随着支付业务的发展，支付系统被拆分成微服务，支付过程中涉及到的服务越来越多，这些服务之间的数据一致性保障亟待解决。通用对账系统正是在这样的背景下诞生的，其核心目标包括：

其主要架构如下图所示

核心流程如下：

一般对账系统消费的是业务消息或者消息，通过数据转换模块转换成标准的对账数据，作为数据校验的原始数据；根据配置的对账任务，基于对账数据查询生成对账记录。对账记录中双方数据准备完毕后，按照配置的对账规则进行对账校验，保存对账结果；若对账数据出现金额差异、状态差异、多对一等异常情况，则触发报警模块发出报警；若对账记录超时，未能采集到符合条件的双方数据，则触发单边账务报警；熔断模块通过监控对账结果进行动作，当对账差异达到配置的阈值时，触发熔断，下发业务熔断消息并触发最高级别报警。

目前，通用对账系统已承担支付领域约50个验证任务，每天处理数千万笔交易的验证和确认，是建设支付监测与发现能力的重要组成部分。

应急响应能力 应急预案

当风险事件发生时，我们的首要任务是止损，其次才是考虑修复问题，为了确保事件处理过程符合预期，需要提前建立各种应急预案。

每项预案都包括明确的触发条件、执行步骤、影响范围、预期结果、验证方式、决策者、执行人员等；每项预案定期评审，并组织模拟演练，确保当线路遇到相应风险事件时，能够按照制定的应急预案执行后有效、快速地进行恢复，控制事件范围。

支付针对可能发生的重大财务损失场景制定了相应的应急预案，避免出现问题时需要商定应对措施，导致时效性和处理时间成为不可控因素。

自动保险丝

如果风险事件发展迅速，人工无法及时响应，当损失超过一定阈值时，系统会触发自动熔断，暂时中断特定业务，防止损失继续扩大。

恢复过程

资金损失问题难以完全避免，为了减少损失，必须启动追偿流程。无序的追偿流程可能进一步加深风险事件对公司形象的负面影响，得不偿失。一次资金损失事件一般涉及多个客户，这些客户所涉及的资金损失金额可能并不一致。对于一些金额相对较小的用户，追偿流程的人力成本可能高于损失本身，更不要说追偿流程对公司形象造成的负面影响。因此，必须明确制定追偿流程的启动条件、执行流程、执行责任人、追偿词、执行计划及结束条件。有序的追偿流程可以有效降低整体损失。

审阅反馈能力总结反馈，举一反三

回顾总结的目的是发现隐藏在表面问题之下的根本原因，在治标的同时，也要解决根源问题，避免同类问题继续给业务带来损失。

支付建立了明确的评审机制，通过详细的评审模板，鼓励相关责任人从各个方面深入分析问题产生的原因，从中吸取教训，明确改进措施，并通过流程确保措施得到有效落实，反馈到资金保障体系中。

- 结尾 -

点击下方公众号入口，关注“技术对话”微信公众号即可查看历史文章，投稿请回复公众号后台：提交