平安银行存管是什么？谁解释下？

1. 平安银行存管是什么？谁解释下？

平安银行作为存管人接受网络借贷信息中介机构的委托，按照法律法规规定和合同约定，履行网贷资金存管专用账户的开立与销户、资金保管、资金清算、账务核对、资金监督等职责的业务。不对网络借贷交易行为提供保证或担保，不承担借贷违约责任。
应答时间：2020-05-29，最新业务变化请以平安银行官网公布为准。

2. 介绍下平安银行存管业务

“第三方存管”是商业银行提供的一项业务，常见于证券、期货、房产等交易活动中。拿证券交易中的第三方存管来说，它是指委托存管银行按照法律、法规的要求，负责客户资金的存取与资金交收，证券交易操作保持不变。证券公司客户证券交易结算资金交由银行存管。
第三方存管
该业务遵循“券商管证券，银行管资金”的原则，将投资者的证券账户与证券保证金账户严格进行分离管理。第三方存管模式下，证券经纪公司不再向客户提供交易结算资金存取服务，只负责客户证券交易、股份管理和清算交收等。存管银行负责管理客户交易结算资金管理账户和客户交易结算资金汇总账户，向客户提供交易结算资金存取服务，并为证券经纪公司完成与登记结算公司和场外交收主体之间的法人资金交收提供结算支持。银行负责完成投资者专用存款账户与券商银行交收账户之间清算资金的划转，将券商的清算交收程序转移到银行，由银行代为完成。
实施保证金第三方存管制度的证券公司将不再接触客户保证金，而由存管银行负责投资者交易清算与资金交收。据《上海证券报》报道，证券业之所以引入保证金第三方存管制度，主要是为了从根本上杜绝券商挪用客户保证金的行为。有关统计资料显示，券商挪用保证金问题屡禁不止。
实行保证金第三方存管制度之所以能确保客户保证金不被券商挪用，是因为该制度有效地在证券公司与所属客户交易结算资金之间建立隔离墙。具体而言，实施保证金第三方存管制度后，客户可以在存管银行网点或证券公司的营业网点办理开户业务，在存管银行的系统中生成客户保证金账号，在证券公司的系统中生成客户号。遵循“券商管证券，银行管资金”的原则，由证券公司负责客户证券交易、股份管理以及根据登记公司的交易结算数据，计算客户的交易买卖差数；由银行负责投资者保证金账户的转账、现金存取以及其他相关业务。
实施保证金第三方存管制度基本不会影响投资者的现有交易习惯。在实施保证金第三方存管制度的证券公司开户，唯一的不同就在于存取资金只能通过银行进行。这有点类似当前不少证券公司推出的“银证通”业务。

3. 对接平安银行存管提现功能说明文档

 shiyi-pingan:平安代理服务   shiyi-account:账户服务   shiyi-cash:出入金服务   shiyi-admin-web:后台管理服务   shiyi-scheduler:定时任务服务
   
                                           
   
                                           
                                            说明：定时任务服务，定时的向出入金服务发送向银行请求1318接口的指令，出入金服务获取当前系统处于“审核通过”的订单，并将这些订单异步请求平安代理服务，此时将订单状态修改成“系统处理中”，让平安代理服务请求平安银行实现真正的提现，平安银行同步返回结果给平安代理服务，平安代理服务收到返回结果后，将请求结果异步通知出入金服务，出入金服务收到通知后，无论结果是成功还是失败，都将提现订单状态修改成“渠道处理中”状态；   定时任务服务，定时向出入金服务发送向银行请求1325接口的指令，出入金服务获取当前系统处于“渠道处理中”状态的提现订单，并调用平安代理服务接口请求银行的1325接口，查询处于“渠道处理中”状态的订单是否在银行端那边已提现成功，若银行端返回结果是“提现成功”的结果，则将订单状态修改成“提现成功”状态，否则将订单修改成“提现失败”状态，并异步请求账户服务，为用户加钱；   平安银行主动发起提现请求，向平安代理服务发起1312接口请求，出入金服务监听1312请求接口，监听到有请求过来，则创建“审核不通过”状态的提现订单。定时任务服务，定时的向出入金服务发送向银行请求1317接口的指令，出入金服务获取由银行端发起的出金请求所创建的提现订单，通过调用1317接口，通知银行那边该订单在交易网这边审核不通过，无需对其进行出金。 
    1318接口：交易网向银行端发起出金请求接口；   1325接口：查询某个时间段内或者查询指定订单号的提现订单在银行那边的状态，即提现成功还是失败；   1312接口：银行端向交易网端发起出金请求（这里直接创建“审核不通过”的提现订单，是因为银行端发起的出金，不进行处理，一律视为审核不通过，不对用户进行提现）；   1317接口：出金确认请求接口，即告诉银行那边，是否对某个订单进行出金。 
   
                                           
    问题1：为什么会有“系统处理中”和“渠道处理中”这两个状态，这两状态可以合为一个状态吗？ 
   答：系统架构是微服务架构，分了很多个服务，从【图:提现请求渠道阶段时的时序图】可看出，定时任务服务向出入金服务发起请求1318接口的指令，出入金服务异步通过平安代理服务间接请求银行的1318接口，然后平安代理服务会将银行给过来的结果异步通知到出入金服务，这时，出入金服务就将状态改成“渠道处理中”的状态。那么，为什么要分成“系统处理中”和“渠道处理中”这两状态呢，为何不直接将状态改成“渠道处理中”，这样不是更省事吗？ 答案当然是非也。   我们来设想一个场景：定时任务在请求1318接口时，出入金服务将状态改成“渠道处理中”状态后，这时，定时调用1325接口的任务也开始运行了，刚刚好拿到了这笔订单，这时请求1325查询该订单出金结果，发现该订单没有发送到给渠道那边，那么我们就会将该订单的状态改成“提现失败”，并加回之前扣的钱给用户。但是，由于是MQ异步发送请求1318接口消息给平安代理服务，这时，平安代理服务才刚刚消费到这个订单，这时去请求银行将这笔订单出金，那么这样系统的用户余额跟银行那边的用户余额就不一致了，因为银行那边出金了，会扣除用户余额，而我们这边却将这笔订单置为“提现失败处理”，并且加了用户的钱。所以，这两状态是不能合并成一个状态的。
    问题2：结合【图:提现非请求渠道阶段时的流程图】和【图:提现非请求渠道阶段时的时序图】，用户提交提现申请后，出入金服务创建“初始化状态”订单，然后异步发送消息给账户服务扣除用户余额，扣除成功后账户服务再将结果发送消息通知出入金服务，出入金服务再将该订单状态改成“待审核”状态。在这个过程中，账户服务扣除用户余额成功后，挂掉了，不能将结果通知到出入金服务，那么，这个订单将会一直是“初始化”状态，这样的订单要怎么处理呢？ 
   答：处理方式有两种。1.人工发现后处理；2.在签退后，发起出入金对账后，会将这笔订单置为异常订单（短款差异）。这时就要进行调账处理，将用户的钱加回去，并将订单状态修改成“提现失败”状态。