将路由概念引入信贷领域，实现端到端不同路径的资金分发策略，其中有效的设计能够对互联网金融带来帮助。本文详细介绍了资金路由的概念与详细的系统设计思路，从业务流程的基本图解到前端展示实例，为资金路由系统设计提供了有效参考，适合关注互联网金融产品的小伙伴阅读。
高端的系统设计思路往往借鉴于生活中最常见的事务。
我们这一代人，一提到路由，估计第一时间想到的路由器，路由的工具。
路由（routing）的定义指的 指分组从源到目的地时，决定端到端路径的网络范围的进程。在网络领域，不同的路由策略决定了端到端的路径不同。此设计理念也在信贷领域也可用做出引入并且发扬光大。
我们引入资金路由原理：
资金路由由一系列决策集合组合，其核心是决定端到端的不同客户资金分发策略的过程。
为什么需要资金路由的设计，这是由整体互联网金融的流量合作模式决定的。当客户进入流量平台后，由于流量平台没有足够的头寸进行放贷，那么就需要把客户推荐给资金方进行放贷。
如果一家流量平台接入了多家资金方，不同资金方的授信通过率，头寸大小、分润比例以及客户偏好不同，这就需要一系列规则来决定一个客户该路由给其中哪个资金方。如果一家资金方收到资产方的客户申请之后，资金方目前的头寸也不足，或者这部分客户自己消化不了，资金方也可以接入资金方，那么资金方也需要一套路由设计，来决定是否路由给外部资金方。
所以资金路由有可能发生在资产平台路由资金方，也可以发生在牵头资金接入参与资金。
在上图中，我们可以看到客户在资产平台申请借款，最后可能是资产平台对接的资金放款，也可能是其对接资金背后的资金放款。其目的是如何把已有的客户最大有效的分发，这种设计背后可以看出流量端的匮乏以及合作场景的多样性。
路由设计的前提是资产方要对接了很多资金方，如果一家资产方只对接了一家资金方，那就没得选，也不存在路由的概念了。如果资产方对接了很多资金方，那就会拥有幸福的烦恼，所以路由系统的前提是需要有一系列资金方。
同时路由还需要有一系列规则组成，不同的资金方配置不同的规则设定。这样当客户进件之后，依次校验各种规则就形成一个漏斗集合，每过一条规则，那么就过滤掉一些资金方。直到最后一条规则跑完，最后留下的资金方，就是此次路由结果。
首先客户先过资产方的前筛路由，过滤掉一些共性不符合准入的客户。接着进入辅助策略，比如白名单策略，最后是过资金方运营策略，最后所有策略都过了，留下的资金方，就是资金路由策略结果。
为了提高资金路由的效率，在进入资金路由之前，还会进行前筛规则路由设计。其目的是有些客户连平台本身的规则都过不了，那当然就没有进入资金路由的必要性了。
比如常见的前筛规则如下：
对于生产验证客户，需要设置白名单规则，如果一个客户在某资金方的白名单中，那么自动路由给该资金方。如果一个客户在好几个资金方的 白名单中，那么这几个资金方参与资金方运营策略路由。
资金运营策略由一系列复杂的策略集合组成，其核心是资金方运营策略，其由一系列路由规则维度集合组成。同时因为一些特殊场景，需要设置指定分发策略。
主要路由顺序：客户白名单、黑名单校验，客户产品要素校验，资金方前筛，资金方头寸，最后剩下的资金方优先级最高的给客户放款。
资金路由集合可以在后管配置一个界面，此界面可以配置每个资金方和以下规则的关联关系，以及资金方的具体要求。后管设计的核心逻辑如下图：
常见的地区有：
资金路由前筛是资金方提前和资产方沟通，一些明确拒绝的客户，此规则相对资金运营策略更加个性化。如果有一些规则和资金运营策略重合，取并集。
头寸管理主要以时间维度展示资金头寸大小，当期可用额度，如果头寸不足当期资金方暂停路由。头寸大小也可以参与计算头寸使用率，比如当天投放金额/头寸金额用来评估路由效果。
所谓路由兜底，指的是当路由所有的资金方之后，发现当期的资金方都不能满足客户的放款要求，这时候自有资金恰好可以满足，所以这时候可以设置自己有资金兜底。这就是路由兜底功能，由于路由过程中客户是无感的，其预期结果要么是 外部资金要么是兜底资金放款，所以需要同时展示路由的外部资金和自有资金的协议进行前端展示。
资金路由有流量分发、借据分发、长尾流量分发，模式设计的原则是客户一般分为授信和用信，以及授信拒绝和用信拒绝，这样可以不同的流程节点进行分发。也可以有指定资金分发策略，来应对一些资金方的特殊要求。
指的是平台的流量按照一定的比例和规则直接路由给资金方，平台不对客户进行授信，客户的授信和用信以及后续的服务全部由资金方来合作。
指的是平台先对客户进行授信，然后客户在用信的时候路由给其它资金方。
2.1 借据级分发：借据级别分发是对客户每次借款的时候，进行一次路由，路由到某个资金方，那么由该资金方放款，下一次借款可能路由给另外一个资金方。因为是以单次放款维度进行分发，所以叫借据级分发。借据级分发对平台的优点是灵活，流量分发的颗粒度最细，对客户产生的影响就是每次借款的资金方可能不同，多次贷款的还款提醒短信分别由不同的资金方发送。
2.2 客户级分发：客户级分发是客户第一次路由给某个资金方，那么下一次客户就不过路由，直接分发给某资金方。客户级分发对资金方的服务要求很高，通过率要保持稳定，对客户的体验稍好。
对于一些流量 ，可能一种情况是经过资金运营策略，所有的资金方都拒绝了，或者是自有资金拒绝了，这些客户如果都放弃了，对平台是很大的损失。所以需要对其进行分发，其又可以分为全部分发和均匀分发。
3.1 全部分发：去市面上找一些能够全部吃下客户风险等级很差的资金方，对于资金运营策略全部拒绝的客户，都路由给这家资金方。
3.2 均匀分发：
正常情况下很少有资金方能够吃下所有风险等级很差的客户，所有造成的结论是很多差客户路由给风险识别能力很差的资金方了。
对于这部分长尾客户，如果全部路由给识别能力很差的资金方，造成的后果是这家资金方必然不长远。为了解决此问题可以再对风险等级很差的客户，做长尾平分分发。有点像买苹果一样，挑剩下的一大筐苹果，里面有好苹果也有烂苹果，目前还有三个顾客需要购买。
如果让前面的客户继续挑选，那么最后一个客户面临的肯定都是烂苹果。所以需要对客户A、客户B、客户C进行路由设计。
3.3 长尾道理设计原理：长尾客户，应该均匀分配，使得合作利益最大化。
支持长尾流量优先级配置：比如优先A，其次B，最后是C。然后针对长尾客户的池子，进行按比例或者按数量进行分配配置，比如A 30%，B分配30%，C分配40%。其原则是A 分配满了之后，再分配给B ,B分配满之后再分配给C。
如果对于某些资金方，基于特殊的合作关系，需要将特殊的一些客户给某些资金方，这样可以基于指定的资金方路由。这种场景下，是基于路由的路由结果，如果先命中指定资金分发，那么就不进入正常的路由规则配置中。一般这样的指定资金方的都是通过离线跑批的形式决定的。离线跑批是合作双方基于信任的基础上，双方的数据都是经过加密的，由线下导入进行匹配，匹配上的客户提前打上指定资金的标签，下次路由就直接路由到指定资金。
在app或者h5等前端设计的时候，最好先调用路由查询，先获得了资金方，这个时候就可以展示资金方的协议如图为客户分发下，展示金融机构名称。
还有一种情况是展示资金方的协议以及自有资金的协议，这样当资金方放款失败，自有资金可以直接兜底。
当路由结果给某一个资金，但是其通过率太低，会影响到整体客户的投放，虽然有自有资金进行兜底，但是自有资金也可能存在头寸不足或者客户要素和自有资金不匹配。
这样会有相当部分客户浪费掉了，为了提高资金的授信和用信通过率就需要联合建模的方式一起提高通过率。联合建模主要双方拿一些有历史表现的数据，由资金方到资产方的环境模拟跑数据。
具体由资金方提供一批有风险表现的用户去匹配资产方的数据特征，去找出一些识别度高的特征，比如黑名单这种。挑选出的变量由资产方进行模型部署，这样资产方就指定资金方不需要哪些客户。
流量分发的路由时序图简化图：
如图，在客户进入资产方之后，就被路由给资金方，由资金方直接授信和用信。借据分发的路由时序图简化图
如图，在客户先在资产平台申请授信，授信成功后再用信环节路由资金方。
由于不同的数据源，路由过程要调用大量的路由，这样需要分析每个路由系统的调用时长，以监控路由发生过程中的异常数据源。监控的维度有调用次数，失败次数，每个路由节点的日、周、月的调用时长。
后管设计按照以上设计原则进行界面设计，界面设计的原理是逻辑和层次清晰即可。比如白名单管理、资金头寸管理、资金运营策略、资金方管理、指定资金策略管理、均匀分发管理。其功能架构图如下：
其中资金路由策略里面每个小模块可以作为一个后管配置界面，在配置界面里面按照资金+规则维度逻辑关系配置我们要的具体规则。
路由系统的设计效果，来自于当接入的资金方不变，客户资质不变，最后体现在投放金额的提高上。即资源这个变量不变的情况下，路由系统的效果是增量提升。
其衡量指标：
资金方头寸使用率= 资金方头寸使用额度/资金方头寸额
路由成功率=路由成功量/路由申请量
路由的发展方向是更加精准，而更加精准的后续发展就是从从数量向质量的发展。比如搭建一个模型，在资金推送的同时实时计算当天的路由收益情况，实现收益最大化的路由。
总结下来路由的设计让我想起了当年做工业软件的自动排产系统，其核心就是根据前置条件筛选出我们想要的最优方案。我们知道资金路由其概念和原理，后面无非是用新技术去优化，以及壮大其场景。
之前我们讲的流程是流量从是从无到有，而现在从有到优，这是是属于路由系统的胜利章节。
呱说产品，微信公众号：呱说产品，人人都是产品经理专栏作家。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。