中农网资金安全治理之对账体系建设
前言
随着中农网支付业务的飞速发展，每天产生的资金额已经达到上百万，清结算系统在保证线上服务稳定可靠的前提下，如何系统化的保障资金安全是非常核心且重要的课题，支付清结算系统经过不断地建设和打磨，在资金安全保障的多个方面均有一些总结和实践，保障资金安全是值得系统思考的课题，只言片语难以全面概括，需要更多的着墨才能较完整阐述，本文侧重点会阐述“对账”的概念，在支付&清结算领域，这是一个非常重要的专业名词，下文将介绍“对账”在分布式系统建设中的实践和解决方案，力求在系统覆盖度、资金准确性、时效等多个维度为系统资金安全保驾护航，实现更健壮可靠的资金履约。
背景&问题
随着中农网支付事业的蓬勃发展，支付清结算业务的复杂性也在不断的增高，总结起来，主要有以下几个特点：
- 场景多:包括鲜茧采购、线上虚拟户金额划转、线上诚意金划转、线上货款划转、ERP结算中心、OMS订单中心等多条业务线；对接多个业务系统。
- 链路长:清结算内部经历记账、汇总账单、付款、回执下载等多个流程。
- 交易金额大：目前日交易额已经达到百万级别，并不断增加中。
- 第三方支付通道不稳定：对接的第三方服务在并发场景下支付成功率无法保证到2个9。
在这样的业务背景下，我们的系统可谓险象环生。因业务高度复杂，稍有不慎就会出现问题，面对大量的日单量，同时还要确保结算金额的准确，这就让我们对问题的容忍度变得极低。这也给我们的资金安全保障造成了巨大的挑战。下面我们列举了一些系统日常运行过程中出现的问题。
| 场景1：加盟商(如 鲜茧采购)核对账单，发现少了一笔费用。 原因：结算单推动平台账单服务账单数据时，数据推送失败并丢失。 |
场景2：中农网资金平台线上订单状态变更支付成功，实际支付结果为未支付。 原因：第三方支付渠道内线上支付结果与实际支付结果状态不一致。 |
|---|---|
| 场景3：结算已发起付款，但订单状态一直为支付中。 原因：支付服务负载过高、支付排队队列阻塞等导致订单数据未能推送至银行。 |
场景4：拉取业务支付数据，出现订单重复支付问题。 原因：接口问题、数据重算导致重复推送资金平台。 |
可以看出，这些都是一些上下游交互的边界场景下遇到的问题。当然不仅限于这些场景，凡是有系统交互、数据交互边界的场景，都会出现此类问题，我们称之为“一致性问题”。经粗略统计，我们清结算系统建立以来有70%左右的问题都属于一致性问题。
导致一致性问题的原因有很多，诸如：
- 幂等、并发控制不当。
- 基础环境故障：比如网络、数据库、消息中间将发生故障。
- 其他代码bug。
目前支付模块的日结算金额已达到百万级别，每个一致性问题都有可能给中农网造成巨大的损失。因此如何解决系统的一致性问题成为我们保障资金安全的重中之重。关于一致性问题，业内已经论述的非常成熟了，搜索引擎中搜索“一致性问题”，随处可见此概念的定义、问题阐述、意义以及解决思路，诸如：
- 强一致性协议: 两阶段提交、三阶段提交、TCC (Try-Confirm-Cancel)等
- 最终一致性: 主动轮询、异步确保、可靠消息、消息事务等
这些手段的目标都是在事中避免问题的发生。但是在实际场景中，无论是系统的内部逻辑还是外部环境都十分复杂多变、不可预知，我们很难完全避免问题。因此事后对于问题数据的发现以及修复就显得尤为重要。这些也正是我们这篇文章要论述的“对账”的核心使命。我们力求总结对账领域内最专业的思路和方法，并结合自身的业务特点，建设配送清结算的对账体系，构筑配送资金安全的坚固防线。在系统的整个构建过程中我们主要围绕以下几个目标：
- 场景覆盖的完整性：无死角覆盖清结算业务涉及的各个场景。
- 问题发现的准确性：能够准确的发现问题，保证不漏报，不误报。
- 问题处理的实时性：尽可能缩短问题处理的周期，极力避免可能造成的损失。
下面开始正式介绍中农网支付清结算对账体系的构建经验。
对账的定义
对账的概念随着金融、互联网行业的发展，定义上也经历了几个阶段的变化，如下：
- stage 1 ：对账最初来源于会计核算，是为保证账簿记录正确可靠，对账簿中的相关数据进行检查和核对的工作。
- stage 2 ：随着互联网金融或电商行业的发展，对账也扩大了应用范围，这一时期，对账是指在固定周期内，支付使用方和支付提供方（银行和第三方支付）相互确认交易、资金的正确性，保证双方的交易、资金一致正确。
- stage 3 ：从广义来看，所有的跨端系统之间的数据核对都应该叫对账，主要是检查和发现数据在流转过程中的不一致问题。通常分为信息流的核对和资金流的核对。信息流核对主要是对业务数据之间的核对，资金流是对资金交易数据进行核对。
系统概况
清结算中心作为资金交付落地的中转中心,上游对接了类似鲜茧采购,ERP结算系统,OMS订单系统,虚拟户划转等外部系统,下游又对接了如茧丝-众邦支付,白糖-中信支付,茧丝-货款等多个支付渠道,不仅承上启下,而且同时对接处理多种信息流数据,系统的高度复杂性给对账的全面性和准确性造成了极大的困难,如图:
设计思路
从整体来看，按照时序维度的先后，系统对账主要分为三阶段的工作。分别是数据准备、数据核对和差错处理。在对账专业概念中，数据核对和差错处理又叫轧账和平账。三个环节紧密相连，从前期准备、问题发现、问题处理三个角度展开对账工作。
数据准备
在数据接入层，不同的第三方渠道会提供不同的数据接入方式。
- 数据拉取:我们主动拉取数据，如ftp拉取csv或接口方式下载账单文件。如众邦银行；
- 文件上传：我们主动将账单文件推送至第三方文件服务器，由第三方对账单数据进行解析。如中信银行；
- 数据推送:接入方将数据通过ETL(Extract-Transform-Load)推送到第三方数据仓库，由第三方对账单数据解析。
数据核对（轧账）
1.对账批次
一个批次代表一次对账操作，批次信息下会展示交易日单数、日交易额以及差错和缓冲数量。目前一个第三方渠道下一个批次；
2.对账缓存
对于平台支付成功但第三方渠道账单中不存在的流水记录，默认置于缓存池(最大缓存日期3天)。同时，缓存池中的数据也可被n+1日第三方渠道账单匹配。
3.对账方式
- 双边对账:以双方的数据互为基准对账。既要保证结算数据为成功的，支付平台也要成功，又要保证支付平台数据为成功的，结算数据也要成功。
4.对账粒度
-
明细对账：对双方的每条数据进行匹配，包括订单编号、交易金额、手续费金额等。清结算平台自定义出银行漏单、平台漏单、平台状态不符、平台短款、平台长款这几种差错类型。
5.银行账单列表
对每一个批次下第三方渠道的账单文件下载，解析为清结算统一识别适配的账单文件。方便在页面对数据进行比对、排错。
6.对账时机
不同的第三方渠道下对账策略不一样，需要根据定时任务手动适配不同渠道下对账时机。如众邦银行适配为n+1日12：00开始对账操作。
差错处理（平帐）
差错处理主要是对数据核对过程中发现的问题数据进行处理。我们会建立一个统一结构的差错记录，将数据核对发现的问题进行统一存储。差错记录中的数据会进行二次核对，避免由于日切等原因造成的问题错报。对于那些真实存在问题的数据我们会提供两种解决模式，如果是常见的问题，且有一套标准的解决方案的话，我们会把它系统化，采取系统自动修复的方式；如果系统无法自动修复，那么我们会进行系统报警，并进行人工处理。
小结
这是一个没有小结的小结。-_-
