摘要:在互金公司做抵押贷款两年多时间,从贷前用户进件,审批流程,到贷后用户还款入账,结清资产,与第三方资方对接全流程参与需求评审,设计,开发,测试,上线。现在要离开公司,想以自己工作的经历,总结一下金融行业贷款业务的整体流程。提供一些设计思路,以及一些设计原则,提高自己的代码设计,业务理解能力。
-
整体概述
贷款,是指根据国家政策以一定的利率将资金贷放给资金需要者,并约定期限归还的一种经济行为。从这句话中不难看出,互联网贷款,就是用户通过系统,然后系统把钱借给用户,根据国家规定的利率,采取不同的收取策略,对借出资金进行回收。现在贷款种类根据是否只需要用户信用情况信息进行担保,分为信用贷款,和抵押贷款。抵押贷款是根据用户提供的抵押物,评估价值,根据价值给用户提供一个可以提款的额度,用户只可以借款额度以内的金额,并且使用。本文主要以抵押消费贷的视角进行阐述。如果公司想要在公开渠道发行这款产品,必须是要在银保监进行备案,并且获得互联网消费金融牌照才行。
-
详细描述
关于互联网金融贷款业务,可以大体分为两个部分,一个是贷前,一个贷后。从名字就能知道,一个是贷款动作完成之前的业务,一个是贷款动作完成之后的业务。贷款之前,主要是客户与系统交互,从用户引流,用户信息资料获取,用户征信信息获取,借款合同签署,用户额度授信,用户银行卡绑卡,用户用款申请,到最终审批放款,至此贷前业务完成,在这个阶段,基本上是系统数据的初始化阶段,包括用户基础信息,授信信息,用户借款信息,用户应还款信息,初始化到数据库中,后续的贷后业务,基本上都是围绕着这些基础信息进行操作以及处理。贷款放款之后,就到了资产回收,入账销账,贷后管理,内部系统数据同步等阶段,说直白一点就是系统处理用户还款信息,保证借款按照合同所约定的情况进行还款,尽量保证公司的资产不受损失。
-
贷前
由此可以看到,整个贷前业务呈现线性结构,所以通常以流程引擎为基础开发框架,配合业务系统,来完成每个业务节点需要完成的业务需求,和审批需求,提高开发效率。在不同的节点需要调用不同的第三方或内部系统,并且如果是不同的金融产品,在业务节点上相同,但是具体实现是不同的,所以此处采用模版方法以及工厂模式的开发模式可以极大的提高代码的复用率以及可读性。
-
贷后
整个贷后业务在业务上比较复杂,主要是针对用户的还款计划进行处理还款,保证公司资产不受损失,此时要考虑用户还款逾期,用户部分还款,用户生成账单,但是隔一段时间还款造成数据异常等情况。用户提前结清过程中,要计算用户提前结清的违约金等。然后用户还款核销入账后,需要修改的表包括还款计划,还款历史,用户借款合同,数据上报等表,是一个超长的事务,不可避免的可能会产生事务问题,如果是跨越多个微服务,还可能会产生分布式事务的问题,所以在设计过程中,要计算好,在哪个事务不会影响其他事务的处理,或者哪些数据是一定需要保证成功的,要保证每个流程互不关联,不需要等待哪个业务完成后,才能完成后续的业务,提高系统的可用性。
-
增强设计
从上面的流程可以看出来,围绕了一个金融产品,并且全程没有其他公司或者集团进行参与的流程,全部是公司内部自我的业务。但是在金融行业,公司与公司合作,公司对公司投资的行为普遍存在,并且抵押贷算是比较优质的金融产品,所以在真正的场景中,经常会有几种产品模式。第一种,直接对接贷前,用户信息注册,也会在第三方资金方系统注册,其他贷前业务流程也会在第三方资金方中进行,最后放款由两方合资,或者一方独资,最后,将贷后业务进行组合,由我方管理,就提供能力,在收到款的同时,进按合同规定的资金分润比例同时打到第三方资金方的银行卡上,或者记录每一笔收益,等月底进行统一的资金分润,通过线下方式转入对方对公账户。第二种,只对接贷后,这样的资产方归属全部是我方,用户借款信息就是我们的真实资产,这个时候我们就可以对这些资产进行直接的转让,这种行为被称为债转,改变了资产的所有方,但是贷后的管理可以发生变化,也可以不发生变化,不发生变化就是和直接对接贷前一样进行收益分润。如果将贷后管理同时转让给第三方,第三方对资产进行还款处理,就必须考虑还款信息的同步策略。如果资产发生逾期,并且逾期期数过大,这种就被称为不良资产,如果不良资产过大,资金的损失概率变大,是所有第三方公司不愿意看到的,这种时候就会要求我方将这些资产买回来,变为自己的资产,这个业务就被称为回购,此时的资产归属方就又变为我方或者其他方。
其实在后续还有很多业务,包括几期的时候如果资金不足,可能不用全部回购,选择按期代偿可以减少不良资产的回购率。第三方拿到这些资产,可以进行打包成金融产品,基金信托服务,进行售卖等等 ,这些业务我接触不太深入,就不在这赘述。
-
总结
互金系统的业务属性很稳定,不太可能有大批量全新的业务需求出现对行业造成冲击,所以保证系统的稳定性以及高吞吐率是重中之重。由此,在进行互金系统架构过程中,设计模式,中间件的高可用性,微服务熔断降级,分布式事务等是优先考虑的问题,业务基本上都是业界可循。如果抽空可以整理下思路,对互金系统进行微服务划分,关键点设计进行总结。