专栏名称: 凤凰牌老熊
互联网金融,软件架构,资深Java工程师
目录
相关文章推荐
芋道源码  ·  凌晨四点,线上CPU告警,绩效没了! ·  9 小时前  
芋道源码  ·  年后面试的兄弟们注意了。。。 ·  昨天  
芋道源码  ·  防止超卖的七种实现 ·  2 天前  
芋道源码  ·  DeepSeek+Spring有搞头么? ·  2 天前  
芋道源码  ·  老板爱瞎改权限怎么办:注解+AOP ... ·  3 天前  
51好读  ›  专栏  ›  凤凰牌老熊

20170601-基金代销系统

凤凰牌老熊  · 公众号  · Java  · 2017-06-05 20:21

正文

一、专题分享:基金代销系统

1.1 背景

目前我国公募基金销售行业如雨后春笋一般,不仅传统的银行券商和独立代销机构在激烈厮杀,很多P2P平台、综合理财平台也在以各种方式切入这个行业,价格战越来越激烈,但产品设计上也越来越创新,整个行业还是非常生机勃勃的。

当前基金销售机构在建设基金代销系统上无非两种方式:自建,或购买恒生金证等公司的系统加以改造。

下面我从三个方面介绍下一个基金代销系统:

(1)账户体系

(2)基金交易

(3)基金支付

1.2 账户体系

我以XX基金的账户体系为例,不一定和市面上完全相同,但大同小异。

我们的账户体系分用户账户、基金交易账户、分销交易账户、资金账户、子交易账户、基金账户。

TA就是Transfer Agent的简称,也就是注册登记代理机构的意思,每家基金公司都有这么一个系统,用来给用户注册登记基金份额用的。

1.3 基金交易

1. 常规交易

基金交易通常分两种,一种是用户发起的交易,一种是TA发起的交易。

这些基金业务名称大都一目了然,而且大家应该也都做过些基金投资,我就不一一介绍了。

在代销业务模式下,销售机构和基金公司之间是以文件形式传递交易数据的。常见的文件有:

举个例子, 用户购买A基金公司的基金,销售基金会在日终清算后生成给A基金公司的03文件,这里面包含了申请该基金的交易数据,如果是首次购买还会生成01文件,包含开基金账户申请数据。这些文件会放到中央数据交互平台,当日A基金公司下载文件并处理。T+1日会将申购交易确认处理后的数据放在04文件里,并放回到数据交换平台。销售机构下载确认文件,并且做确认清算处理。清算后该给用户加份额就加份额,给基金公司结算申购款就结算申购款。如果有申购确认失败,或者部分成功的情况,还需要给用户发起退款。

2. 申购交易

3. 赎回交易

4. 赎回资金

赎回款到账日视基金类型不同而不同。货币基金一般是确认日当天,股票型基金通常确认日后2-3天,QD要5个工作日以上。

另外,监管银行会通过04、06文件核对每一笔给客户的赎回款、分红款。

1.4 基金支付

这块其实大家都很熟悉了,我们一般接入的支付渠道就是第三方支付、银行直连。估计接了十多家吧。

和一般的电商不同的是,基金交易支付通常是 协议代扣 ,而不是快捷支付。用户在绑卡时会签署代扣协议,不过有些渠道是信任代扣的,什么意思呢,就是用户这张卡在A渠道做了鉴权通过后,B渠道是信任的鉴权结果的,无需再做一次鉴权。

因为业务需求,我们在扣款上也做了一些相应的创新,比如多笔交易合并支付,用户购买一个基金组合产品,5个基金原本是5笔代扣交易,合并成一笔去代扣。这在电商系统里很常见,但是在基金交易系统里原本是没有这种设计的。

另外还有多渠道组合支付,比如私募基金交易,单笔支付额度巨大,100万起,我们有点银行额度是达不到的。只能采用多渠道组合的方式去代扣。

支付对账方面,我们做了外部对账、内部对账:

最后说下资金结算。申购款一般是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: 银行采用的都是批量,热点账户一般用在某段时间内对该账户进行频繁的同时上账和下账,因为你不及时上账,下账就会出现余额不足







请到「今天看啥」查看全文