专栏名称: 凤凰牌老熊
互联网金融,软件架构,资深Java工程师
目录
相关文章推荐
芋道源码  ·  孤陋寡闻了,原来 MySQL 还能这么写? ·  昨天  
芋道源码  ·  一个复杂的SQL分析 ·  2 天前  
Java编程精选  ·  Stream流式编程,让代码变优雅 ·  5 天前  
51好读  ›  专栏  ›  凤凰牌老熊

20170609-备付金报备

凤凰牌老熊  · 公众号  · Java  · 2017-06-10 17:42

正文

一、 主题分享:备付金报备

今天由我为大家分享“备付金报备”相关知识,我在支付行业混迹8年,目前主要负责清结算、账务平台、备付金管理。

1.1 相关发文

央妈关于备付金监管相关发文:

  1. 支付机构客户备付金存管办法(中国人民银行公告〔2013〕第6号)

  2. 中国人民银行营业管理部关于贯彻落实《支付机构客户备付金存管办法》有关事项的通知(银管发【2013】257号)

  3. 中国人民银行关于建立支付机构客户备付金信息核对校验机制的通知(银发【2013】256号)

  4. 中国人民银行营业管理部转发中国人民银行关于建立支付机构客户备付金信息核对校验机制文件的通知(银管发【2013】345号)

1.2 核对检验要求

央行要求支付机构、备付金银行建立客户备付金信息核对校验机制,按照账账相符、账实相符的原则,于每个工作日对每个交易日客户备付金的存放、使用、划转等信息进行核对,并妥善保存核对记录。备付金银行应在T+2日内与支付机构完成T日客户备付金信息的核对校验工作。客户备付金信息核对校验机制应至少包括:

  1. 双方约定的客户备付金信息查询方式;

  2. 支付机构向备付金银行传输的客户备付金信息内容、传输时间与传输方式;

  3. 备付金合作银行对支付机构存放在本银行的客户备付金信息进行核对校验的方式与标准;

  4. 备付金存管银行对支付机构存放在所有备付金银行的客户备付金信息进行归集以及核对校验的方式与标准。

1.3 监管账户

涉及三类账户。

1. 支付机构的客户资金账户 即支付机构在自身业务系统中为客户开立的、用于记录客户资金收付结算信息的账户,包括但不限于支付账户、待清算资金账户、预付卡交易与余额记录。

2. 备付金银行账户 即支付机构按规定在备付金银行开立的、用于存放客户备付金的各种银行账户,分为备付金专用存款账户(备付金存管账户、备付金收付账户和备付金汇缴账户)和非活期存款账户(包括定期、通知存款等账户)。

3. 管理账户 即备付金银行为支付机构客户建立的、与支付机构的客户资金账户一一对应并同步变动的影子账户。对于业务规模较大的支付机构,备付金银行可根据系统承载能力,在保障核对校验效果的前提下,适当简化管理账户交易信息传递工作,例如,以支付机构报送全量的客户资金账户日终余额信息代替日间实时传递每笔交易信息。

1.4 备付金管理

客户备付金信息核对校验机制按参与主体及核对校验的内容分为两个过程。

(一)支付机构和各备付金银行核对支付机构业务系统中当期出入金业务与备付金银行账户的出入金信息。客户备付金出入金业务是指,使备付金银行账户余额增加或减少的支付业务活动。其中,增加备付金银行账户余额的业务活动称为入金业务,减少备付金银行账户余额的业务活动称为出金业务。本过程的目的是,核对、确认当期支付机构各备付金银行账户发生额、期末余额及未达账项金额。支付机构与其备付金银行能逐日逐笔核对客户备付金出入金业务明细信息的,可申请对其备付金存管银行的客户备付金存放比例、或实缴货币资本与客户备付金的日均余额比例、或风险准备金计提比例适当调整。

(二)支付机构和备付金存管银行法人(或其授权分支机构)核对支付机构业务系统中客户资金账户当期发生额、期末余额与全部备付金银行账户的变动额及余额。本过程的目的是,核对、校验客户备付金的安全性与完整性。 支付机构所在地人民银行分支机构通过支付机构、备付金存管银行法人(或其授权分支机构)、备付金合作银行法人(或其授权分支机构)分别报送的客户备付金信息,加强对各方履责情况的监督、评价。

1.5 主要规则

  1. 支付机构与备付金银行逐一比对客户备付金出入金信息。

  2. 支付机构与备付金银行核对T-N日的未达账项是否在T日前到账。

  3. 备付金银行对支付机构有关备付金存款账户余额及客户资金账户余额进行连续性检查。

  4. 支付机构与备付金存管银行法人(或其授权分支机构)比对客户资金账户变动额与全部备付金银行账户变动额。

  5. 支付机构与备付金存管银行法人(或其授权分支机构)比对客户资金账户日终余额与全部备付金银行账户余额。

  6. 备付金银行对支付机构出金支付指令中有关收款人信息是否已列示在客户信息库中进行核验。

  7. 备付金存管银行法人(或其授权分支机构)比对其为支付机构客户建立的管理账户与支付机构客户资金账户余额。

1.6 报表系统设计

备付金监管的核心是支付机构的备付金总额应与存管行、合作行的备付金总额一致,支付机构和银行都需要建设备付金报表系统。

支付机构需要和银行进行对接、也需要和央行对接,按照要求时间上传报表。

针对支付机构而言,搭建备付金时,需要和生产业务系统数据对接,生产业务数据我们分为五类:

  1. 收款调增客户账户

  2. 退款调减客户账户

  3. 打款调减客户账户

  4. 打款退回调增客户账户

  5. 退款退回调增客户账户

这五类数据对应到会计系统的不同科目,日终处理完成后,按照预定的数据模型进行勾稽关系校验,最终生成报表(这里需要注意还需存管行和合作行对应的出入金数据需要区分)。

针对银行而言,分为存管行和合作行,存管行要求到明细模式,合作行涉及到报表模式,需要与支付机构备付金系统对接,匹配勾稽关系、进行数据校验,然后生成报表。

  • 表1_1支付机构银行客户备付金入金业务明细表.xls

  • 表1_1_2支付机构银行客户备付金入金业务明细表.xls

  • 表1_1_3支付机构银行客户备付金入金业务调节表.xls

  • 表1_2支付机构客户备付金出金业务明细表.xls

  • 表1_2_1支付机构银行客户备付金出金业务明细表.xls

  • 表1_3支付机构客户备付金业务实际出金明细表.xls

  • 表1_4支付机构客户资金账户转账业务统计表.xls

  • 表1_5支付机构客户资金账户余额统计表.xls

  • 表1_6支付机构银行特殊业务明细表.xls

  • 表1_6_2支付机构银行特殊业务明细表.xls

  • 表1_7支付机构现金购卡业务统计表.xls

  • 表1_8支付机构预付卡现金赎回业务统计表.xls

  • 表1_9支付机构银行客户备付金业务未达账项统计表.xls

  • 表1_9_2支付机构银行客户备付金业务未达账项统计表.xls

  • 表1_10支付机构银行客户备付金业务未达账项分析表.xls

  • 表1_10_2支付机构银行客户备付金业务未达账项分析表.xls

  • 表1_11支付机构客户资金账户余额变动调节表.xls

  • 表1_12支付机构客户资金账户余额试算表.xls

  • 表1_13预付卡发行企业备付金账户中售卡押金统计表.xls

  • 表1_14支付机构管理账户情况统计表.xls

  • 表2_1银行支付机构备付金银行账户余额统计表.xls

  • 表2_2支付机构管理账户情况统计表.xls

  • 表2_2_2支付机构管理账户情况统计表.xls

点击这里下载所有模板: 备付金报表模板下载

1.7 重要公式

  • T-1日客户备付金银行账户余额+T日备付金银行账户变动金额=T日备付金银行账户余额;

  • T-1日客户资金账户余额+T日客户资金账户变动金额=T日客户资金账户余额。

  • T日备付金银行账户变动总金额=T日客户资金账户变动金额+T日收到的利息收入+T日手续费净收入-T日结转的风险准备金-T日结转的利息收入-T日结转的手续费净收入+T日申请存放的净自有资金-(T日接受现金形式的客户备付金-T日向备付金银行缴存的现金备付金)+(T日以自有资金先行赎回预付卡的金额-T日向备付金存管银行办理预付卡先行赎回资金结转业务)+T日未达账项金额+其他调整项目。

  • 备付金银行账户余额=支付机构业务系统中客户资金账户余额合计数-期末以现金形式持有的客户备付金余额+期末存在的以自有资金先行偿付的预付卡赎回金额+备付金银行账户中所含的未结转利息收入+备付金银行账户中所含的未结转手续费收入+备付金银行账户中所含的申请存放的自有资金+未达账项金额+其他调整项目。

二、 主题分享Q&A

Q:备付金得13张报表可以具体讲一下吗?(我确认下,你的疑问是这13张报表具体应该如何填制吗?)

A:如何填制和支付公司自己的会计系统科目如何设计息息相关,我可以大致说下填制规则(附件:央行报表的模板)合作行的话每个银行的不太一样,没有办法详细说明


Q:代付业务资金流是怎么走的?根据央行要求,只有备付金合作行(改为存管行)能提供跨行付的功能,假设支付公司备付金合作行为A,调用银行B的代付能力,收款行为银行C,银行B是怎么处理的?我们(翼支付)调用的是银行的代付能力,恒丰,招行,光大。

A1:合作行一般1 2 3 6 9 10 有些要11 13,互联网支付的

A2: 你说的A户是存管账户;B是收付户。如果需要用B行的代付,只需要在B行开通收付户,并准备资金就可以了

A3:银联代付业务备付金系统支持上有些问题的,上次跟人行聊起过,他们说银联代付上报内部要重新讨论下。就实施而言,个人建议大家把主要精力集中在交易数据与出入金上报上,13张报表先放放再说。因为代付不是备付金出金的,与原先系统设想不一样,所以不好报。

Q:代付能力提供行是b行,b行扣b行收付户的钱,然后代付到c行卡,这样?

A:并不是,B行本身不支持跨行付款。你的上一个问题(代付业务资金流是怎么走的?根据央行要求,只有备付金合作行(改为存管行)能提供跨行付的功能,假设支付公司备付金合作行为A,调用银行B的代付能力,收款行为银行C,银行B是怎么处理的?)貌似不成立。只有存管行A才可以跨行转账到C,资金流就是 A–>C

Q:所以代付能力提供的行必须是这家支付公司的存管行?

A:对,你可以使用B行的同行代付。允许做的是:B行收付户-》B行 ;A行存管户-》任意行的账户

Q:使用B付款到银联代付户 可以吗?

A:现在的保险做法一般是接某家已经与银联对接的银行,通过银行使用银联代付,这种一般是可以谈垫资的。


Q:手续费收入可以在支付账户中进行记录吗?如果可以,备付金报表怎么做相应的处理呢?其中支付账户指的手续费账户的客户,也就是支付公司本身

A:这里说的支付账户如果是指支付公司为客户开立的记账账户,按照我的理解回答吧,一般做法是在系统中开设业务中间账户用于记录手续费收入。体现在1-11(已结转收入) 和1-12中(未结转收入),支付公司内部的账户设计一般分为三类:支付账户、结算账户、业务中间账户。

Q:这个业务中间账户,不是指上边说的客户资金账户(支付账户)吧,我理解的对吗?

A:是区别开的,理解的没错

Q:那1-11(已结转收入) 和1-12中(未结转收入),对应的业务,就是记录在“业务中间账户”的吧?我理解如果记录在支付账户,是不是就应该和客户的充转提归为一起,来看待了?

A:手续费收入指的是交易发生为支付公司带来的收入,会有三种,1.预付:客户提前预存 2.实时扣:交易成功后从入账金额中扣减 3.后收:交易后按日或按月收取。从记账角度看是记录在“业务中间账户”,体现在报表中是收入,支付账户不是用来记录收入的哦~~


Q:结算账户是指哪些呢?

A:结算账户:用于代收资金记账,只能通过结算将钱拿走,结算账户不可以使用充转提,支付账户可以使用充转提


Q:代收资金的记账,会对应某个商户的支付账户吗?比如支付账户提现,结算账户的资金结算转出,或者说结算账户就是单独记录待结算款的?不对应支付账户?

A:这中间涉及2个业务主体:商户、账户。商户可以同时开通支付账户和结算账户,这两个账户没有直接关系,但都会有标记是属于哪个商户。


三、 自由讨论

3.1 支付路由QoS模型延迟处理办法

Q:麻烦请教一下,支付路由中qos计算模型,这个qos是在支付服务中计算一段时间的延迟率取平均值?还是计算请求当时的数据包延迟情况?

A:取决于算法设计,可以用窗口来计算平均延迟。

Q:窗口怎么理解?

A:比如5分钟时间内的平均值,5分钟为一个窗口,或者最近5笔交易。

  • QoS是不间断的检测,而不是没有交易QoS就不检测了,QoS计算因子不断地提供数,给规则引擎提供计算

  • tcp滑动窗口,类似概念,用于控制速率


Q:作为微服务模式的聚合支付,每个支付产品都是一个独立的支付服务,那规则上的制定就是检测支付服务的延迟率、丢包率>支付产品(第三方支付接口或银行直连接口)的延迟率、丢包率,支付的服务的计算因子权重>支付产品的计算因子权重,最后提供决策系统判断?因为我想理论上第三方支付接口出现的堵塞情况概率较低,更多的是本地支付服务对于支付能力的处理。

待回复

3.2 牌照讨论

  • 合并隶属同一法人下的牌照,方便管理和监督,市场上两百五十多张牌照,还是多了

  • 其实没两百多 其中预付卡就占了不少

3.3 支付手续费

订阅号:猫头鹰姑娘 《支付手续费设计思路概述

Q:手续费后收的模式有好的方法核账吗?财务手工去查流水效率好低而且容易出错。

A1:后收一般用应收科目来核算,建立商户应收–手续费分户账就可以了。如果担心交易状态变化,可以每变一次记一次,以便真实反映业务流程。

A2:我现在也有一个交易完成后收取手续费的需求,按状态收取

Q:交易状态分为:成功,交易中,失败 ,但是交易中可能变成成功或者失败,不允许变一次收一次,对商户而言一个订单只能收取一次,一直没有一个好的方案

A1:成功才收

A2:后收一般采用,周期计费,周期结费吧。

A3:后收一般线下收取

Q:一个客户要求所有状态都可以收费,他自己来控制,用状态机方式是如何处理的?

A:如果是收费状态就记一条流水,计费是按流水计。订单变,一定是由A到B,B到C的变,计费就是这样。

Q:我现在的做法是等渠道系统的订单同步状态回来之后,用定时任务来统计,放到商户的支出流水里面,但是这样就没有办法在每个订单的手续费支出里面提现,后收回款会有各种各样的问题,有些公司会用母公司统一回款,有些网银中间还会收一些费用,导致银行流水各种核不上。

A1:可以逐笔记,

A2:还是要最终 根据 成功的 订单去走的,要看业务及业务部门需要,规则都是活的。框框就在那,订单要不总金额,阶梯计费;收费:事前收费和事后收费。

A3:系统和业务是折中的,规则也不是无限的,我们(民生金服)要求商务签合同必须支持单笔计费,否则分布式计费麻烦了。计费就是算出应收,后收的核销比较麻烦。不过也没关系,躺在应收账上就行了。


Q:你们没有商户总结算额超过200万就有打折这种场景吗?这种场景如何分布式?还有算了费之后财务能不能手动修改,以及免收

A:打折的情况结算后补个账

Q:这种(打折补账)账务上怎么处理?

A:阶梯打折或免收事后财务手工处理,或在结算时再处理

Q:计费系统不记录?也就是应收和实收

A:不计,结果汇入科目就行了,可以将差异计入公司营销费用。

Q:也就说在做计费的时候只算费对吧

A:账,一定要真实反映业务,进出两条线。


Q:那假设一个客户用分布式同时算10笔费用,各50万,收费规则说,结算总额100万以内的不打折扣,超过100万的按8折收取,怎么事后补账?(中央结算:我们不用分布式算费,所以没这个问题,但像我们的收费规则是这样的,笔和笔之间不完全独立)

A1:账户肯定都有一个运营模块,可以进行查询,修改,达到那个的时候,系统也好人工也好改下费率

A2:按全折算一笔应收,再补一笔八折后的差额,应收-实收。打折是营销,是公司的支出,手续费是收入。营销费用不在计费时做,事后处理。

Q:但是财务人员要看到最终收多少费用,是不是还需要加上营销这方面的考虑?

A1:如果做的好点,就放在结算阶段。

A2:我们(海尔快捷通)采用支付流程、清洁算规则、清洁算协议的模式,把一笔基础支付抽象成一个支付流程的多个节点。比如 入款支付流程:初始、支付申请、支付成功、支付结算等,每个节点可灵活配置对应清洁算规则,每条清算规则对应一个完整的复试记账条款,清洁算协议控制个节点执行时间、同步异步。 同一个支付流程多套清洁算规则。可以在支付成功时计费,也可在支付结算时计费。

A3:我们(民生金服)是实时清算的,结算计费都是事后业务

实时清算,把结算计算归在事后业务的处理方式的讨论:

  • 这种方式(A3民生金服的方式)灵活,就是流程长。直接结果就是支付响应时间长点。支付流程上结算指钱从中间过渡户到商户结算账户。不是结算到银行卡。

  • 分为异步和同步,我们(民生金服)实时清算分同步和异步,异步可以合并批量。主要是信托类资金大,要及时系统内部核对。准确的说,主要是清分要及时。

  • 比如收单:支付成功,借 渠道入款待清算,贷 *中间过渡户;支付结算,结算(借 *中间过渡户 贷 商户结算账户 )收费(借 商户结算账户 贷 手续费账户)。一笔交易多方收手续费,分润方也收手续费的,麻烦点。(也就是分账)

3.4 维金系统小议

Q:快捷通用的维金系统吧?

A:是的

Q:快捷通的系统带源码的吗?

A1:有源码

A2:只买了源码,后面都我们自己开发的,迭代的。

Q:改了之后谁维护?

A1:自己维护

A2:自己维护也行,也可以交服务费

3.5 金融风控探讨(后期可预约分享)

  •  风控这个东西有趣的地方在于你很难界定他到底资产过不过关,接着是没出问题的时候,很难得到重视,出了问题后他又没啥用,反正就是很尴尬,还好做程序系统的风控还是可以量化的,比纯粹做金融的风控好点

  • 天上不会掉馅饼,这就是风控,风控主要是事前,事后没毛用了

  • 天上肯定不会掉饼,但是这个风控的度怎么度量呢?这个是个很哲学的事情

  • 赚钱太容易了,就有风险了

     太好跟太差的资产不用说,那种不怎么好也不怎么差的呢?这玩意很难搞的

  • 我们做系统的可以量化,比如可疑交易,信用卡套现什么的

  • 收益超过12就要小心了,12%是个经验值

  • 但是真正金融资产,比如一块地,一个企业,跟难衡量的

  • 想要高收益,就要承担高风险。

  • 那些大金融我们不要考虑了,专业性太强了,企业投资跟我们不一样

  • 小的也很难呀,比如人的信用和贷款金额

  • 大宗电商平台几乎都有期货投资部门,主要是进行反向操作,降低风险,减少损失。

  • 那个涉及到评分模型了,对冲是必要的

  • 大宗类更难了,要有套保操作,套期保值

Q:我其实挺想问,评分模型真的有用吗,过滤器能过掉多少,剩下的用户能覆盖收益吗?

A:评分模型一般是依据业务可承担的风险程度来设置。


Q:请问有接触过个人消费信贷评分模型吗?

A:没有,不过正在研究,估计就是些因子计算,模型要训练才能投产。 我不夸张的说,我所知道的很多聚合支付码牌,要是真的走正规风控流程,交易量最少掉 20%。 风控不是不做业务,主要是预警。这个就看风控级别定义了


感谢您对本文的关注,如需要及时收到来自“支付产品技术交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。本文档来自“支付产品技术交流群” 的聊天记录整理,由志愿者整理并发布到本网站。文中部分链接不可用,请点击“查看原文” 阅读完整版本。