Categories
程式開發

有贊保理業務架構設計與實踐


一、背景

為保障消費者權益,有贊提供基礎消費保障服務。買家確認收貨後,資金才可結算到賣家店鋪餘額,普遍的結算週期在7天左右。從商家的角度出發,結算賬期的產生使得資金周轉變慢,這為擴大生產交易規模製造了困難。於是快速回款產品應運而生,有贊通過引入保理機構,以應收賬款保理轉讓的模式來幫助商家實現資金快速回籠。

二、保理簡介

2.1 什麼是保理

在開始前我們會問,什麼是保理。保理即保付代理,是一項集保理融資、銷售分戶(分類)賬管理、應收賬款管理及信用風險擔保於一體的新興綜合性金融服務。

2.2 保理的好處

  • 對平台無槓桿:金融裡的槓桿,就是指負債。例如:企業本金1000元,貸款9000元,那麼企業總資產是10000元,負債率是10000/1000=10倍,負債越高,風險越大。保理基於企業本身的應收賬款,可以避免利用槓桿。
  • 對企業無負擔:無新增負債。
  • 提高企業資金流動:固定資產流動。

2.3 常見業務模式

供貨商通過賒銷的方式提供給採購商貨物,同時簽訂了供貨訂單。供貨商將代表應收賬款債權的供貨訂單向保理商申請轉讓,保理機構折價支付款項。賬期到期後,採購商支付貨款給供應商,供應商向保理商回購債權。

有贊保理業務架構設計與實踐 1

三、保理在有贊快速回款中的應用

3.1 問題分析

根據《中華人民共和國消費者權益保護法》第二十五條規定,經營者採用網絡、電視、電話、郵購等方式銷售商品,消費者有權自收到商品之日起七日內退貨,且無需說明理由。因此除少部分特殊訂單外,有贊大部分的訂單都需要商家發貨後,需要等待最短7天最長30天的周期才能進行結算。其交易流程大致如下:

有贊保理業務架構設計與實踐 2

從資金流向上分析,其大致如下:

有贊保理業務架構設計與實踐 3

按照正常的交易流程,支付成功後,待結算資金會在支付公司停留7~30天的時間。這段時間內商家無法操作這筆資金。對於資金比較緊張的商家來說,加快資金周轉效率是重中之重。

3.2 快速回款保理模式

從以上電商場景中發現,商家待結算的資金可以認為是一種應收賬款。在保理業務中,賣方(即商家)可以針對這筆應收賬款進行轉讓,保理公司就可以向其提供資金融通等一系列的綜合金融服務。在有贊此項服務被命名為快速回款,其流程設計如下:

有贊保理業務架構設計與實踐 4

商家發貨後,把待結算資金當做應收賬款向保理公司發起融資申請,保理公司審核後進行放款,商家就可以提前使用資金。交易訂單結算後,以結算款發起還款。保理公司回收本金,並收取服務費。

四、有贊保理系統架構

4.1 業務架構

目前初期階段,需要滿足基本的保理業務,包括:

  • 產品配置:產品配置是包裝保理業務對外服務的入口,產品的費率、資方渠道、還款模式等都是在這裡提前確認。
  • 授信管理:結合商家的真實交易數據以及信用情況進行額度授信。控制放款資金和企業風險。
  • 應收賬款管理:針對已經轉讓的應收賬款進行管理,包括收賬、對賬等。
  • 融資管理:受理企業融資申請,應收賬款轉讓,為債權人提供融資服務。
  • 保後管理:融資放款後直到完全回收的過程中,需要進行定期檢查、風險預警。對於到期情況需要進行還款結算,債權回購。有效保障資金安全。

有贊保理業務架構設計與實踐 5

4.2 技術架構

4.2.1 服務路由

通過產品配置,我們的保理系統可以包裝出多款產品。雖然保理系統的模型可以抽象,但是適配產品的保理模式千差萬別。我們希望的場景是保理系統提供統一的api,通過產品編碼去路由不同的保理模式。在此需求下,我們設計了接口路由模型。其模型如下:

有贊保理業務架構設計與實踐 6

以融資申請為例,QK_001,QK_002,DZD_001 這三款產品都需要調用融資申請接口。當請求進入到service router後,service router通過入參中的產品編碼和調用的service api,在router config中尋找相關的配置信息。當發現匹配的服務時,路由到對應的保理模式中。

4.2.2 狀態機工作流

由於保理業務存在一定的複雜性,往往一個接口請求內部需要進行一連串的業務處理,然後異步返回結果。我們選擇使用狀態去標記一個請求業務處理執行到哪個節點,一個一個狀態串聯組成工作流。其模型如下:

有贊保理業務架構設計與實踐 7

五、後續

目前保理系統已經支持快速回款產品的對外服務,但是從功能上還有許多需要完善的地方。接下來會從內部功能和外部產品包裝上不斷完善。

本文轉載自公眾號(ID:)。

原文鏈接

有贊保理業務架構設計與實踐