风控的核心关注目标的是客户逾期风险，而运营的核心是关注目标的放款量，两者目标是对立的，但又需要以公司放款盈利为最终目标。本文就信贷催收业务模式与系统架构搭建展开分析，希望能够给你一些启发。
18年毕业至今一直从事产品工作，近几年产品经历都与风控直接相关，从出行反作弊，到互联网金融参与信贷反欺诈，对接征信，决策引擎，又因为人事调整，负责贷后并重构了电催，法催业务系统。
其实工作过程中个人一直都有些零零散散的笔记总结，但随着负责业务的逐渐深入，越发意识到风控系统建设体系对于个人纵向职业发展的重要性，想着不如结合从事经验与看书学习，自己总结一套体系，以互金信贷为背景，在不泄露公司策略与数据的前提下，对互金风控各业务环节涉及到的系统搭建逐步进行整理，初步计划按照经历，进行思考总结：
从整个借款人自贷款平台发起借贷申请到最终放贷，直到借款人出现逾期流程。
当用户发起借款申请提交审核，到达贷前节点，平台会进入最重要的贷前风控审核环节，这一轮主要结合用户还款能力和还款意愿对用户的信用风险和欺诈风险进行评估，最终决策是否风控通过。
这个环节会直接拒掉大部分风险较高的借款人的申请，但依然允许小部分有风险的借款申请通过。
为什么风控允许存在风险的借款申请通过呢？
风控的核心关注目标的是客户逾期风险，而运营的核心关注目标的放款量，两者的核心关注点是对立的，但即便如此，风控与运营2大部门最终都要以公司放款实现盈利为首要目标。
公司财策盈利的概括公式：
盈利 = 放款后可回收金额- 资金成本 – 风控成本 – 运营成本 – 人力成本
其中资金成本是不可控的，风控成本与运营成本基本可控，所以为了提升盈利，平台核心就是要保证放款后可回收金额（作为毛利）的最大化。
我们看一组图形：
随着放款量的提升，不可避免的是出现逾期客户产生不可回收损失的量会随之攀升；历史P2P批量爆雷，出现大量贷款无法回收，本质就是追逐放款量的情况下，没能做好风险把控。
但一味控制风险，是无法实现利润最大化的，所以在整个放款平台做财策的时候，会要求风控将逾期率控制在一定比例下，完成一定量的放款，可以达成平台预期的放款收益，如下图：
（本图便于大家通俗理解绘制，不与实际业务数据有关联）
当达到B点时，整个毛利是最大的，平台可收回欠款及利息达到最大，在这种情况下，风控既不违背自己控风险的初衷，也实现了平台盈利。
当然以上只是粗略的概括，关于平台做出财策，制定放款量与风控逾期率是需要进行多维度的计算。但这也说明了，
贷款平台在主观程度上，可以承受一部分客户出现逾期。
自2019年至今，疫情经历3年，不少人在大环境下被迫失业，没有了收入来源，借款人是无法保证自己能够如期还款的，缺乏还款能力，这是不少债务人的逾期原因。
当然还有一些债务人，本质上是缺乏还款意愿的，除开黑产和专业骗贷户，还有些债务人在一些不良平台被套路贷，真正借款到手3万，实际不良平台通过多种形式收取费用，有或者后者多平台贷款，实际借款10万，导致债务人内心不愿意承担本没有借款的本息费用。
但无论在什么情况下，平台虽然能承受部分客户逾期，但为了降低整个平台损失，需要通过催收，将债务人欠款进行追回。
在介绍业务模式之前，说明几个基本的名词定义便于理解：
整个催收的业务链路，是由上游委托方发起，委托方先进行案件委派，催收团队负责接收并完成催收作业，最后根据回收情况进行分润；
在整个催收过程中，催收团队负责接收案件，由团队内部催收运营经理，配置分案策略与催收策略，完成案件分发，到具体催收员作业的整个过程，其中并搭配部分稽核专员，对催收员的催收过程进行事前要求，事后监督，以保证其在合规与团队设定的要求下进行催收作业。
当催收员收到团队分配的案件时，开始实施催收行为；
催收行为本质是由催收员通过各种合规手段联系人到债务人，当债务人被通知要求还款后，结合自身经济能力进行还款。结合福格行为模型对整个被催收时，债务人发生还款行为进行拆分。
福格行为模型：表明一个行为得以发生，行为者首先需要有进行此行为的动机和操作此行为的能力。接着，如果他们有充足的动机和能力来施行既定行为，他们就会在被诱导触发时进行。
简而言之：
债务人逾期后完成还款 = （动机）具备还款意愿 + （实施能力）具备还款能力 + （被触发）收到外界通知还款
所以要想该笔案件中的债务人还款，催收员首先要能够联系到债务人，其次从2个方面提升债务人完成还款行为的可能性：
提升还款意愿：
保证其具备还款能力：平台不可能提高债务人的经济能力，所以为了保证其能还清欠款中的本金+利息+滞纳金
近几年疫情，大量中小个体户被迫关停，导致部分人失业，间接影响了部分借款人的还款能力，导致整个信贷行业的贷后逾期率开始攀升，债务人群体也越发庞大。在庞大的债务人中，大部分人一旦出现逾期，在没有外部压力介入的情况下，是会迅速丧失掉整个还款意愿的，此时债务人为了避免烦人的催收，最直接的躲避方式就是本人失联。
正如福格行为模型所述：债务人还款的行为务必需要触发条件，即催收员得能够通知到债务人进行还款。那么如何获取到更多的联系方式能够触达到债务人，是催收员的基本需求。
当联系到债务人之后，整个催收才刚刚开始。由于债务人因为各式各样的原因出现逾期，催收员需要尽可能的了解逾期原因，是因为缺乏还款意愿，还是不具备还款能力，然后针对逾期原因进行运用相关的处理手段。那么这些手段如何更方便迅速的实施，是催收员更高的期望。
随着案件账龄的逐步攀升，催回难度也会逐渐提升，需要有更专业的催收员去匹配不同难度的案件进行催收。例如初级催收员，对于高账龄例如逾期4个月以上的 ，是很难回收案件金额的。
而案件的催收周期通常是固定N个月周期，那么如何在案件的委托周期内，把更多的案件实现催回。在于精细化进行案件分配。
所以，如何区分催收团队的组员专业能力，并为其匹配更适合其能力的案件，是策略运营经理的基本诉求，同时能够结合金额与数据将同类案件均分到同组催收员下。
除此之外，信贷领域的债务人出现逾期，往往并非只是在某一个平台发生逾期，可能债务人同时在多个贷款平台同时借款并发生逾期，这也意味着，当催收团队接收到某个委托方对债务人进行催收时，意味着债务人可能同时被其他家的催收团队进行催收。
如何保证催收员能够在一定周期内，抢先其他同行完成案件金额回收，是催收运营人员更高的期望。
为了维持团队的持续生存，管理层必须要考虑的收益与成本；
提升收益的方向除了在案件回收更多的金额，往往需要通过商务层与对案件委托方洽谈，将回收金额的结佣比例尽可能谈高，但由于行业内的不同账龄段基本结佣比例相对透明，所以此处收益很难有提升空间；
那么内部管理可控的就是成本降低，抛开商务接洽，获取委托方的案件委托，整个催收团队运营的核心成本在2点：
那么如何在保持案件回收率的前提下，让更少的催收员进行作业，或者作业过程产生的费用相对更少是团队管理层的需求。
例如：在债务人群体中，逾期不到N天的部分群体（天数较小，例如3天），行业内称为“缓催人群”，这部分群体可能是忘记还款或是其他原因，他们的还款意愿相对逾期账龄高的债务人更高，完全可以通过语音机器人或自动发送短信提醒还款，债务人即可主动完成还款行为，无需人力介入，那么这类群体，就可以通过自动化催收实现欠款催回。
除了考虑收益与成本问题，上游委托方也会给团队提出一些要求，比如周期内因为催收产生的客诉率必须在N%之内，这就要求团队在作业过程中，尽量避免客户出现投诉。
在这种情况下，团队对催收员提出降低客诉要求，例如债务人逾期前几天内，团队不允许拨打其联系人或单位电话，然而这实际上是与催收员通过高强度施压债务人，达成回款的诉求是相悖的，但此时客诉率指标悬在团队头上，如何保证催收员按照团队规定执行进行催收，降低客诉风险是团队管理层的期望。
当我们理解了整个业务模式中各个角色遇到的问题和诉求，对于系统搭建就有了清晰的方向。
随着业务流程的理解和各个角色的需求明确清晰，系统可以开始整个方案的设计了。
催收系统的存在就是为了更好的支持催收业务运转（除法诉之外）；
当定位明确后，我们才能明确好系统的信息边界；例如系统订单池范围，限于逾期过的订单，同时随着定位的明确，系统未来能做什么，不应该做什么，也相对明确了，这样能保证系统与外部系统的低耦合度，避免未来系统承载太多不应该承受的业务。
功能抽象的前提是基于业务诉求具象出对应基础功能点：
然后基于具象出来的基础功能点，抽象到模块：
一个完整的系统除了功能模块作为单元，还需要信息的组成；
系统的功能，本质也是对信息进行了操作，变更了信息的含义；例如：案件分配，就是对案件的归属权进行了变更。
那么当我们通过拆分业务流程，明确了系统中各个业务角色需要的功能后，我们还需要整理出系统内的信息单元，例如催收系统的基础信息单元如下图：
当我们确认了系统内部的信息单元，业务人员通过功能操作信息流转，线下的业务才算真正在线上系统上有了完整含义的体现。
当催收系统的信息单元与功能都确定后，我们在将功能与信息单元结合，形成信息流转，此时一个完整的法催系统架构就形成了，它即体现了系统内部的功能结构，也通过信息流转直观的表达了业务含义。
目前信贷行业整体资产质量有严重的下滑趋势，虽然不良资产的市场容量与需求足够大，但国家已经在针对传统的高压催收方式进行管控，同时近年调整的《个人信息保护法》也强调了金融平台对个人信息的获取限制，用户在借款时未填写的联系方式，催收团队不可通过非法信息修复手段，获取债务人并未主动提供的联系信息。
正如知识图谱，原本可以通过多节点可视化，帮助催收员发现债务人关联的联系人来增加债务人可联几率，在合规压力下，也不能在助力业务提升可联率。
未来催收会逐步轻化现有的传统自有团队电话与上门催收方式，逐步转移到人民调解和法院诉讼上，但催收作为金融信贷的最后一道管卡，会持续存在。
作者：橙言，互金风控产品经理；公众号：橙言（ChenYan_515）
本文由 @橙言 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。