【业务】借贷业务笔记

仅仅记录自己的理解，不正确的地方 希望指正。

背景

任何事物出现一定是为了解决问题，而伴随着互联网的到来，在经过监管部门的规范下，互金行业借贷也逐渐规范化，而各个互联网企业借助自己流量实现变现也逐渐成为趋势。互联网可以一定程度上为这种小额贷款提供一定的效率、形式上的方便。

而如果进行仔细的划分的话，一共是三种角色，用户、互联网金融平台、金融机构。前者比较好理解，用户对于只要可以进行注册一个账号的就可以，而金融平台需要借助于本身自己整个平台或者是父公司的流量进行引流、获客。而流量就是王道，而对于金融机构来说，有资金但是如何获取更多的用户呢，这个时候就出现了 一个上下游需求供给的供应关系链。

对于一个金融结构来说主要的BU ：风控/研发/大数据/ 而产品、QA、运营、财务、法务等基本都是存在的。 而需要对接的下游链路就是各种消费金融机构、银行等。

主要名词

二要素、三要素、四要素 ： 既用户的身份证卡号、手机号等信息
放款、借钱 ：一个是对于平台来说用户借钱就是一笔钱进行流入到用户的账号中，而是否放款就需要按照用户的征信等其他相关信息进行风控审核。
还款：用户借钱完毕之后，需要按照一定的期限进行还款。而还款的方式可以按照每月固定日期还，可以提前还，也可以提前结清剩余期数。
提前结清：用户有主动意愿进行结清整体还款，可能手上有钱了，或者需要相关的房贷等证明等。
还款计划：对于用户借钱完毕之后，需要计算出还款的每次还多少。
期数：用户借款时会选择借款多少期，一笔成功的放款对应对比还款。
终态：第一次看到还以为是什么意思，后来了解了下 发现就是一种订单的最终状态，对于较为复杂的流程来说，中间状态可能比较多，但是最终只能有对应的失败、成功两种状态。
代扣：替机构进行扣款， 比如用户A 需要还款，但是对于咱们平台来说不能直接进行扣款，所以需要三方支付平台按照对应的商户号进行扣款。对应代付也是 三方支付平台替我们去支付。
代偿：代偿的话，也是中间的担保方会为某一笔或者整笔的逾期订单进行偿还应该的本金、利息。
逾期：用户应该在每月30号还款，但是超过了30号没有还款，对于不同的资方来说，可能规则不同比如T+20为代偿订单。 有的是逾期既是代偿订单，所以不同期限不同需要分别对待。
合同文件：对于用户、金融平台、消费金融机构来说用户是不能进行纸质签约文件，所以只能线上化进行处理相关文件，比如盖章、所以就涉及到和资方的文件的上传、下载。操作不同文件代表不同的含义。
授信：授信其实就是放款前的一系列步骤中的一个，基本上对于申请类接口来说需要保证幂等性，只能调用一次，而处理的结果需要依赖相关的查询接口。比如授信申请、授信查询、放款申请、放款查询
总的流程来说：用户申请放款- 》授信-合同文件的上传下载-》放款-》还款计划生成-》还款-》逾期-》代偿 -》结清证明
T+1：当天日的基础上添加一天，拉取文件或者代偿的规则等。T指代当前日。

鉴权

绑卡：在用户开始交易之前，第三方支付机构需要判断你是否有使用这张银行卡的使用权，简称绑卡。而如何验证使用权呢，就依靠四要素: 那第三方公司是怎么验证用户的使用权呢？在国内，我们一般采用下面这4个要素来进行验证：
用户姓名
用户身份证号码
银行卡号码
银行注册的手机号 这4个要素都是银行记录的信息，因此虽然看起来你是在第三方支付公司的App上进行绑卡操作，其实是银行在背后进行相关信息的验证工作。
由于这4个要素都是电子信息，可能会被人盗用，所以为了进一步增强安全性，银行在验证手机号码的时候还需要验证你是否拥有这个手机号码。具体的方式是发一条验证码给在你在银行柜台办借记卡时注册的手机号码。
我们可以把鉴权的过程分为4步：第1步，用户填写前3个要素和手机号码；第2步，银行发短信验证码给用户手机号；第3步，用户将前3个要素和短信验证码发给第三方支付公司；第4步，第三方支付公司再将所有信息发送给银行进行确认。
所以鉴权的过程其实是验证了5个信息，其中4个是静态信息，1个是动态信息。
在用户绑卡通过之后，银行会返回给第三方支付公司这个用户的内部ID信息（也叫Token）。之后第三方支付公司就可以拿这个ID进行所有合法的操作。
刚才给你讲解的流程示意图如下：

支付

鉴权完成之后，就可以扫二维码，进行支付了。二维码其实是一个图形化的字符串，背后是这笔交易对应的订单。当用户点击“确认”之后，就会开始整个支付流程。

拉取支付状态

那为什么需要拉取支付状态呢？我们还是从台前转到幕后，从系统功能的角度思考。
用户App的支付确认按钮是有局限的，它只能确认后台是否已经收到了支付请求，并不能确认支付是否已经成功。这是因为支付后台需要花一些时间和银行沟通，在这个期间后台并不知道银行的支付流程进行到了哪一步。
由于不知道支付什么时候才能完成，用户App需要每隔一段时间就向支付后台拉取交易情况，我们通常会把这个过程叫作轮询。这个过程一般在几百毫秒内就能结束，所以你一般察觉不到延时。
那为什么会出现轮询这种系统对接方式呢？金融机构每天会面对大量的用户资金操作，这些操作的时间和频率有很大的偶然性。
为了应对用户操作的峰值情况，金融机构普遍通过异步消息处理的架构来对极端流量进行削峰填谷。如果流量突然增大，异步消息架构会缓存所有请求，慢慢处理。这样就能避免核心金融系统超载。异步消息架构的结果就是用户不会及时得到处理结果，需要自己不断地去查询处理情况。
当银行处理完支付后，银行会把支付成功的消息推送给用户和第三方支付公司。第三方支付公司也会推送给你支付成功的消息。所以你在扫码支付成功后，通常还能听到两个手机消息通知的声音。
到这里我们看到了两种不同的获取最新状态的方式。一种是用户定期去拉取状态，另一种是服务器将状态消息实时推送给用户。这种推拉结合的消息通知方式，其实是架构设计中常见的异步系统处理方式。支付状态获取的流程图如下：

链接

等额本息&等额本金 https://hz.fang.ke.com/loupan/zhuanti/8600.html/
互联网金融基础篇 https://zhuanlan.zhihu.com/p/32237280