一、清算主体设计

清算的故事：从两百年前老罗斯柴尔德打通不同银行间银票的通兑开始，银行间清算业务就一直延续到现在。当年，老罗斯柴尔德拉拢一帮银庄的掌柜跟他们商量，’以后我的客户拿着我家的银票可以到你家取金币，然后你再拿着银票到我家取金币，作为回报我也允许你的客户到我家取金币’，从这个时候开始，标志着现代银行的通存通兑业务就开始了。由于大多时候双方客户都有交叉，实际需要相互取的金币并不多，比如你的客户在我这里取了一千金币，我的客户在你那里取了八百金币，然后我们两家一比对账本双方认可，你再给我两百金币、银票一交换我们双方的账就清了，这个过程就叫清算，其中比对账本的过程就是对账。

1.1 场景分析

结合上面的故事，我在做具体几个说明：

  1. 两家银行之间不会真的在清算后把金币押送给对方，因为现在有人民银行这个总管家，只需要告诉人行把我存在她那里的钱给你就可以了，然后人行就会根据清算所使用的工具，将我开设在她那里的法定准备金账户或其它清算账户上的资金划扣给你。这种划扣方式也叫作支付系统划汇清算。
  2. 对账时可能到我家对账，也可能到你家；如果你是人行一类的上级机构，那我就去你家对账；如果你是其它的商业银行，那我们就好商量，在哪里对都一样；如果你是农商行、支付宝、社保等第三方托付机构，那就到我家对账。这里的到我家是指按照我行定的对账流程和格式进行对账。
  3. 不同银行的行外清算模式不同，我的客户可能要在我们之间清算结束后才能拿到钱，因为你可能怕我的客户在你那里取了钱最后我不给你，你为了保险起见会要求我先存一部分钱在你那里，也就是到你行开设用于清算的同业头寸户，然后你才会在交易发生时就把钱给我的客户。这种方式也叫作头寸户清算。
  4. 我们两家银行间的清算可能出现清算户余额不足的情况，这种时候清算就会停止，然后等待对方来账，来账够了才会继续清算往账，一般这种情况出现的概率比较低，出现这种情况基本属于清算事故，头寸管理员可能会“挨板子”。
  5. 清算动作可能在每一笔交易后都会发生，比如使用大额实时支付系统时；也可能是一批次的交易发生一回，比如使用小额批量支付系统时；如果通过总行清算，无论使用大小额支付系统，其每一次的清算资金都需要在头寸管理员指定的安全范围内，超出这个范围的清算批次就要排队，否则可能影响银行的存款准备金率考核。

上面这几个要点简单的说明了一下，人民银行、商业银行、支付宝等之间的清算流程。
各商业银行的头寸管理、流动性管理，货币同业拆借利率SHIBOR等都是基于清算需求而产生
—

1.2 对账实现

接下去，结合具体的场景在来看对账的具体如何实现

场景一：1，持卡人张三于2015年8月4日持工行借记卡，在中信银行自己布放的缴费POS终端上，成功缴了一笔200元的电费（实际是缴给电力公司A），中信银行收单，缴费交易执行交换费单笔0.10元，转接费0.05元。

1、分析：该例子发卡行是工行，收单行是中信银行，支付类型是缴费交易，手续费是发卡行收取0.10元，银联转接费收取0.05元，这些费用在跨行清算中，统一由收单行中信银行先行支付（至于中信银行和其对接的商户之间的结算不在本次清算中），故清分处理如下：

20170927_210634

2、 进一步分析：收单行中信银行在跨行清算中，先出0.15元的手续费，其实是不包括自己收单行的收益的，按照收单行的收费比例0.08%，中信银行需要向对接的商户（电力公司A）收取：200元*0.08%=0.16元手续费，扣除先帮商户出的0.15元，即自己的手续费收入是0.01元，即商户在中信银行开的结算账户的记账如下：

20170927_210719

这个是我们最传统的一个收单业务的清算记账

场景二：持卡人李四2015年8月4日持招行贷记卡，在深圳沃尔玛商场（直联商户，工行收单）成功刷卡购物1000元。假设消费交易执行交换费0.7%，转接费0.1%，商户的扣费比例是1%。

1、 我们先分析清分对象：招行-发卡行，工行-收单行，直联商户（深圳沃尔玛），转接行-银联。 清分先处理银行卡消费支付部分

20170927_211110

2、 接下去，我们在考虑手续费部分的清算部分
消费交易费率：发卡行：0.7%，转接：0.1%，则发卡行和转接行分别获得手续费收益是：1000元×0.7%=7元，1000元×0.1%=1元，这些手续费第一次清分先从收单行出，即收单行付出手续费：7元+1元=8元

20170927_211209

将两个会计记账分录进行合并
20170927_211244

3、 接下去，我们在考虑收单清算，即对收单行的资金需要在直联商户进行二次清分

20170927_211415

4、接下去我们把跨行清算，和商户侧清算的会计分录再合并

20170927_211452

各个清算账户的借贷进行相抵，计算出对应的债权和债务关系，清算账户余额=贷方累计额-借方累计额。
20170927_211519

这个是清算的核心思想，所以在清算的系统设计中，会为我们的每一个收单商户开立一个结算账户，基于结算账户，通过会计分录的计算，得出需要给这个商户（结算账户）资金划付多少人民币

对账主体很多样，可以分为总行级平台与外部系统的对账；一级分行或二级分行平台与当地外部系统的对账；与单一或多个外部金融机构的对账；单一产品与外部系统的对账；多个产品通过共同的接口与外部的对账

因此在设计结算账户会因为多个对账主体进行会计科目细分，最后在进行汇总合并；同时由于银联是23：00日切，支付宝微信是24：00日切；双方对账时间点可能不一致，如果包含日切时间点后的数据，可能还需要转移到次日的对账文件中

二、主题一Q&A

Q1：关于场景一，工行会计分录是应该借：客户银行存款 200 贷：交换费收入0.1 银联清算款 199.9吗？
A1：不对，0.05是银联的发卡转接费，工行是发卡行，收取了0.10的发卡手续费
20170927_212523
A2：图片的借贷表示资金方向，工行每做一笔交易，账务系统应该会有会计分录，而且借贷必相等吧
A1：嗯，是的，对于工行机构内部是借贷必相等。我这里的会计分录是清算主体的。不是账务系统，而是通过清算实现的结算账户的会计分录处理
A2：清算主体是人行？
A1：嗯，跨行清算为人行大小额系统，如下图会更清晰一些
20170927_213006
**
Q2：如下图是人行等会计分录？
20170927_213216
A1：嗯，是的，也可以理解为大的清算系统；对于收单机构而言，其实相对简单，就处理商户侧的结算账户。但是为了说明人行大小额系统、银行跨行清算、收单机构清算这几这之间的关系
A2：嗯，支付机构在人行好像没清算账户。只能通过银行清算
A1：嗯，也可以通过银联
**
Q3：在人行大小额系统里，只有银联等少数清算机构才能主动发起借记交易，银行是不能发起借记交易的对吧？
A1：嗯，一般都是通过人民银行这个大枢纽
A2：对，只有银联，银联可以看成清算的一部分
A1：跨行ATM取款也是这个原理
A3：全国支票影像交换系统也含在央行支付体系里
A2：跨行业务本身就是央行职责
A1：其实支付宝直连银行，变相承担了跨行业务的职能；
A2：那种不算
A1：所以支付宝内部也非常强调头寸管理和流动性管理；人民银行要求切断支付机构直连银行，目的也是比较明确的；规模也不小了，而且绕开了人民银行的监管哦。其实这个讲完，应该大家也比较容易理解网联为什么诞生，承担什么职能了吧？
A2：特定历史条件下的产物，国家的金融体系架构是不容挑战的
A4：支付宝单独抽象了一个清算机构，内部自己玩
A1：嗯，是的，内部自己闭环了。其实大家再可以推演一下支付账户的账务系统
***
Q4：银联对账完账到底怎么划转的？
A1：其实原理是类似的，结算账户～支付账户，也是通过人民银行大小额系统划拨的，然后再具体划付到各收单机构

三、差错处理

各位，我们开始前先回忆一下上次讲的清算主体。清算主体、结算账户、清算主体的结构~

今天为了更贴近于大家真实工作的场景，对于第三方支付公司而言，对账涉及到与渠道（银行）对账、与下游商户对账、自身系统间对账。

大家回忆一下借记、贷记结算账户的概念；分别对应银行渠道结算账户、商户结算账户、自身系统间对账（内部过渡结算账户）

3.1 对账

对账，我们一般称为勾对，第三方支付公司与银行间的勾对，根据勾对两种不同性质的操作，分别对应支付交易的信息流和资金流。信息流可理解为业务对账／交易对账，资金流可理解为资金对账。

说了这么多，就出现来4个对账文件：支付公司信息流文件、支付公司资金流文件、银行信息流文件、银行资金流文件。

总结一下，我们说的对账是2种概念上的对账：

理论上对于一家第三方支付机构、信息流和资金流应该是完全一致和匹配的

如果出现交易数据和实际应收款项存在差异，那么说明系统存在严重的bug，需要查询问题原因，也就是上面所述的系统内部对账的一种，交易系统和账务系统（结算系统）的数据匹配，试算平衡

3.2 差错

接下去，我们分别对信息流对账和资金流对账的几种可能出现的差错，进行展开介绍：

  1. 情况一、支付公司信息流没有，而银行有的差异，可能是因为支付公司支付核心交易数据的丢失、银行的掉单，如果是银行的掉单，由支付公司的运营登录银行网银确认后，做补单处理，并将差异表中该记录核销。（这句话我翻译成技术语言，就是说的我们说的交易系统记录的这笔交易记录支付状态为未知或者失败，实际银行侧该笔扣款记录已经扣款成功，也就是我们常说的多流水）

出现这种差错，也有2种不同的处理方向：

处理方法：这种情况为了避免对商户划付延迟，一般第三方支付公司将这笔交易进行挂账处理，实际按照该笔交易成功资金结算给商户，并在会计分录中记录该笔挂账，待确认，需要技术人员核查具体造成这种情况的原因

现在2种差错情况都介绍好了，接下去，我们分别介绍出现这2种差错的原因，便于大家后续排查

  1. 情况一、支付公司资金流（信息流）没有，而银行有的差异
    可能原因如下：
    1）银行日切晚与支付公司核心账务系统；
    2）支付公司账务核心系统与其他系统间的掉单。一旦出现，则会出现长款（即银行不应该结算而实际结算）的现象，对于因日切导致的差异，在第二天的对账中系统会自动解决，其他原因的，需要技术排查。

第一个原因大家应该再熟悉不过了，银联CUPS 2.1系统的日切时间是23：00，而一般对互联网公司的日切时间是24：00，中间存在1个小时的时差就会导致多流水，针对这种情况每个支付公司都有自己的解决办法处理这个1小时的差异，因为这种造成的其实也是假多流水，不是简单的进行退款~

第二个原因就是系统原因导致的，随着互联网交易的并发和用户交易量不断上升，尤其是天猫双十一，需要技术人员不断调整系统架构，例如使用redis、mangodb等NOSQL技术不断优化系统架构，当然大家也可以深入学习铁手的那篇支付系统的演变升级的帖子~~
（美联支付体系架构演进（下） - 容量提升）

  1. 情况二、支付公司资金流有，而银行没有的差异
    这种情况，也就需要先分析是否由于日切时间差异导致，如果是非日切导致的原因，就需要找银行追款了

对以上进行总结下，业务对账，即信息流对账，支付公司的交易流水与银行的交易流水间核对，保障支付交易完整入账。资金对账，即资金流对账，支付公司的入账流水与银行的结算流水间核对，保障银行入账流水与实际入账资金的匹配。以上是必要的2个步骤，一个是保证用户的支付都完整入账，一个保证用户支付的钱都流入银行备付金账户。

因此一般业务运营中心还有专门的经办、复核岗位，用于确认核销银行来款，确保实际资金进入实体银行备付金账户，这个时候钱是真实的钱，而不是交易系统的一堆数字而已~

对于第三方支付公司与银行侧（渠道测）完成对账后，针对大型的互联网公司，一般会商户侧也会要求参与对账，也就是我们商户的交易信息流与支付公司的交易信息流的二次对账

目的是为了确保商户自身的订单状态与实际交易状态结果相一致，如果商户侧自身存在与支付公司交易信息流不一致的，那么互联网户商户自身也需要排查是否存在系统原因和优化

当然随着目前业务的不断状态，很对第三方公司参与消费金融、理财产品等，因此对于各内部系统统一调用支付中心后，也需要进行业务对账，确保相应的订单状态的最终状态的一致性

今天会计分录没有具体展开说，其实就是应收应付、实收实付，银行存款几个科目的借贷记分录。这块比较简单，不做赘述~

四、主题二Q&A

Q1：大家会有用到应收应清算吗？待清算到应清算
A1：这个就是日切啊~ 我想应该都会用到的吧。
**
Q2：没有应清算会有什么问题呀？
A1：资金流的数据哪里来，复式记账的优势也就体现在这里；复式记账法是以资产与权益平衡关系作为记账基础，对于每一笔经济业务，都要以相等的金额在两个或两个以上相互联系的账户中进行登记，系统地反映资金运动变化结果的一种记账方法。如果不用复式记账，就是单边账，也是没有问题的，但是系统一旦出现问题也比较难以发现
**
Q3：代发代扣这块业务，对账是怎么处理的？跟支付交易对账有区别吗？
A1：代扣和消费一样，代发是反向资金
***
Q4：日切时候跳过应清算，暴力点从待清算到银寸，是不是支持的场景比较局限不够灵活？？
A1：是的，非常暴力，而且万一中间系统出什么问题也容易被忽略，最后看似一致，实际埋下隐患；对于不同日切时间点，不同币种间不够灵活，后续的差错处理也无法和之前的交易联动，又回到了总账模式；我为什么之前一再强调清算主体设计，可以再结合我之前说的，应该就能想到中间的差异了；总结起来，冤有头债有主～
A2：想不到一个好场景来体现它的优势
A1： 我就用之前秋秋老师说的境外收单的场景作为例子来给你分析

Q5：信息流的勾兑也就是每日上游通道提供的对账文件和支付机构的交易或结算信息进行勾兑，而资金流核对是由各支付机构的备付金管理人员核对网银实际收付流水。 这么理解对么？
A1：信息流勾兑一般优先指的是银行或者渠道侧，基本理解是正确的
***
Q6：我之前支付公司的系统设计跟大家的好像都不一样，我之前做的是聚合支付业务，走的是大商户模式，为什么我公司出来的差错基本都是出现短款而别的公司都是出来长款，这个是系统设计的不同吗？
A1：那是因为你们设计只考虑业务信息流对账，以各渠道方为主；对于你们这种模式，也不太可能出现长款，因为是各支付机构和银行侧渠道测对完账之后再和你们对账
A2：以渠道方为主就会这样？
A1：也不全是，还有一部分就是你们系统设计的问题，对于渠道方的超时处理
A2：我们就是支付机构，我们渠道方就是银行
A1：我举个例子，你用支付宝支付，支付宝渠道方没有返回明确成功，你们系统会怎么处理
A2：肯定是没有成功
A1：但是银行这笔确实成功了，你们失败了，这就会产生长款
A2：只有明确成功才会显示
A1：嗯，那长款一般都是这个原因产生的，你们没有就要检查代码了；至于短款也是上面的原因，是不是没有明确成功状态，也返回了成功，导致了短款
A2：我那个业务就没有见过长款，但是之前跟群里面的朋友聊天发现有朋友也做这个业务，基本没有出现过短款情况，都是长款
A1：建议针对超时，异常的交易仔细排查哦。嗯，不论长短款，都要查清楚产生的原因，短款尤其应该
如果都不知道怎么发生的，这支付也做的太糊涂了
A2：这个就让我感觉很奇怪了，我还以为都是短款，基本不会出现长款呢，我离开支付公司有点久了，细节有些快忘记了，那个对账流成应该是支付宝微信先和银行对，对完后，银行跟我们对，我们自己内幕对，然后给客户打钱
A1：嗯，对账流程没有问题啊，银行代理支付宝微信；还是要细节，短款交易出现的具体原因；先排除是不是日切时间不一致的问题；接着再查具体交易状态是不是记录的有问题，有没有系统把不明确的交易记录成成功了
A2：主要是跟大家都不一样，我还以为有什么问题
A1：其实你把这个切块来看，也是一样的；不管银行和支付宝微信怎么对账，银行对你来说就是一个渠道
A2：是的，是一个渠道
A1：建议以后做一个运营平台，对于这种差错处理透明出来，明确问题原因
A2：是有的，我们有这个东西；主要是每天都会出现这种短款，各种奇葩情况
A1：好吧。。。。那就要考虑系统架构优化了
A2：这种情况是极少数；极为特殊，只有民生渠道会有
A1：嗯，不管怎么样，都要杜绝啊，短款亏得都是自己的钱
A2：其实不会，原因是只要短款就会挂单，不给客户钱，客户发现了回电话过来，我们就会去排查，如果是那种极特殊情况的话
A1：。。。。好吧，原来是这样啊。。。这种客户都跑光了，对于商户来说，太糟心了
A2：看来我这里能有短款是有原因的，整套业务流程允许短款，估计大家的都是一定付的，所以系统设计上就不会有短款
A1：嗯，是的，一般挂账挂在机构内部自己的，自有银行账户贴钱先垫付，然后具体该是短款核销（确认损失），还是找银行追款（损失折回）；这个一般都有标准的制度流程保障的，短款很严肃的
A2：一般我们都是能找回来的；没有发生过损失的情况，短款多了，也就习惯了
A1：嗯，但是从会计制度来说不严谨。这种一般对于系统也是一种指标，一个强壮的，稳健的支付系统，差错率应该非常低的。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。