有赞保理业务架构设计与实践

一、背景

为保障消费者权益，有赞提供基础消费保障服务。买家确认收货后，资金才可结算到卖家店铺余额，普遍的结算周期在 7 天左右。从商家的角度出发，结算账期的产生使得资金周转变慢，这为扩大生产交易规模制造了困难。于是快速回款产品应运而生，有赞通过引入保理机构，以应收账款保理转让的模式来帮助商家实现资金快速回笼。

二、保理简介

2.1 什么是保理

在开始前我们会问，什么是保理。保理即保付代理，是一项集保理融资、销售分户(分类)账管理、应收账款管理及信用风险担保于一体的新兴综合性金融服务。

2.2 保理的好处

• 对平台无杠杆：金融里的杠杆，就是指负债。例如：企业本金 1000 元，贷款 9000 元，那么企业总资产是 10000 元，负债率是 10000/1000=10 倍，负债越高，风险越大。保理基于企业本身的应收账款，可以避免利用杠杆。

• 对企业无负担：无新增负债。

• 提高企业资金流动：固定资产流动。

2.3 常见业务模式

供货商通过赊销的方式提供给采购商货物，同时签订了供货订单。供货商将代表应收账款债权的供货订单向保理商申请转让，保理机构折价支付款项。账期到期后，采购商支付货款给供应商，供应商向保理商回购债权。

三、保理在有赞快速回款中的应用

3.1 问题分析

根据《中华人民共和国消费者权益保护法》第二十五条规定，经营者采用网络、电视、电话、邮购等方式销售商品，消费者有权自收到商品之日起七日内退货，且无需说明理由。因此除少部分特殊订单外，有赞大部分的订单都需要商家发货后，需要等待最短 7 天最长 30 天的周期才能进行结算。其交易流程大致如下：

从资金流向上分析，其大致如下：

按照正常的交易流程，支付成功后，待结算资金会在支付公司停留 7~30 天的时间。这段时间内商家无法操作这笔资金。对于资金比较紧张的商家来说，加快资金周转效率是重中之重。

3.2 快速回款保理模式

从以上电商场景中发现，商家待结算的资金可以认为是一种应收账款。在保理业务中，卖方（即商家）可以针对这笔应收账款进行转让，保理公司就可以向其提供资金融通等一系列的综合金融服务。在有赞此项服务被命名为快速回款，其流程设计如下：

商家发货后，把待结算资金当做应收账款向保理公司发起融资申请，保理公司审核后进行放款，商家就可以提前使用资金。交易订单结算后，以结算款发起还款。保理公司回收本金，并收取服务费。

四、有赞保理系统架构

4.1 业务架构

目前初期阶段，需要满足基本的保理业务，包括：

• 产品配置：产品配置是包装保理业务对外服务的入口，产品的费率、资方渠道、还款模式等都是在这里提前确认。

• 授信管理：结合商家的真实交易数据以及信用情况进行额度授信。控制放款资金和企业风险。

• 应收账款管理：针对已经转让的应收账款进行管理，包括收账、对账等。

• 融资管理：受理企业融资申请，应收账款转让，为债权人提供融资服务。

• 保后管理：融资放款后直到完全回收的过程中，需要进行定期检查、风险预警。对于到期情况需要进行还款结算，债权回购。有效保障资金安全。

4.2 技术架构

4.2.1 服务路由

通过产品配置，我们的保理系统可以包装出多款产品。虽然保理系统的模型可以抽象，但是适配产品的保理模式千差万别。我们希望的场景是保理系统提供统一的 api，通过产品编码去路由不同的保理模式。在此需求下，我们设计了接口路由模型。其模型如下：

以融资申请为例，QK_001，QK_002，DZD_001 这三款产品都需要调用融资申请接口。当请求进入到 service router 后，service router 通过入参中的产品编码和调用的 service api，在 router config 中寻找相关的配置信息。当发现匹配的服务时，路由到对应的保理模式中。

4.2.2 状态机工作流

由于保理业务存在一定的复杂性，往往一个接口请求内部需要进行一连串的业务处理，然后异步返回结果。我们选择使用状态去标记一个请求业务处理执行到哪个节点，一个一个状态串联组成工作流。其模型如下：

五、后续

目前保理系统已经支持快速回款产品的对外服务，但是从功能上还有许多需要完善的地方。接下来会从内部功能和外部产品包装上不断完善。

本文转载自公众号（ID：）。

原文链接：

有赞保理业务架构设计与实践