资金管理：二清、调拨、线下汇入

钱收上来以后还需要按照要求进行管理，不同的交易模型，不同的资金属性，需要依赖不同的资金管理手段，要做到安全合规，同样不同账户之间的资金需要基于业务需要进行调拨互转，而某些业务下存在的线下汇款业务的线上化需求也需要关注，本部门将介绍二清、调拨、线下汇入三块业务的资金管理相关的内容

全文10292字，建议先收藏慢慢看

1

二清

开车需要驾照，无证驾驶要坐牢；同样收钱管钱也不是谁能都干，商户的钱，用户的钱，谁都不能动，一分都不能少 ！

1.1二清背景

经济趋势，国家大力推动“互联网+”发展的背景下，涌现了众多的互联网企业。同时，中大型企业也纷纷尝试通过自建电子商务平台加速转型升级，以整合供应链上下游资源。互联网支付也面临着很多资金安全问题以及监管问题

监管要求，监管部门禁止没有支付牌照和支付资格的互联网平台开展网络支付业务，禁止其以自身名义搭建具有金融属性的类电子账户，禁止私设不具有真实交易背景、不受金融机构管控的资金池。

《非金融机构支付服务管理办法》，“非金融机构提供支付服务，应当依据本办法规定取得《支付业务许可证》，成为支付机构。”

支付牌照价格水涨船高，目前央行对于支付牌照的管控处于收紧态势，原则上不再发放新牌照，存量牌照严格审核，部分机构未获续展。支付牌照价格高昂，对于电商平台来说难以承担。

1.2什么是二清

“二清”，即二次清结算，指的是有清结算资质的机构将资金结算给入网的平台后，该平台再将资金清结算给其子商户，若该平台没有清结算资质的话，就属于二清了。如果平台的经营出现问题，资金又没有受到第三方的监管，这些“裸奔”的资金很容易被平台卷走，对于商家和客户而言，都不安全。，如图1所示

图1 典型的二清业务模型

用户在平台购买商品下单支付，钱收到了微信支付宝里

次日微信支付宝将资金结算给平台——第一次清算（合规）

资金在平台的自有账户中形成了资金池，该部分资金具有金融风险，平台随时可以携款跑路

平台再将资金从自有账户清算后结算给平台的商家——第二次清算（二清违规）

二清简单的说就是清结算的“无证驾驶”，要想不违规，就找个有证的开车带着你

1.3二清违规后果

无证经营相关业务肯定是不合规的，也有可能触发法律，为了维护商户以及客户的资金安全，国家肯定会大力监管，对违规平台采取停业整顿或处罚等手段，这里就不具体介绍了

1.4平台需求

B2B、B2C等各类型电子商务平台，或者具有代平台商户收款和结算的互联网平台，一般不具有第三方支付公司牌照，但是基于业务需要又有给商户清结算的需要，怎么办呢？

那就需要借助银行或第三方支付公司为其搭建支付结算网络。这也就是接下来要重点讲的两个方面：

“银行或三方提供的合规解决方案是什么”

“平台如何改造平台接入合规的支付结算体系”

1.5谁能解决合规

要想解决合规问题，最主要的是要有资质牌照，然后提供合规的资金监管账户体系，清算分账能力，合规的支付交易能力等等；现在有很多支付机构专门针对该场景提供了全套解决方案，像易宝支付的钱脉等，也有不少商业银行向市面提供了二清的解决方案，像平安银行，农业银行等

1.6合规解决方案

车本身没有违不违法，要看谁开，有驾照就合法，资金本身也没有合不合规，要看放谁手里，有牌照就合规。所以资金合规的本质就是“有牌照的机构管钱”，管钱的原则就是“谁的钱放谁的账户里”；合规要解决的核心问题主要是：

合规的收钱——支付交易，资金归集

合规的管钱——监管账户以及各方子账户

合规的分钱——清算清分

常见的合规解决方案的几个关键点如下面详解

1.6.1平台入网开户

入网就是平台与方案提供商签订合作协议并开通一些列账户的过程；开通资金监管户，手续费账户，垫资账户等，基于业务模式选择需要开通的账户类型

1.6.2商户开户鉴权认证

这是平台为自己的用户和商家申请开通监管子账户的过程，用户在支付的时候需要付款子账户，商家在清分收款时需要收款子账户

在开户时需要提供相关的资料，比如个人需要身份证信息，商家需要身份证或者营业执照等信息

在开完户之后需要绑定结算卡，可以用来向子账户充值或者结算款的提现，绑卡鉴权可以是多要素的鉴权或者小额打款鉴权，银行一般提供选择性

1.6.3资金账户体系

为了帮助平台做好清结算，需要完善的账户体系，账户分实体账户和虚拟账户，实体资金账户管钱，虚拟账户管账；业务的处理主要是虚拟账户之间账的变动，就是资金所有权的转移，资金并没有变化

比如用户付款100元给A商家，“100先充值进入用户付款账户，再从付款账户转到中间担保账户，确认收货后再从中间担保账户转到商家子账户”引号中的账务变动实际上只是虚拟记账，实际的监管户中的真实资金100元一致没动，如图2所示

图2 解决二清的资金流模型

所以基于不同业务节点或者说业务需要还需要分多个账户类型，用户子账户，商家子账户，平台收入账户，平台支出账户，总监管账户等，如图3所示

图3 监管账户账户体系设定

监管主账户：备付金账户，银行为平台开通的管钱的监管账户

平台收入账户：记录监管户中属于平台收入的部分，1个

担保账户：中间账户，记录待清分给商家的部分，1个

挂账账户：记录待清算的资金，1个

在途账户：记录待清算的交易金额，与挂账账户进行清算，1个

用户子账户：记录用户支付的部分，1个用户1个

商家子账户：记录结算给商家的部分，1个商家1个

1.6.4支付交易

合规方案还需要为平台提供具有竞争力的支付交易能力，可以收款，退款，支持商家提现，交易款的分账，账户间的转账等；机构一般会提供收银台，当然也可以允许平台继续保持原有的微信支付宝等收款方式，但需要将交易同步提交给监管机构，将资金归集到指定的监管账户，并通知监管机构进行确认收货后的分账

充值：用户向子账户充值

支付：用户购买商品进行付款

退款 ：支付成功的订单进行退款

清分：平台发起分账，将资金分给商家

提现：平台，用户，商家对子账户的资金进行提现到绑定的银行卡

内转：各子账户之间的转账

1.6.5资金归集

监管机构自有通道或者外部的微信支付宝三方收单通道，T日的交易收款再次日结算到对应的资金账户后，按照监管要求归集转入指定的监管账户完成资金的归集监管，如图4所示

图4 资金归集

监管机构自己的通道收款转入监管账户，记账到挂账账户

外部渠道的收款先有外部机构结算到平台的归集账户再转入监管户，记账到挂账账户

平台的补贴优惠券部分从自有账户充值到监管户，记账到垫资子账户

在途账户中记录实时上报的交易记录记账

1.6.6监管清算

监管机构的清算就是在T+1日对T日的交易金额进行清算的过程，清算的办法就是核销挂账账户和在途账户，当挂账账户的总金额大于等于在途账户在T日的总交易金额时则清算成功，否则T日清算失败，后续会再次执行清算直到成功

上面介绍了

在途账户记录的是实时的交易上报，相当于说用户支付成功了多少交易

挂账账户记录的是实际转入监管账户的资金

当挂账账户记录的总额大于等于在途在T日的交易总额时说明钱到位了，所以清算完成，清算完成的资金部分才能总后面的清分，清分给商家

例如

T日用户支付购买了100元的商品，微信支付了80，用了一张20的优惠券；用户支付成功后，实时上报监管机构，这时候在途账户入账100元，用户子账户转100到中间担保账户；T+1日微信给商家结算了80元资金（不考虑手续费）到平台归集户并转入监管户，记账到挂账账户，此时挂账账户金额为80元；T+1日为了完成清算，平台向监管户充值20元补贴到垫资账户；T+1监管机构清算时挂账账户80+垫资账户20=在途账户100，完成清算；完成清算后担保账户中的100元的监管资金将可以用于清分；平台发起清分请求，将100元清分给商家子账户95元货款，5元清分给平台收入账户；这时商家子账户中有95元，平台收入户中5元；商家可以将95元提现到绑定的结算卡中

1.6.7清分

清分就是用户确认收货了，或者商家服务完成了，要给商家结算货款了，平台向监管机构发起某笔订单的清分请求，将订单收款请分给各方的子账户的过程，完成清分后的资金，对账账户的主体可以发起提现请求，提现到绑定的银行卡中

1.6.8对账

专门的对账专题，不再具体介绍

1.6.9资金监管策略

监管策略就是监管机构要有一定的机制确保资金的合规和安全，监管账户能够确保资金的合规，但是因为平台具有发起清分以及代替商家发起提现请求的权限，所以在支付权限上要确保安全，比如已经清分给商家的钱不能再扣回来，除了用户发起支付退款之外；

因为如果允许平台任意发起清分扣款请求，那么商家的资金依然存在较大风险；但是平台有扣商家资金的业务诉求，比如差评要罚款；那么怎么办呢，一般情况协议里会约定扣款的一个比例，比如整体不能超过1%，这样既能够满足平台需求，又可以极大程度确保商家资金的安全

1.6.10资金流和信息流

在上面的监管解决方案下，从用户付款，确认收货，分账，商家提现，整个过程中的信息流和资金流如图5所示

图5 分账的信息流和资金流

信息流

用户付款成功，支付成功，生成订单

推送清算中心清算商家结算款与平台抽成

推送清分系统完成平台自有账务记账，并向监管机构发起清分请求

商家对钱包余额发起提现，平台请求监管机构进行出款

资金流

用户付款成功后T+1日渠道将资金结算给平台账户

资金再从平台账户归集到监管账户并记账到担保账户下

平台发起清分请求资金从担保账户转账到商家的子账户

商家发起提现资金从监管账户出款到商家绑定银行卡账户

1.7平台改造和对接方案

上面讲完了一般提供合规解决方案的银行或者支付机构的方案，那么平台如何进行改造和接入呢？其实看完6的方案部分我想大家已经基本清楚如何改造和接入了，接入合规跟接入一个通道非常类似，只是除了支付交易以外还有开户入网以及清分处理，下面罗列几个关键的改造点

支付系统的改造，支付系统的收款和退款需要实时上报给监管机构，将订单推送给交易接口完成上报

清算系统和清分系统，清算系统按成费用的计算，清分系统调用监管平台的清分接口请求清分处理，清分成功后平台资金同步要进行记账

账务中心的改造，账务中心为商家开通结算账户，其实本身不管接不接监管平台，平台都会有自己的账务系统，只不过此时商家的虚拟结算户与监管账户中的商家子账户是一一对应的

对账系统的改造，对账系统要完成托管体系的相关支付交易以及资金清分的核对

2

“二清”账务处理分析

基本将二清的事情以及监管方案和接入方法讲清楚了；但是发现还有一个点有很多朋友在社群咨询，那就是订单逆向退款时监管户的账务处理搞不明白，今天就详细介绍每个交易场景下的账务处理和资金变动情况，为了便于理解，不写会计分录，以更简易的流水账形式来阐述

场景设定：陈老师5号用平台打快车从立水桥南到奥森公园去遛贝尼，总共打车费用是50元，使用微信支付方式，选用招商银行卡进行支付；发现司机绕路进行投诉，平台经过认定司机估计绕路；7号平台平台退回打车款25元到招商银行卡

2.1交易基础信息

用户：陈老师

陈老师useID：521

司机：王师傅

王师傅商家ID：123

订单ID：1001

商品：快车服务

金额：50

支付方式：微信支付

支付金额：50

支付流水号：1111

2.2打款款支付成功

支付成功后，实时扣除招商卡50元余额；次日网联提交人行进行清算，资金从招商清算账户结算之微信备付金账户

2.3资金归集

6号资金从微信归集到监管机构的过渡账户，并进入监管账户，如图6所示

图6 资金归集过程

2.4平台清分处理

平台清算系统完成订单的清分，平台抽取30%佣金，结果如下

订单ID：1001

商品：快车服务

金额：50

司机：王师傅

王师傅商家ID：123

分账费用：订单收入35元

平台：平台

平台ID：0

分账费用：订单佣金15元

2.5平台基于清分结果分账

平台基于清分结果，向监管机构发起分账指令

司机：王师傅

王师傅商家ID：123

分账费用：订单收入35元

平台：平台

平台ID：0

分账费用：订单佣金15元

监管结构接到指令后进行分账处理，如图7所示

图7 资金分账

平台收到监管机构的分账成功通知以后，为商家在平台账户中心的结算账户进行记账处理，如图8所示

图8 平台为商家记账

2.6司机提现

王师傅看到钱包余额增加了35，便提走15元，钱包余额剩余20元；此时平台先扣除平台平台商家账户-15，如图9所示

图9 商家提现扣账

然后请求监管机构进行出款，监管机构收到提现指令以后，将15元打款至王师傅的结算卡中，如图10所示

图10 监管户对外付款

2.7申诉退款的业务平台处理

假设7号退款当天，平台微信账户已收款入账100元（不考虑微信手续费），如图11所示

图11 收款入账

陈老师发起申诉，这25元完全由商家来出，请求微信退款前，先扣除商家在平台账户中心的账户余额，由于商家账户余额是20不足，所以先进行垫资充值5，如图12所示

图12 垫资账务处理

然后再扣除订单收入退回的25，如图13所示

图13 退款的账务处理

商家的平台账户账务处理完以后，平台平台通过微信原路退回给陈老师25元，此时微信账户剩余资金75元，如图14所示

图14 支付平台账户退款给用户

2.8退款请求监管机构做监管户的账务处理

此时因为商家的实际资金不足，只有20元，所以清分请求指令是2条，先对商家进行垫资充值5元，如图15

图15 退款业务在监管侧的账务处理

然后再做订单收入的分账撤回25处理，如图16所示

图16 订单收入的分账撤回

另一个场景：如果王师傅没有进行提现，那么就不需要垫资，就很好处理了，直接由商家子账户退回25即可，如图17所示

图17 订单分账直接撤回

2.9微信后续的资金归集

因为微信在7号退回了25给陈老师，所以微信在8号只需归集净额75元即可，此时待分子账户余额是100元，如图18所示

如图18 平台内归集

发现微信账户在7号收了100元，所以应该要分100元，但是退回了25，只剩75了；不过归集75到监管户发现微信退回的25在监管户里从商家子账户撤回到了监管户，正好弥补了微信退回的25；使得待分金额依然有充足的100元；所以发现监管户的钱并不需要退回到微信去，这个大家注意

3

调拨系统

大家可能对资金调拨不太陌生，但是对调拨系统可能就接触的少了；那么什么是资金调拨系统呢，其实就是系统化实现资金账户之间资金的转移过程的系统；可大可小，可简可繁；一个拥有四五百个备付金账户的支付机构，这些账户之间资金调拨频率和体量是巨大的；今天就聊一聊资金调拨系统的设计方法，以及需要关注的设计点

3.1资金调拨

都知道一个企业，支付机构，银行等都会用于多个银行资金账户；每个账户都会有不同的用途，每个账户中也会有不同体量的资金；当然每个账户中的资金的利息以及其他收益率也是不同的；所以基于业务需要开通了众多资金账户，又基于利益需要或者合规需要又将资金按照一定规则存放于不同的资金账户；这样就会在一些场景下需要将一些账户的资金转到另一些账户中去使用；这个转移资金的业务就是调拨业务，如图19所以

图19 一个集团的银行账户体系

3.2为什么要调拨

调拨系统的建立一个是基于调拨频率和调拨效率的需要，另一个就是可以实现全线上化的资金监控和管理；例如支付机构，会在一家银行开通备付金监管户，在其他很多银行开通备付金收付户以及备付金汇缴户；基于监管需要资金日终会向上归集到监管户；日间又基于出款业务需要，将资金调拨至各个备付金收付户；因为账户数量多，调拨频繁，可能几分钟就需要调拨一次；那么人工处理是不现实的；这时就需要基于具体资金账户的资金需要通过系统完成资金的自动调拨，如图20所示

图20 多备付金账户下的出款业务（断直连之前）

3.3调拨的方式

最原始的就是可以通过人工做调拨：比如资金同事到对公户网银平台，操作资金转账，将资金划拨至另一个公司名下的账户里，或者一个集团子公司名下的对公账户里；这种模式多用于资金调拨频率低，资金账户数量少的情况；一般的企业基本人工调拨即可满足业务的需要

另一种就是系统自动调拨：就如2中提到的场景，基于出款需要或者其他业务需要实现系统化的自动调拨；当然调拨系统也可以是一个简单的调拨收后台，由人工提交调拨单据，发起调拨请求；另一种就是完全基于业务实际资金需要自动调拨申请；比如基于实际出款的总量，来决定目标出款账户资金余额是否充足，不充足时需要调拨多少，要从哪个账户调拨资金等系统处理，如图21所示

图21 调拨系统定位

3.4资金调拨系统概述

调拨系统就是接受业务系统的调拨申请，完成调拨的判断以及调拨的发起；并记录所有调拨的业务数据的资金处理系统；下面是一个比较通用的调拨业务架构，如图22所示

图22 调拨业务架构

调拨的请求来自各业务方，比如出款业务，还款业务，归集业务，或者其他的需要划拨资金的业务

业务方将要发生的业务封装成调拨请求，发送调拨系统；调拨系统来判断该次需不需要进行资金调拨

这个过程需要去查询出款账户的资金余额是否充足；预计其他资金预留规则综合得到需要调拨的资金数量

然后生成调拨单据；基于调拨通道的限额情况对调拨单据进行拆单处理，然后生成调拨记录

最后发起调拨打款申请完成调拨

3.5资金账户管理

资金账户管理其实就是维护所有可以参与的账户信息；一个是为了获得调拨需要的账户信息，另一个就是资金安全需要，仅允许在账户管理里存在的账户才能执行调拨业务；其他账户不允许作为调拨收款账户，如表1所示

表1 账户信息管理

3.6调拨通道管理

因为资金调拨的金额一般都比较大，一般的通道是无法满足的；所以就需要签约一些大额通道；比如银企直联，银行直签的巨额通道；我接过的一些超大额像单笔10亿，日累计50亿的通道；可以满足业务需要，如表2所示

表2 调拨通道管理

对于一般企业来说银企直联就可以满足需要

3.7调拨预留规则

基于业务需要判断资金调拨金额的时候其实还要考虑其他情况，比如调拨收款账户需要保留一定的资金量，不能全部用完；也就是有一个存量规则，如图23所示

图23 预留资金模型

还有一种情况对比高频调拨出款的账户，比如一个支付机构的用于出款的备付金账户，可能每5分钟就需要一次批量出款；每5分钟就需要进行一次资金调拨；在如此高频率的调拨场景下如果预设一个底线存量那也是没问题的；但是考虑到资金的利用效率，以及收益情况，另一个原因就是降低调拨频次，可以设定为30分钟调拨一次；因为每5分钟有一次出款批次，为了保证金资金充足，就需要基于一定的算法来保证金30分钟内的每次出款的资金充足；这时候，就需要一个合理的算法来计算每次调拨需要为接下来的30分钟的出款预留资金；假设这个预留资金为Ax，x代表调拨的场次；这里不过多介绍如何计算，大家可以思考一下这个算法；可以再交流群沟通；假设得出的每个场次的调拨资金为 Mx，如图24所示

图24 多场次调拨的账户预留模型

3.8调拨金额计算

基于上面的假设就知道了每次调拨应该调拨多少资金了；假设业务第2场次要从“招行1001账户”出款10亿；此时请求到调拨系统

出款需求：chukuan=10亿

此时通过招商查询接口查询到此时的账户余额是9亿；并且查询到账户在第2场次后要预留资金量为5亿

所以本次是需要调拨资金的，告诉业务方账户余额不足请等待调拨结果

这时计算需要调拨的资金量：xudiaobo=10亿-9亿+5亿=6亿；所以需要调拨的资金量是6亿人民币，如图25所示

图25 调拨逻辑流程

查询获得给该账户调拨的账户是存管户2001；生成调拨单，如表3所示

表3 调拨单管理

由于通道限额单笔是5亿，所以需要对调拨单进行拆单，如表4所示

表4 调拨拆单管理

3.9账户调拨关系模型

该模式就是决定哪个账户往哪个账户调拨，利用出款账户来查询要从哪个账户调拨资金，如表5所示

表5 调拨关系管理

3.10调拨过程

（1）调拨发起

主要是业务发起以及人员从后台直接发起；所以需要向外提供调拨申请接口，后台需要调拨申请管理功能；这个就不过多介绍了，相信大家都能设计出来；认真思考一下吧

（2）调拨审核

这个基于实际需要不同类型的调拨请求需不需要审核；视情况而定；人工提交的调拨申请肯定是需要审核的

（3）调拨记录

调拨记录主要是调拨申请记录；调拨单记录；调拨子单记录；调拨打款记录；调拨审批记录等，如表9-3、9-4所示

（4）调拨出款

生成调拨子单以后，调用打款中心的调拨通道发起资金划拨申请；基于通道返回的结果变更调拨单的打款状态；并且将最后的调拨结果告知业务方，以便业务方进行下面的业务流程

（5）调拨异常的处理

一般的异常就是调拨没有收到通道侧的最终反馈；这个就需要人工干预去查看资金有没有调拨完成；另一个就是调拨失败；这时候就需要一个失败重新出款的操作流

4

资金线下汇入系统

现在基本都是线上化收款和打款；但是依然存在着一些线下支付但是需要线上记录的场景；因为虽然资金在线下交付但是业务要在线上进行；比如线下支付现金，线上充值到账户用于日后的线上消费等；那么这种情况下，线下的资金业务怎么跟线上打通呢？今天就介绍一个方法，希望能打开你的思路，想出更多好的办法；对不同系统的设计方法观摩，可以磨练出自己的产品设计感，这一点很快就能体会到

4.1什么是线下汇入

线上支付我想大家都不陌生；你在支付宝余额进行线上充值；针对线上支付，在线下完成资金转账的动作就是线下汇入，但是线下汇入不一定是交付的现金，线下汇入的一个重要标志是没有通过平台的线上支付通道交付资金；也就是你就算是用支付宝转账打款到了指定账户，也算是线上转账；但是对方的业务系统并不知道，你转了一笔钱；这种场景统称为线下资金汇入场景；平台泛指提供服务的平台，比如平台、京东等，如图26所示

图26 存在线下汇入的业务模型

4.2线下汇入的场景

线下汇入场景可能在大额的时候比较多，比如一次性充入50万；对公的场景比较多；这里就不过多举例，大家可以结合自己的经历脑补一下

4.3线上的记账需求

如果说线下的资金业务会影响到线上，那么线下的资金行为记录到线上就是必须要做的事情了；怎么实现呢？其实方法有很多，比如线下沟通，由人工确认收款成功；然后人工在线上后台进行补账录入；还有一种是客户线下汇款成功后，在客户后台按要求提交线下汇入单据；单据到了平台后可以由人工进行审核确认到账，也可以通过系统自动完成核对校验，确认到账，然后完成入账或者业务的推动，如图27所示

图27 线下付款到线上的流程

4.4线下汇入系统概述

线下汇入系统就是管理用户线下汇入的单据，并通过人工或者系统手动确认线下收款的系统；该系统确认后的单据可以作为实际收款的凭证来进行记账，以及推动业务的后续进行，如图28所示

图28 线下汇入系统工作原理

4.5线下汇入系统架构

线下汇入主要要有以下几个模块

汇入单据管理：记录线下汇入的所有单据

操作台：可以人工录入单据，也可以人工复核单据确认收款

自动对账模块：定时查询对应银行账户的账务流水，完成与汇入单据的自动核对

基础管理：管理用于线下收款的账户，接入的查询通道，用户权限管理

结果输出：线下汇入系统对外的收款成功通知；通知账务入账，订单支付成功等，如图29所示

图29 线下汇入系统架构

4.6线下汇入业务流程图

这里只画了核心流程，至于其他的一些逻辑大家可以按实际需要补充；比如一定时间内核对不上的报警，人工的撤销核对成功等等，如图30所示

图30 线下汇入系统业务流程

4.7商户端的支付提交

商户端增加线下汇入信息的提交，或者采用单独的H5页面提供给客户提交线下汇入单据；或者制定线下汇入资金数据的人工沟通机制以及人工在线下汇入系统的补入；要提交的信息主要有这样几个方面；付款人信息，付款账户信息，汇入账户的账户信息，汇入的账务银行返回流水号，银行回执单，如图31所示

图31 汇入信息提交页面

4.8线下汇入系统支付单管理

客户提交上来的单据或者人工后台录入的线下汇入单据管理，具体字段可以依据实际情况确定，这里做一个简单的列表单据管理；查询筛选条件大家自己设定即可，这里就不过多绘制了如图32所示

图32 支付单管理

4.9指定收款账户

一般公司的业务允许线下汇入的情况下，可以指定专用的线下汇入专户用户接受线下汇入资金；这样的会便于线下汇入资金的管理和核对；该账户可以维护到线下汇入系统，客户在提交汇入信息时可以选择钱汇入到了那个账户里；再做线下汇入自动核对的时候可以按照账户的维度进行分组核对，以提高核对准确路，如图33所示

图33 指定收款账户

4.10流水查询接入

针对收款账户，需要接入账务流水的查询；如果是银行对公户的话，可以接入银企直联；设定固定的查询时间进行自动查询，比如每5分钟查询一次；这个查询频次要看银行的要求；一般情况下不允许查询太频发；查询到流水后存储到线下汇入系统的银行账单数据中，用于后续的对账

4.11对账机制 

对账模块这个大家可以看一下对账系统的设计；这里的对账会比较简单，不需要做配置化，将核对逻辑和核对频次写死即可；优先按照银行流水号进行核对，核对上以后即认为没有问题；当汇入单据没有提交银行流水号时，采用多字段匹配；完全匹配上认为核对成功；比如付款人姓名和卡号，金额，收款人姓名和卡号；这个大家可以酌情制定策略；要关注的核心就是确保核对的准确性

4.12人工审核机制

如果单量比较少的情况下；没有做系统自动核对可以采用人工复核的形式来核对汇入单据和银行的实际收款的核对

4.13对账成功后的业务触发

数据核对成功后，基于实际需要，要去触发后续的业务；比如计入账务核心完成入账；通知业务订单支付成功等

--推荐阅读--