基金代销系统
1.1 背景
目前我国公募基金销售行业如雨后春笋一般，不仅传统的银行券商和独立代销机构在激烈厮杀，很多P2P平台、综合理财平台也在以各种方式切入这个行业，价格战越来越激烈，但产品设计上也越来越创新，整个行业还是非常生机勃勃的。
当前基金销售机构在建设基金代销系统上无非两种方式：自建，或购买恒生金证等公司的系统加以改造。
下面我从三个方面介绍下一个基金代销系统：
(1)账户体系
(2)基金交易
(3)基金支付
1.2 账户体系
我以XX基金的账户体系为例，不一定和市面上完全相同，但大同小异。
我们的账户体系分用户账户、基金交易账户、分销交易账户、资金账户、子交易账户、基金账户。
- 用户账户 : 一个手机号对应一个用户账户，用户使用手机号注册并验证通过，设置登录密码后开通。
- 基金交易账户: 一个自然人或机构开通一个基金交易账户，自然人通过身份证、护照等证件实名认证，机构客户通过营业执照等证件，认证通过后开通基金交易账户。基金交易账户编号前3位通常是一个基金销售机构的唯一编码。
- 分销交易账户:因为有外部合作业务，XX基金和百度、理财通、凤凰都有基金销售合作业务，一个用户可能在多个分销机构开通了基金交易，所以用户在每个分销机构对应有一个分销交易账户。基金交易账户 1:N 分销交易账户。XX本身是一个分销机构存在。
- 资金账户： 用户每绑定一张银行卡，鉴权通过后生成一个资金账户。无论这个银行卡是在XX绑定，还是在分销机构绑定，这个资金账号是唯一的。验卡鉴权现在基本是通过快捷鉴权，四要素验证。以前还是有B2C、小额打款等等、CP验密，等等现在都不用了。
- 子交易账户： 一个资金账户和一个分销交易账户，生成一个子交易账户。子交易账户用途是做基金份额登记。
- 基金账户：一家TA对应一个基金账户。所以基金交易账户和基金账户是一对多关系。用户在XX开通基金交易账户，买了5家基金公司基金，就开了5个基金账户。基金账户是基金公司开通的，我们会在用户首次购买该基金公司产品时，一起将开户和认申购交易上报给基金公司。同一个人，在天天基金、XX基金购买了同一支基金，他的基金账号是一样的。
TA就是Transfer Agent的简称，也就是注册登记代理机构的意思，每家基金公司都有这么一个系统，用来给用户注册登记基金份额用的。
1.3 基金交易
1. 常规交易
基金交易通常分两种，一种是用户发起的交易，一种是TA发起的交易。
- 用户发起的交易:常见的包括基金账户开户、认购、申购、赎回、快速过户转换、转托管、修改分红方式等。
- TA 发起的交易: 常见的主要是分红发放，强制赎回、调整调减、清盘等。
这些基金业务名称大都一目了然，而且大家应该也都做过些基金投资，我就不一一介绍了。
在代销业务模式下，销售机构和基金公司之间是以文件形式传递交易数据的。常见的文件有：
- 开户申请 01 文件、交易申请 03 文件(包括所有用户发起的交易)
- 开户确认 02 文件，交易确认 04 文件(包括所有用户发起、TA 发起的交易)
- 份额对账 05 文件
- 分红下发 06 文件
- 基金行情 07 文件
举个例子, 用户购买A基金公司的基金，销售基金会在日终清算后生成给A基金公司的03文件，这里面包含了申请该基金的交易数据，如果是首次购买还会生成01文件，包含开基金账户申请数据。这些文件会放到中央数据交互平台，当日A基金公司下载文件并处理。T+1日会将申购交易确认处理后的数据放在04文件里，并放回到数据交换平台。销售机构下载确认文件，并且做确认清算处理。清算后该给用户加份额就加份额，给基金公司结算申购款就结算申购款。如果有申购确认失败，或者部分成功的情况，还需要给用户发起退款。
2. 申购交易
销售机构按金额申请，TA 以份额确认。
T 日申请，T+1日确认，QDII 基金一般T+2
T+1 日，支付机构将申购款结算到销售机构指定的监管银行归集账户。
确认日第二天，也就是通常T+2日，销售机构向监管银行发起划款指令，将申购款打到基金公司的注册登记账户。
最后由中登将钱打到基金公司的银行托管总账户上。
3. 赎回交易
按份额申请，以金额确认。
T日申请，T+1日确认(QDII通常T+2)。
4. 赎回资金
赎回款由基金公司托管银行账户打到注册登记账户。
然后由中登打到销售机构的监管银行归集账户上。
最后由销售机构发出赎回款划出指令，打到客户银行卡上。
赎回款到账日视基金类型不同而不同。货币基金一般是确认日当天，股票型基金通常确认日后2-3天，QD要5个工作日以上。
另外，监管银行会通过04、06文件核对每一笔给客户的赎回款、分红款。
1.4 基金支付
这块其实大家都很熟悉了，我们一般接入的支付渠道就是第三方支付、银行直连。估计接了十多家吧。
和一般的电商不同的是，基金交易支付通常是协议代扣，而不是快捷支付。用户在绑卡时会签署代扣协议，不过有些渠道是信任代扣的，什么意思呢，就是用户这张卡在A渠道做了鉴权通过后，B渠道是信任的鉴权结果的，无需再做一次鉴权。
因为业务需求，我们在扣款上也做了一些相应的创新，比如多笔交易合并支付，用户购买一个基金组合产品，5个基金原本是5笔代扣交易，合并成一笔去代扣。这在电商系统里很常见，但是在基金交易系统里原本是没有这种设计的。
另外还有多渠道组合支付，比如私募基金交易，单笔支付额度巨大，100万起，我们有点银行额度是达不到的。只能采用多渠道组合的方式去代扣。
支付对账方面，我们做了外部对账、内部对账：
- 外部对账，显而易见是支付系统和支付机构对账，一般是15点收市之后下载对账文件，对账交易包含是T-1日15点以后到当前T日15点的
- 内部对账，是支付系统和交易系统之间的对账，涉及到一些订单状态更新、差错处理、撤单等等。
最后说下资金结算。申购款一般是T+1 12:00之前结算到销售机构归集账户，这是有明文规定的，可以参考《证券投资基金销售结算资金管理暂行规定》。但是赎回款、现金分红款、认申购失败的退款，一般我们不走支付机构，而是由监管银行代发。因为免费。
好，以上是银行卡支付的一些介绍。
目前业内比较流行的做法是和余额宝一样，用货币基金包装成钱包产品，来取代银行卡支付，将用户的资金留存在平台的生态体系里，同时降低了支付成本。比如用余额宝买股基、赎回基金到余额宝，实现货基T+0取现，等等。这块就涉及基金直销业务模式了，一般是直接连基金的直销系统，后续有机会再和大家分享。
二、Q&A
Q：只能采用多渠道组合的方式去代扣，这个怎么理解?一笔100万，系统拆成20笔五万，发到不同的支付机构或银行扣款成功?
A：是的，拆成不同的支付渠道去扣款。
Q：扣一半怎么办?(但是有几笔成功，有几笔不成功，怎么处理/部分成功怎么办?时效性怎么控制?/还有银行的终态返回不一致，怎么把控?)
A：恩，这块的确有这样的问题。所以我们是先把钱扣到一个类似余额宝的CXG账户里，如果钱都扣到了CXG，再拿CXG余额去买私募基金。如果钱扣一半失败了，交易就不会发起。
Q：那会产生另一个问题，支付状态的最终成功或失败，可能相对时间较长
A：所以交易确认和资金流相对较长。当前这种多渠道扣款只是针对私募基金的线上交易，100万起的，所以小的体验上欠缺一点是可以忍受的。
Q：不发起交易，然后会退款吗?
A：不会退款，钱会存在CXG账户里，用户可以发起赎回。
Q：QD是什么意思?
A：QDII 基金，投资海外市场的基金。
Q：资金账号唯一，这个资金账号是鉴权银行卡的时候银行给的么?
A：资金账号是销售机构生成的。
Q：那你怎么保证在其他分销机构帮绑定这个卡生成的资金账号也是相同的了?
A：问题很好，是这样的，一般分销机构是不能绑卡的，他们只能把银行卡信息传给我们去绑卡。个别像理财通这种，比较强势的会特殊处理。分销机构一般只是个流量引入平台，他们没有基金销售牌照，基金交易和支付还是我们来做的。
Q：私募基金按照你的说法，从CXG里支付，是否意味必须先充值，而用户是不能直接银行卡支付的?
A：只有通道额度不够的时候才会，银行卡扣到CXG，再用CXG买私募基金。如果通道额度足够是不限制的。
Q：用户在绑卡时会签署代扣协议，不过有些渠道是信任代扣的，什么意思呢，就是用户这张卡在A渠道做了鉴权通过后，B渠道是信任的鉴权结果的，无需在做一次鉴权。 问:走B渠道还需要再发短信么?
A：我们走的代扣通道都是不需要短信验证的，那是快捷支付才需要。如果走信任代扣通道，出了盗卡问题，是要销售机构承担责任的。
Q：这个中央交换平台是谁建立的呢?是不是所有的基金公司TA都要连
A：这个是中登的统一交换平台，都是要连的。说白了差不多就是个文件服务器
Q：银行直连现在都有信任代扣接口的吗?还是你们接的是第三方支付?
A：银行没有
Q：是对接的哪家第三方支付?
A：具体哪家不便说了，抱歉。
Q：做代销有资金账户，需要有支付牌照吗?
A：这个资金账户原来内部记账用的，跟支付牌照没关系。
Q：分销交易账号跟子交易账号是不是交易账号的概念，区分开有什么好处?是不是二者就是基金交易账号的概念吧，交易账号关联银行卡(资金账号)，银行卡又对应多个资金渠道?
A：业内有些公司是银行卡和资金渠道关联形成一个交易账号，也就是多交易账号机制。但我们这个不是，分销交易账号是在分销机构注册开户才会有的，如果没有分销交易账户，那用户在多个分销同时做了交易就无法区分开了。
Q：那子交易账号和分销交易账号关系是什么?这块我不是太理解
A：子交易账号是银行卡的资金账号和分销交易账号共同生成的，可以这么理解，我有一张工行卡，我在XX绑了，也在腾讯绑了，因此会有两个子交易账号，用来登记这张卡的基金份额。
Q：刚才说的扣款场景，其实有充值余额、资金池的概念了，这个没事吗?
A：这个没关系，因为我们是扣款买了货币基金。
Q：多个渠道扣款失败的话，不是会留存余额吗?
A：部分成功的话会，但是钱是买了货币基金，所以没关系。
Q：买100万基金，渠道20万限额，5次扣款，成功60万，实际留存余额60万，这60万不会买基金吧?只会等用户提出或者再充值购买吧?
A：会买基金的，CXG的底层货币基金是实时确认的。
Q：我这里问一下，如果发生刚刚您说的部分成功的情况，是买了货币基金的话，那申请提现就是提现到货币基金对应的银行卡，这个操作是一次还是跟之前购买的一样是组合
A：这个就是普通基金赎回流程。没有金额限制。是一次的，而且赎回资金不走支付渠道代发。
Q：那就是你们买的时候做了一次包装，赎回就按照正常来?
A：待回应
Q：中登的平台，在交易链条中的核心功能是啥?
A：数据交换的作用，另外他们做为监管层，会对数据做备份汇总及监管。
Q：交换啥数据? 和支付结算相关? 这个没大看懂，可能还需要消化下。
A：基金公司和销售机构之间的基金交易数据交换。
Q：子交易账号与卡强关联的目的是什么?同卡进出?
A：是的
Q：腾讯和XX是两家并行的基金代销机构吗?
A：不是，腾讯理财通接了XX的基金交易，他是XX代销下的一家分销，同时XX分销也是XX代销下的一个分销。打个比喻就像是直营和加盟一样。所以是两家并行的分销。
Q：ta的交易账号跟子交易账号是一对一的关系吧?
A：TA的交易账号就是我前面说的基金账户，这个跟子交易账号没有对应关系，只和代销层面的基金交易账号关联。并且不是1：1关系。一个人可以买n个基金公司产品，所以是N：1关系。
Q：ta有交易账号和基金账号两个概念吧。客户在不同代销是同一个基金账号不同的交易账号吧?基金账号应该是标识客户的吧。可能理解概念不一样，我说的ta交易账号应该是你说的代销层面基金账号;不同代销机构是同一个基金账号不同交易账号，用于区分份额
A：你说的很对，行家。
Q：你们T+0业务是否有跟其他理财产品购买打通?这里涉及资金效率的问题
A：这里涉及资金效率的问题保险、资管产品、公募基金都有打通
Q：像保险、资管类的产品，你们一般非交易过户是过户到谁名下?垫资方是基金公司还是自己?
A：自己垫资。基金公司垫资一般都是直接打到客户银行卡。
Q：是的，基金公司要保证自己在闭环内
A：各行业也不一样，跟券商合作一般都是把钱打给券商，哈哈。
Q：特别问一下，这个余额宝25万上线对你们这个做法有没有什么影响?
A：这个没有影响，25万是余额宝自己的限制。
Q：用CXG的余额去买基金，是先把份额转给代销平台，然后代销平台替用户把钱结算到归集账户，是这样吗?
A：CXG买基金不需要份额转给代销平台，只要发起普通赎回即可，赎回成功就帮客户发起基金申购申请。在资金流上赎回货币基金的钱t+1到归集账户，不结算给客户。同时他+1申购交易确认成功，t+2再把赎回的钱结算给申购基金的基金公司。
Q：那是不是有可能购买基金和赎回之间时间差可能只有几秒钟?
A：赎回货基是调用基金公司直销系统接口，除非网络阻塞否则不会那么久。
Q：可能我没描述清楚;前面说大额交易资金会先进CXG，购买货币基金。如果一个用户想买私募基金的话，比如先进行CXG充值，这笔钱会先买货币基金，当100万到了后，马上去买私募，那么CXG里要立即进行赎回，那这个周期就会很短，可能一分钟内就完;这个实际情况会这样吗?或者货币基金的业务规则允许这样操作?
A：不会出现您说的这种情况，肯定是确认后才赎回的。
Q：那就会出现一分钟前买了上百万基金，一分钟后就赎回了
A：不会，在购买私募的时候会生成一笔赎回申请，但是不会立刻发给基金公司，而是T+1份额过户了才发起赎回的。
Q：那你们要垫资很多很多啊
A：一般不需要垫资的，因为私募是有冷静期的。
Q：CXG的赎回资金如何能进入托管银行，正常银行是要核对第三方支付的申购流水，防止洗钱或者非法赠送
A：这个没看明白。赎回我们一般不走第三方支付机构代发。
Q：就是代销机构把资金打入托管行，托管行也认可是吧?CXG在基金销售平台外围，不在体系内?
A：no，CXG的赎回资金也是进入代销机构的监管银行归集账户的。
Q：明白了，此CXG也是包装的货币基金，抱歉，前面没认真看
(网友发散追问)
Q：哥们可以补充一下，说一下基金账户购买非标类产品的设计流程?
A：就是底层实际上会进行债权匹配，比如3C的消费金融，放款给借款人，或者合作平台统一结算
Q：购买非标产品是不是不需要垫资?资金都是t+1资金交收吧?
A1：如果提交了申购文件，效率就会很低了;而且过户给平台，一般对公T+0基金公司都不给玩，除非跟楼主公司一样，自己先垫资;问题是合作平台或者借款人也讲资金效率，正常最迟T+1就要收款
A2：这个不一定吧，双方约定交割时间不就成了么
三. 自由讨论
3.1 信用卡逾期利息
Q：问个问题，信用卡消费以后，没有逾期发生的时候，系统会不会计算每天的利息，还是在逾期以后，才一次性计算之前的利息?
A1：系统应该是每天计提利息。到了结息周期付息收息;贷款和存款每天都会计提利息。计算每天应付应收利息。
A2：会按天累“积数”，例如第一天消费100，第二天消费200，当前积数就是400了。按天累，100累两天就是200啊
A3：百度下循环利息就好了
3.2 求信用卡各领域分享
Q：信用卡这块有没有人组织分享一下 哪方面的都行 这块好像到现在为止没看到群里面讨论过
A：待回应
3.3 同城双活ZK跨机房
Q：问个ZK的问题，我们现在有两个同城双活机房，ZK的数量比较麻烦，ZK的选举是要求奇数的，怕一个机房出现断电故障，3+2，3+3可能都不太好。集群半数宕机无法选举leader 要半数以上拥护;同城双活，两地三中心，之前各种坑爹，光纤被挖，机房断电;我们机房是光纤直通的，可以类似内网看待，ZK会用来做一些配置集群，包括DUBBO;主要是DUBBO要用，然后开发了一些组件，dubbo是应用层的组件， 基于dubbo实现的服务，要访问数据库，也是跨机房
A1：一般机房之间是光纤直通，但毕竟是跨机房的，延迟和稳定性和同机房的不能比。 zk尽量避免跨机房。 我们只用MQ和LoadBalance来跨机房。
Q: 问一下，mysql 同步数据到elasticsearch， 你们使用哪个中间件的?
A1：我们同步一般都用mq，数据写入方发mq，接受方收到消息后更新数据;不是自动同步， 是业务层通过mq异步同步，这样的话，可以数据加工后保存，比较灵活。不需要全量同步
A2: 我们用Eureka，没有选举问题;zk一般只做服务治理，服务注册和发现，我们的集中配罝用的是cloud config 和cloud bus;;Spring Cloud加上cloud bus 能做到在线更新配置后自动同步到所有应用
Q2： cloudconfigure和cloudbus有什么区别?
A2： config只是一个集中配置中心，是静态的，Bus是个消息总线，将config的变动及时通给到各个配置消费者
Q2： bus除了分发配置，还能做消息事件通知吗?背后的mq中间件有什么要求?是否能高可用
A2： MQ可以是集群啊，BUS就是一个普通的MQ;其实spring cloud的东西挺全的，sleuth可以解决服务调用跟踪，Hystrix可以实现服务容错，包括熔断、线程隔离、服务降级、请求缓存、请求合并等。
Hystrix 的官方配图
A3：zk只要在主机房配置为leader和follower,在其他机房配置为观察者模式就能解决跨机房问题，包括性能和选举问题
A4：我们现在用的是disconf，搭建起来相对麻烦，但是用起来还蛮好的
3.4 提现T+1到账的账务处理
Q：请教一个问题，我们现在有一个业务场景，客户T日提现，T+1才到账。这种账务上应该怎么处理呢?目前有两种方案：(1)T日冻结，T+1日做解冻+扣款;(2)T日扣客户的账，挂一个应付科目，T+1统一从挂账科目出金。 一般采用哪种方案呢?如果是方案2的话，T+1日出金的时候，是从挂账科目出，性能和资金安全方面，感觉少了一些保障呢;另外，如果出现付款失败和退票，也都是先退到过渡户，再退回到客户账户吗?
A1：第二种
A2：通常会有个待结算账户，对客户可见，T+1日做一笔转账至余额账户，也就是每个客户再另外开一个待结算账户
A3：这两方案本质上没啥区别，一个是分开记，一个是合计记，方案2比较明确，退款是由交易发起的，直接由过渡账转回;商户比较特殊，有自己的分户账，就简单多了;如果是用户的话就没有必要了，商户一般不存在打款失败的情况，只有在成功的情况下进行核销
Q3: 用户如果经过实名认证，应该也不会出现打款失败的情况嘛?
A3: 会的，比如打款通道的问题;我以前遇到过招行天津分行全都失败的问题，其它的都成功了
Q3: 如果是打款通道的问题导致的付款失败，退回到客户账户上，也不合适吧?
A3: 这个要看你们的处理流程了，也可以补打啊
Q3: 我们现在基本上是区分两种，如果是非客户账户的原因导致的失败，都是补打款的，如果是客户的账号有问题导致的失败，就是退回客户的账上，等客户再发起提现。
A3: 这个流程没有问题啊，账号有问题补打也没有意义 ;但是退款环节最好加上审核机制
A4：开户的时候 会给商户开4个账户
A5：比较支持第2种方式，这里面还有运营方面的需求，查询任意时刻待提现的总资金
Q5: 即挂账科目有可能需要实时统计余额吗?
A5: 是的
Q5: 这里比较麻烦的就是，挂账科目，在我们这里属于内部账户，不会实时统计余额。请问你们的系统是怎么处理的呢?
A5: 内部账就不能实时了?没有这个规定
Q: 内部账户，一般并发量比较高，如果实时更新余额，不会有性能问题吗?我们一般是间隔一段时间统计一次，内部账户，一般访问频率会比较高吧?
A:上次中金的朋友讲过了， 我觉得讲的挺好的，与业务相关的可以放在账务去做，而不用关心内外之分
Q: 出账的不更新账户余额危险很大吧?
A1: 即使你现在内部账户放在了会计系统也没有问题，实时或批量都没问题，没有人规定会计系统不能有实时接口。但像打款这样的账户，应该是相对稳定的，不应该是实时更新的
A2: 肯定能实时出余额是最好的，但比较想知道像内部账户这种并发量这么大的账户，怎么做到实时出余额。刚才的截图是从一个支付宝比较老的文档中看到的，不知道还有没有其他做法。
Q: 实时余额会有问题，余额总在滚动，你如何操作?
A1: 看有没有哪个大牛，专门说一下这块吧 这个类似的问题好像群里说了好几次了 我每次看好像都不太一样，不知道有没有统一的一个标准
A2: 所谓缓冲记账，就是批量上账
A3: 之前提出好多个无差异的账户作为平台账户，我觉得是个不错的主意哈，对热点账户效果应该明显
A4: 场景不一样，方案上稍有差别，实时记账没有问题，问题是这样做是不是适合作业需求。热点账户不打款，这就是差别。
Q: 但是这里的场景不就是要打款么?
A1: 对啊，所以不能用常规的那种热点方式，热点账户的解决方案一般是内存缓存，定时更新到库中;对于内部账户的上账，批量上就可以;我的建议是先把打款作业需求梳理清，打款的依据是打款明细，而不是账户
A2: 关于热点账户的入账问题，我的理解是两种解决方式，一是汇总入账，还有就是刚才大家所说的缓冲记账;两种方式各有优劣，而且在实际业务运营中，后者除在并发波峰外，基本可以做到实时或准实时
A3: 出款、入账区别对待，为确保资金安全，一般是确保账户余额减成功后才发起出款，这里的余额修改通常做实时;入账如楼上所说，汇总or缓冲
A4: 银行采用的都是批量，热点账户一般用在某段时间内对该账户进行频繁的同时上账和下账，因为你不及时上账，下账就会出现余额不足
3.5 银行与三方支付签约是否要求排他
Q：负责聚合支付业务的产品或业务童鞋，请教一下，现在银行与支付宝、微信支付，签订服务商或代理商协议有排他性约束吗?或者说银行作为二清类服务商，能同时与支付宝、微信支付签订合作协议吗?听到有人说，现在他俩要求服务商排他，只能找一家站队;但实际情况是比较多的银行同时和多家第三方合作，推出聚合支付服务，所以想确认下~
A1：没有
A2：可以
A3：没有，我们有很多银行客户都申请了微信和支付宝的银行机构服务商
Q3: 除了民生、中信外，具体还有哪些银行呢?
A3: 好多城商行都在干聚合支付了：兴业。浦发，以及等等
A4：第三方接第三方，需要通过银行整个挡板账户。
Q4: 什么叫第三方接第三方啊? 不是有第三方做第三方的签约商户么;易宝好像就代理了微信吧，可以用易宝走微信支付?
A41：通过银行间连;现在其他第三方通过银行间连，提供支付宝、微信支付收单服务的，资金流是消费者账户先流向支付宝备付金账户，支付宝清算至银行内部账户后，银行二清给商户，中间不能再经过其他第三方的账户了;巨头是这样要求的;也就是说，此时的第三方的角色定位，就是聚合支付服务商，收单外包机构，和Ping++、收钱吧等角色一样
A42：所有支付公司做微信支付的，中间都有个第三方
A5：第三方不允许接第三方
Q5：一直有个问题请教一下，关于三方不允许直接连三方，是在哪个文里规定的?
A5：2号令
Q5： 2号令我看过，没有解读到具体的条款
A5：第一章第四条
Q5：针对这条我一直有个疑惑，假设易宝代理微信做收单，日终清算时，微信直接将财付通银行备付金账户的资金划转到易宝的银行备付金账户，应该没有违反第四条规定吧?
A51：首先财付通是啥?其次，如果财付通是支付机构且易宝也是支付机构，那么就违反第四条了;楼上A4的同学对于第三方的解释有误，这里的第三方必须拥有清算资质，收钱吧之类没这个
A52：四方不能落账户，三方才可以
A53：五方模式没意义，支付链条太长;五方真的没有意义，备付金集中存管后，其他第三方再沉淀资金的动力不足了
Q6：接上面，如下图，易宝代理微信收单，资金清算时，微信直接将其银行备付金账户的资金划转到易宝的银行备付金账户，再由易宝清算给最终商户，重点就是中间微信将资金直接划转到易宝备付金户这个操作，是否违反2号文?
A61： 易宝微信中间加一个银行，中间加一个银行，就需要银行开内部户过一道资金
A62： 你为啥老要跟备付金扯在一起
A63： 都说了，所有使用微信的支付机构都需要有个第三方，谁告诉你直接划的;银行是清结算机构，开毛个内部户;银行的角色就是微信的代理商，只不过有清算能力;说的更直白些，银行是微信大商户，易宝是银行的大商户，你是易宝的大商户
A64： 目前一般是这样的，微信不能直接跟支付机构对接的。微信跟支付机构只能通过银行或者结算中心进行转接。不管是交易还是资金流，都是这样的
A65： 违反
Q7： 支付公司现在的资金账户就是在银行开的备付金账户，支付公司之间要做资金清算，最终结果就是两个支付公司之间备付金的资金流动，我现在的问题是，在银行账户层面这个资金通过哪些手段流动过去
A71：个人感觉其实银行本质上不是一个支付机构间的清算角色，更像是微信委托银行做一个代付给易宝
A72：理解下，你是指支付机构间的备付金资金转移，好像没有违反二号令;资金还是通过银行进行转接清算，而不是支付机构见互相开立账户直接结算，这一块的理解各异，而且现状是大家都往另一方面理解，so 不用纠结了
A73：其实第三支付机构是不能“银行化”的。只做好自己的结算业务即可。
Q8：如果聚合提供商平台接了商户，资金过第三方支付后，用银行内部账户清分给商户，有问题吗?
A8：没有，刚才有童鞋说的很直白，银行是微信的大商户，这个大商户有支付和清算资质，再清算给它下面的小商户，以前微信把这种服务商，叫做二清类服务商
Q9：这时候银行的账户体系要建的很全面才行，不然支持不了商户需求吧?
A9：这个要看合同吧，如果第三方只与银行签，那第三方就是银行的商户，钱由银行结算给第三方，没有微信什么事
Q10：如果第三方与微信签的合同，那么银行就只是个代理，资金理应由微信结，不过目前来看，大部分都是第一种模式。
A10：如果是银行模式的，就是微信结算给银行，银行结算给大商户;如果是直联模式和微信签合同的，就是微信直接结算给商户
A101：如果是普通服务商模式接入的子商户 子商户也是和微信签合同，资料是服务商录入，微信是直接结算给子商户;而有支付牌照的公司，是不能直接合作的，所以都是通过银行模式
Q11：银行模式，银行根据什么信息把资金结算给商户呢?
A11: 银行模式下，交易要走银行系统
Q12：请教下，目前贵司对服务商有排他性(排支付宝)的约束吗
A12：没有排他性，根据交易对账单结算;微信有商户平台和对账，银行也有自己的商户平台和对账
3.6 代付与二清
Q1：支付机构可以为商户提供代付服务吗?
A1：可以
Q2：商户交易的资金，按道理应该进到商户的结算账户，如果商户要求，这部分资金，不清算给他，而是根据他发的代付指令，代付到其他多个银行账号，这是允许的吗(算不算变相的二清)?
A21：代付资金和清算资金要分开的
A22：你这说的模式，就是代收代付啊，代收代付，绕不开涉嫌二清的嫌疑
A23：有些支付机构的支付产品，支持交易实时分润，但一般代收付平台喜欢留存资金，不知道算还是不算，这个问题，曾经被困扰了很久，因为官方没有界定清楚，而且行业内理解也有颇多差异;前段时间，央行对于小额支付系统的集中代收付业务，有点一竿子打死的意味，代收确实需要整治下，但代付业务是池鱼之祸
A24：你这个问题得分情况看：如果是商户自有资金，只做代发的话肯定是没问题的;如果是收单资金，直接资金不过商户账户，直接由银行或者三方请给最终小商户，在资金层面也没有问题，不过也可能存在清算信息层面有擦边球嫌疑
Q3：是不是这样理解?商户不能拿自己的备付金，作代付。但可以另外打款给支付机构，作代付?
A3：不是你说的这个意思，我理解你说的应该是二级商户收单清算的场景，你这个场景肯定需要避免二清，底线是资金不过你的账户，目前我们有一种模式，银行开一个内部账户，支付公司把资金清算到这个内部账户中，然后银行根据你的指令将资金直接清算给最终小商户
Q4：是不是有点类似二类账户的用法?我之前看过二类账户的一些用法，看到可以应用在代付业务上。估计就是你说的这种模式。为大商户开一个二类账户，资金清算到二类账户，再发代付指令给银行，由银行从这个账户中做代付出去?
A41：你就认为是银行账户就行
A42：自有资金，代付业务不需要啥牌照资质，只要符合代付业务准入即可
Q5：一般支付机构发代付指令，都是需要从备付金账户出金的吧?商户的自有资金，进入到支付机构的备付金账户上，没有问题吗?之前看到快钱是有为商户提供付款功能的，但不知道具体的业务模式是怎么样的。
A51：感觉没那么复杂吧，商户自己的钱自己爱怎么弄就怎么弄，二清也不是这么防的吧?第三方把钱结算到商户账户上，商户再充值到第三方平台，再代发，你怎么界定他就是二清?
A52：不同的代付通道，是有区别的：有的是需要预充到支付机构的备付金账户再出金;有的直接可以从企业的对公户中划扣资金
A53：我对二清的理解是接入风险，不是业务风险;商户的结算款，只要有协议，可以转到余额账户，余额账户当然可以代发了;不论是结算款转余额代发，还是自有资金充值代发，对于第三方公司来说都是一样的，都属于负债类的，对于客户的负债清偿，肯定是走备付金。
A54：这个结算资金，不一定全部是该商户的;商户做了代收代付业务，这里就有涉嫌二清的嫌疑
Q6：总结起来，按我刚才说的业务场景：如果是商户的结算款，要做代付：一种就是跟银行合作，先清算到商户的结算账号，再从商户的结算账号上做代付。一种就是跟商户签个协议，打打擦边球。如果商户只是单纯的代付业务，商户肯定是要通过不同的方式，将资金划转到支付机构的备付金账号上，再通过支付机发代付指令。
A61：合同上写的是商户的，结算资金就是商户的;是不是二清，关键是看商户是否开展了二清类的业务，不是看他的代发;不用划转，结算款本身就在备付金账户上，只不过账务上要求，这个是进账
A62：感觉普通商户的结算款，基本没有什么代付的需求吧。
A63：做代收代付类服务的，一般是平台型商户，自身不是商品或服务的提供方，作为流量入口撮合交易;这个人行一查，还是挺明显的，也不容易解释过去。没有这样的业务场景
A64：不出现资金跑路风险，不做大资金池，不冲击维稳刚需，监管也是有成本的，类似业务事实上大量存在
A65：纯代付就是你说的这种模式，商户直接把资金打到支付公司，然后给支付公司发代付指令，这是标准代付流程，没什么问题
A66：对商户而言;银行也有代付服务，不一定要走支付机构，支付机构的代付通道，溯源也是银行开放的;而且部分银行的代付，不需要商户的对公户一定是该行，跨行扣款也可行
A67：这需要银行有代扣通道
3.7 聚合扫码支付市场行情
Q：有个话题想跟群里的专家们探讨一下：目前很多银行都在做或者开始要做聚合扫码支付，大部分都会将系统和运营外包，然后也会找些地推服务商，这块目前市场行情怎么样?
A1：关键要确定行方的诉求，长尾市场上的小微商户，支付宝、微信都不直接地推，银行直接撸袖子上，成本优势更差;【XX银行】将在X月底投产统一支付平台，把行内渠道接口标准化，后台先上二代支付和XX省金服通道。平台优点:统一行内接口，统一对账，统一差错处理，支持智慧路由和指定路由。做这个平台主要为了后续快速接入其它支付通道。1. 超级网银X月底同构到统一支付平台里; 2. 银联代付X月版投产;3. 网联X月投产;4. 年底再收CISP(跨境人民币支付系统);5. 明年再做:银联代收，SWIFT，还有各个同城~还在搞银联快捷支付需求~。现在存量业务与新系统多条线并行，每接一个支付通道，都把行内渠道业务系统也接过来。例如: X月底超网同构和V1.X需求投产，会把现在走超级网银的:个人网银，企业网银，现金管理，wap手机银行，微信银行等等十几二十个业务渠道都接过来
Q：我们现在暂时先不打算把网银柜台之类存量业务迁过来，只做增加线上支付收单类业务
A: 是的，行内历史遗留的支付系统分散，维护团队不同，开发平台和开发语言不同，造成运维成本高的问题，要彻底解决
Q：你们是用的外包还是行内自主开发?
A：收旧系统要很大成本~很多行都不敢这么玩。行内+外包。行内主要做:需求分析和方案设计，接口设计，数据库设计，具体到代码和测试那块由外包做。
【本文为51CTO专栏作者“凤凰牌老熊”的原创稿件，转载请通过微信公众号“凤凰牌老熊”联系作者本人】
