支付对账三部曲之资金对账系统设计篇

楼下小黑哥

共 4621字,需浏览 10分钟

 · 2022-01-19

上篇文章我们讲到千万级对账系统整体的系统架构以及完整的业务流程,那今天这篇文章我们来聊下对账结束之后流程 - 资金核对

何为资金核对?

上篇文章聊到对账,其实属于业务明细对账,即我方交易订单与渠道明细的订单的核对,这个对账过程需要逐笔核对。核对成功,代表双方的订单数据都没有问题。

既然成功了,对方需要把这笔钱给到我们。但是实际情况下,可能是为一些问题,导致这笔钱最后没给我们。

所以这个过程我们也需要核对,这个核对过程就被称为资金核对。

那资金核对,需要拿应收应付与实收实付参与核对,那什么是应收应付?什么是实收实付?两边数据怎么获取呢?

先不用急,下面文章会详细解释,我们先来看下资金核对整体流程。

资金核对整体流程其实与业务明细对账流程类似,分为三部分:

  • 资金数据收集
  • 资金数据核对
  • 资金数据差错梳理

资金核对过程,核对某个渠道某个商户号实收实付与应收应付的数以参与核对数量会很小,所以整个过程都在对账系统内完成。

资金数据收集

上面我们说过资金核对的数据分为两部分:

  • 应收应付
  • 实收实付

那资金收集这一部分,其实就是对应这部分数据的收集。

实收实付数据收集

实收实付的钱,其实就是对方支付机构/清算机构清算给我们结算款,那这个实际对应的是『银行』账户实际资金的变动。

『银行』账户分为两种,如果是一般公司,那这里『银行』账户指的就是某家银行对公账户。

那如果是支付公司,这里的『银行』账户指的是备付金账户。

这两类账户分别有两种不同数据处理措施。

实收实付数据收集之后,存入银行资金表,表结构如下 :

关键字段如下:

  • unique_id 流水ID,用于标识唯一资金流水信息
  • source  用来标记资金来源
  • settle_date 资金结算账期
  • bank_no 银行账号
  • debit_amount 借记金额
  • credit_amount 贷记金额
  • channel_code 渠道编码
  • remark 摘要信息
  • opposite_bank_no 对手账号
  • merchant_no 渠道商户号

channel_code 与 merchant_no 一般会有多个存在,所以我们在实收实付数据收集过程中,需要根据一定匹配规则,匹配指定的 channel_code 与 merchant_no。

另外上面 settle_date 为资金结算账期,这个跟交易发生日期并不相同。

资金结算账期一般为 T+1,那交易账期为 T 日的交易,资金结算过来账期将会为 T+1。

这么看比较难以理解,举个例子,2022 年 1 月 7 日(周五)发生一笔 100 w 的交易,这笔交易账期就是 2021 年 1 月 7 日。

由于这个渠道资金结算周期是 T+1,也就是说 1 月 7 日,1 月 8 日,1 月 9 日的交易资金,将会在 1 月 10 日统一结算。

所以说这里资金结算账期将会为 2022 年 1 月 10 日。

银行账户数据收集

银行账户实际资金变动,最终都会体现在银行结算账单上,那我们可以通过下载结算账单,解析获取实际变动资金信息。

这种方式需要运营人员手动下载银行账单,再上传账单到对账系统,需要一定人工参与。

如果银行账户不多,可以参用这种方式。

那如果银行账户较多,可以考虑对接银企直连,这样可以通过对账系统自动拉取资金变动详情,减少人工参与。

下面以手动下载对账单为例,不同的银行下载资金结算账单格式都不太相同,系统上需要对这种情况做自适应配置。

招行资金账单格式如下(部分字段未显示):

我们需要从账单上收集如下数据:

  • 交易日期
  • 银行账号
  • 借方金额,可以理解为该银行账号转出的金额
  • 贷方金额,可以理解为该银行账号转入的金额
  • 摘要,转账附言
  • 流水号,这笔转账唯一标识号
  • 银行余额

如果每个三方渠道绑定结算银行账户信息都不一样,那我们可以使用银行账号,区分不同三方渠道应收应付数据。

但是实际操作过程中,我们可能使用同一个银行账户接受多个不同三方渠道实收实付数据 ,所以这里我们需要有一个匹配规则,当某条流水匹配上这个规则的时候,那么这条流水就是某个三方渠道实收实付数据。

由于每个三方渠道资金转入时,银行流水摘要都不太一样。有些三方渠道,比如支付宝、微信可以设置转入银行的附言。

举个例子,支付宝结算款我们可以设置为 支付宝xxx(商户号4位尾数)账户往来款

微信结算款我们可以设置为 微信xxxx(商户号4位尾数)账户往来款

通过这种方式,我们使用银行摘要或则备注,当做匹配规则。如果匹配成功,将其转换为某个渠道某个商户号实收实付数据。

备付金账户数据收集

上面通过银行资金结算单的方式,只适合非支付机构。

如果是支付机构,由于目前所有支付机构资金集中存管在人行的备付金账户,简称 ACS 账户,所以没办法使用上面这种方式。

不过好在目前人行给支付机构开通大额系统的权限,那所有通过大额系统出入的金额,支付机构侧都可以收到银联或网联转发的 ACS 动账通知。

通过这种方式,我们可以自动监听 ACS 的动账消息,自动收集应收应付数据。

人行 ACS 动账消息有多种不同类型的,支付机构结算款信息,网联/银联会通过调用 hvps.141.001.01-即时转账报文发起结算,

所以这里我们只需要监听该报文类型即可。

我们从这个报文数据收集到以下数据:

  • 交易日期
  • 消息流水号
  • 备付金账号
  • 借记金额
  • 贷记金额
  • 对方账号
  • 备付金余额
  • 摘要

每个渠道发起 ACS 动账摘要信息都不太相同,所以我们也可以使用摘要信息去做匹配,将其转换为某个渠道某个商户号实收实付数据。

一些典型 ACS 渠道摘要如下:

  • 银联支付宝:支付宝条码清算xxxx(商户号)_0106(账期)
  • 网联微信:微信条码清算xxxx(商户号)_0106(账期)
  • 银联无卡支付:0105(账期)银行卡清算

这里需要说明一下交易资金流水账期,一般来说资金结算周期是 T+1,那么一般都是在 T+1 日那天结算过来。

也就说我们收到 ACS 动账消息中交易日期就可以当做是资金流水的账期。银联/网联微信、支付宝就是这种情况。

举个例子,2022 年 1 月 7 日交易结算款,会在 2022 年 1 月 10 号结算。也就说 2022 年 1 月 10 号将会收到一笔结算款 ACS 动账消息,那我们就可以直接把这个 ACS 动账消息中账期当做资金结算流水的账期。

但是有些渠道就比较特殊,比如网联银行卡。

网联银行卡结算周期也是 T+1,但是 T 日会有两个结算场次。

T日9点的场次包含的是T-1日15:00到T日9:00到交易批次。T日15点的场次包含的是T日9:00到T日15:00到交易批次。其中9:00提供的交易批次算作第二场次。

那这里网联银行卡资金账期就不能直接使用 ACS 动账消息中账期,我们需要经过计算,使用 ACS 动账消息账期经过 T+1 计算。

举个例子,2022 年 1 月 7 日收到网联银行卡 ACS动账消息账期是 2022 年 1 月 7 日,经过 T+1 计算,网联银行资金账期为 2022 年 1 月 10 日。

应收实付数据收集

应收应付的数据,跟据对方支付机构提供的清算文件轧差计算汇总得出。

应收应付表结构如下:

关键字段如下:

  • unique_id 唯一 id,内部自己生成
  • settle_date 应清算的账期
  • bank_biz_date 业务账期
  • biz_type 业务类型
  • trade_num 交易笔数
  • channel_code 渠道编码
  • merchant_no 商户号
  • remark 备注

这里有两个账期,bank_biz_date 代表业务账期,settle_date 应清算的账期。

settle_date 应清算的账期是 bank_biz_date 代表业务账期经过账期类型(T+1/D+1)经过之后生成。

举个例子, 如果渠道账期类型是 T+1,那么如果应计算账期是2022 年 1 月 10 号(周一), 那数据如下所示:

业务账期应清算账期业务类型
2022010720220110支付
2022010820220110支付
2022010920220110支付

下面数据汇总的数据,我们根据应清算账期就可以查找这个账期内所有明细数据。

清算文件有两种类型,第一种对账明细文件就是清算文件,比如微信、支付宝。

还有一种就是提供对账明细文件,也提供清算文件,比如网联银行卡,这种就需要使用清算文件计算。

对账明细文件应收应付数据汇总

如果微信、支付宝这类对账明细文件就是清算文件,这种比较简单,我们只需要解析对账文件,轧差汇总数据即可。

这一步可以放到对账明细业务流程中,按照业务类型汇总得出以下数据:

业务类型+/-(收入/支出)
支付+
支付手续费-
退款-
退款手续费+
提现-
提现手续费-
退汇+

清算明细文件应收应付数据汇总

网联银行卡这类可以单独提供清算文件的渠道,我们就需要使用清算文件汇总计算。

这里以网联银行卡为例,网联会在 T 日日终两个小时之后生成资金结算信息,文件中包含 T-1 日15 点到15 点交易相关信息。

清算文件格式如下:

样例文件如下:

我们可以根据上面分项列表统计不同业务类型的汇总金额。

资金数据核对

应收应付与实收实付两端数据都收集完成之后,我们就可以开始资金数据核对。

这个核对过程相比对账核对就比较简单。

我们可以根据资金账期+渠道编码+渠道商户号查找两端数据。

举个例子,微信渠道资金结算账期 20220111应收应付明细数据如下:

业务账期资金账期业务类型金额
2022011020220111支付100w
2022011020220111支付手续费20w
2022011020220111退款10w
2022011020220111退款手续费2w

轧差计算应收应付金额如下:

应收应付金额=支付金额-支付手续费-退款+退款手续费=100w-20w-10w+2w=72w

再查找20220111实收实付明细数据如下:

资金账期借记金额贷记金额
202201110w72w

轧差计算实收实付金额=贷记金额-借记金额=72w-0w=72w

如果两端轧差之后数据相同,那么资金核对成功。

资金数据差错处理

有些情况应收应付金额与实收实付金额不等,核对不能成功,这种情况排除系统问题之后,一般都是当天账期实收实付金额导致。

这种情况可能原因是,比如银联无卡渠道,可能因为用户投诉盗卡,银联侧将这笔钱退给用户。这就导致当天结算款缺少一部分。

网联银行卡出金退汇,这就会导致第二天清算款增加。

这些情况比较多,需要运营人员排查这部分原因。运营人员排查到具体原因之后,可以在后台增加差错调整记录。

差错调整记录增加之后,实收实付金额将会重新计算:

实收实付金额=实收实付金额-借记调整金额+贷记调整金额

如果调整之后两端金额相等,资金核对成功。

总结

资金核对过程相比对账核对,不管业务流程,还是系统设计上都简单很多。

但是资金核对业务规则相对来说还是表复杂。这里对于刚接触的同学,重点了解资金核对业务规则,资金结算账期 T+1 计算规则,这些都比较绕。

讲到这里,我们以及了解业务明细对账以及资金对账,后面我们再来聊下对账三部曲最后一部-差错处理。

参考

http://www.woshipm.com/pd/4427117.html


浏览 290
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报