对账系统，一分也不能少

 在支付领域中，由于涉及资金处理，因此数据的准确性、一致性、完整性是非常关键的。除了技术层面的设计，还会引入对账对账流程，提供各环节数据的校对工作，以及后续的差错处置、跟踪、调账等功能。对账系统通过比对上下游的交易、记账、结算等数据，可以发现数据不一致的问题，从而保障资金流的正确性和业务的稳健，发现风险控制风险，并利用工具解决资金问题。

一、通用业务逻辑

在讲解业务逻辑之前，有必要先介绍下在支付领域的场景模型。现在互联网金融的发展，各种机构定位不尽相同，我们以一个收单机构为例，来简要说明对账的原因及过程。

这里面其实会涉及到信息流和资金流的核对，以及流水文件和汇总数据的核对。那我们重点关注平台和渠道的对账，其他环节的对账大体类似。有些环节不需要对账就不讨论了，比如用户银行卡的交易，只需要个人查看银行给到的每月账单即可，对账往往是机构和机构之间的业务逻辑。一般的支付平台会通过渠道来对接银行接口，处理资金流。两个机构间会按照约定，定期提供信息流文件后者资金流文件，渠道提供给平台的是信息流文件，银行提供给平台的是资金流文件，文件中会体现流水明细和汇总结果。因此我们可以想到需要核对的一些场景：

a.渠道交易流水和平台交易流水核对

b.渠道结算和流水核对

c.渠道结算和银行流水核对

我们可以简单理解为本质上就是资金流和信息流的核对，当然另外一种视角是资金流转过程中的账证之间的核对。具体到某一个场景中，有可以设计明细对账和总账对账。总之在各场景中需要结合具体业务，需要针对数据特性做特殊的比对逻辑，确保数据一致，避免资金损失。

二、通用架构设计

我们已经知道了要核对的对象，那么大概都有哪些流程呢，下面简单梳理了一些通用逻辑，可以作为参考来实现。

1.数据采集

对账系统需要从各方系统中采集数据。这些数据的数据源不尽相同，如数据库、日志文件、API接口等，需要连接数据库、ftp服务、rpc服务来获取数据，这里需要尽可能。

2.数据标准化（预处理）

从不同系统采集到的数据需要先清洗、转换、格式化，得到标准的账源数据，这样一来就可以使用通用对账模型处理各类数据。

3.对账规则配置

根据业务需求，设置相应的对账规则，如对账周期（日、周、月）、对账方式（全额、差额）以及允许的误差范围等。

4.对账流程

这里就是对账的核心模型，需要按照之前设定的对账规则，对采集到的账源数据进行比对。不一致时，则生成对账差异。

        a.比对未匹配后，一般不会直接生成差异，而是设置一定的等待期，避免由于日切、同步延迟导致的数据误差。

        b.会按照配置生成一定的批次，相应的对账结果会绑定在某个批次下。

        c.

5.差异处置

对于对账中发现的差异，需要进一步分析和处理。可能的处理方式包括人工核查、系统自动调整或发起冲正等。

常见的差异类型，包括长短款、信息不符等，这里需要基于不同的差异类型，来进行相应的处理。

6.报表和报告

将对账结果以报告的形式输出，供财务人员查看和处理。

所以一个成熟的对账平台，在以上各个环节都是准确、高效、简便、灵活、易用、易理解的。这个过程可能涉及到的流程和数据如下图所示。

三、技术难点及解决方案

那么上面的架构在实现上有什么难点呢？在过往经验中，列出了一些问题，大家可以共同讨论。

1.账源数据各部相同，如何实现配置化解析，提高接入效率？

  使用一些数据解析工具，将数据提取逻辑抽到配置层，有新的数据接入时则可简化提取的工作，常见的工具比如springel、jsonpath等。

 2.由于规则配置不常变动，常会考虑使用redis，需要注意什么？

   redis作为纯内存操作的kv db，支持持久化，读写快。使用redis需要考虑的问题，在这个场景下也需要解决。

        a.缓存雪崩，支持降级为本地缓存，另外redis考虑备份及预热

        b.缓存穿透，使用布隆过滤器，或者缓存空值等

        c.一致性问题，双删策略或者异步更新。

 3.如果账源数据分表，需要1:1对账，有什么好的设计逻辑？

        现在一般都是大数据进行批处理，这里就这种情况做一些比对逻辑的说明。

        账源数据做比对，一定存在单号的关联关系。这里我们使用单号做分表，轮询每一张表，分批查询初始态的账源数据，在循环处理单条账源数据，逐条做二次查询并输出结果，更新状态。这样的逐条比对，数据库的压力还是比较大的，优化的话可以考虑基于批次分页查询。

四、小结

         对账系统的难点主要集中在数据量大、核对准确性、差异处理紧急以及资金压力大等。通过构建完善的对账系统、引入AI技术、优化数据采集、加强运营等解决方案，可以有效提高对账效率和准确性，降低资损风险，提高资金利用率。