这两年有着越来越多的传统银行，正在探索实践开展线上信贷业务（也称互联网信贷业务），包括整个流程为纯线上的信贷业务以及入口端部分获客流程是与线下场景相结合的信贷业务。

不管是哪一类的线上信贷业务，强调的都是客户体验。因此都是采纳客户自助线上操作以及后续尽可能系统自动化流程的模式。客户自助操作发起的任何请求，对于后台系统来说则都是一次某种意义下的业务进件（一般也称为申请进件），而自动化流程的关键就是对于各种类型的申请进件进行数据驱动下的决策，通常也叫做审批。

在这种模式下，对于业务进件的管理，其系统所拥有的功能精度和所提供的服务效率就显得十分重要。笔者特站在传统银行自动化审批决策的视角上，总结以往的经验，就这个问题的一些细节展开讨论。

线上信贷业务的特点及业务进件之复杂性

首先，不像是那几个有互联网基因的新成立的民营银行或几个带头探索走在市场前列的全国性或股份制大行，有着相对完整的自建的或基本上属于自控的线上信贷获客渠道，对于大多数开展线上信贷业务的普通的传统中小银行，基本上都没有属于自己的获客渠道或场景，都是需要通过与有获客能力的持牌金融机构开展联合贷款，或者直接与有良好纯线上或线下线上相结合的获客场景的互联网类平台开展合作并由合作方承担助贷导流一类的角色。这样的话，在客户线上发起自助申请后续的数字化审批则是依靠从合作方传递过来的业务进件和相关数据。

第二，大多数传统银行，存在互联网金融相关的技术人员和数据人员匮乏的问题，并且这个问题也一时半会无法解决。而进入线上信贷业务领域哪怕仅仅只是做一些业务尝试，对于培养人才规划业务转型与升级，也就是越早越好。在这种背景下，传统银行与渠道合作方的深度合作在所难免。这种深度合作就自然而然地产生了深度应用渠道方通过借款人申请场景获取及聚集的数据的需求，以及有时候还不得不被绑定了同时应用渠道方自己通过场景之外的第三方数据供应商所获取和整合的数据，以保证总体合作业务成本在合理水平。

第三，目前市场上在为传统银行提供获客导流助贷服务的平台也有很多家，其中的确有几家拥有自我闭环场景且流量充裕，但因其具有某种垄断性，广大传统银行在与其合作中始终处于商务方面的劣势地位。而进一步，监管层面也一再希望传统银行在选择获客导流的助贷服务时候，要把握好集中度。因此客观上传统银行也是希望同时与多家获客导流助贷平台合作。然而各家平台所涉及的场景数据和客户线上申请流程细节都各不相同，其结果也一定是对于银行来说线上信贷业务的业务进件和所涉流程与数据往往是五花八门。

第四，从提供获客导流助贷服务的合作平台来说，都是希望能够同时为多家提供信贷资金的金融机构开展合作。从希望通过助贷平台来获取信贷服务的借款人来说，也往往希望能够通过平台尝试多家金融机构以求得较高的最终通过率。因此，在目前尤其是传统中小银行与获客导流助贷平台的合作中，在借款人客户发起自助申请的界面上，很难见到从头到底几乎只属于一家合作银行专用的申请流程，而往往只是合作平台自己的申请流程然后在流程稍后端的某个节点再将客户分发并导入具体一家银行的嵌入在助贷合作平台前端的专用流程。

第五，监管层近两年一直在强调，商业银行与各类助贷机构开展互联网贷款业务的合作，必须做的风控不能外包。在这样的严监管要求下，即便是为商业银行提供获客导流助贷合作的各类平台自己也为了风险管理的目的做过一道筛选，商业银行必须要建立自身的二道风控流程或终审风控流程。在有条件的情况下，也是尽可能充分利用由合作平台提供的数据，结合合作平台的前端申请流程，完成银行自己的自动化或准自动化的风控审批流程。即使是对于不少能力不足的中小银行，也还是都要求先将业务进件所相关的数据先接入进来。这样的话，对于业务进件及其携带的数据，商业银行都需要落地到细化的层面。

第六，在自动化模式下的线上信贷业务的申请流程所提供给后台系统的业务进件，本来就随着线上信贷业务的不同产品、不同申请类型、不同自助操作环节和不同辅助数据的接入，有着很多的不同。可以有授信额度或单笔贷款资格申请、额度项下提款资格申请、放款验证申请、提前还款申请和提前终止额度申请等等。有的时候助贷平台的流程，还会出现预申请的流程。有些流程又会中间被折回前端合作平台并需要先完成某一个插入的操作才能继续等等。

总之可以看出，传统银行开展线上信贷业务，在业务进件及所携带入的数据方面，在业务进件的系统流程方面，比起传统的线下信贷业务来说，要复杂得很多。

进件管理与信贷管理主系统分离的理念

基于线上信贷业务在业务进件处理端的复杂性，尤其是所涉及的数据的多样性和流程的多样性，笔者一直认为在系统层面，进件管理所需的功能要与信贷业务管理所需的其他主要功能，尽可能在系统架构上分离开，并且业务进件管理自身能够成为一个完备的子系统或系统模块。

这里指的线上信贷业务管理的主要功能，是指包括额度账户管理、贷款账户管理、支用管理、放款回款管理、还款计划管理、利息罚息核算结算管理、逾期状态管理、授信和贷款合同管理、担保与理赔管理等一系列直接与每一笔贷款层面相关的管理功能。如果还有联合贷款业务的话，则可能还涉及到在每笔放款层面的后续与联合出资方的清算和对账等。部分线上信贷业务平台还可能包括征信上报管理的功能。

在传统线下模式下，客户来银行申请信贷服务，首先由客户经理负责进行一系列的线下审核步骤。当客户经理将客户的这笔借款需求录入系统时候，基本上是已经有了这笔申请最终会被审批通过的眉目。系统中录入的贷款申请最终依旧会作为拒绝记录留存下来的占比不高。贷款资格审批通过后的放款、提前还款和提前额度终止等客户需求，基本上也都是属于客户经理在系统中在客户贷款账户下面的一个操作而已，不存在数据和自动化流程方面的复杂性。

所以我国以往传统商业银行的个人信贷管理系统，通常是不需要有专门独立出来的针对信贷申请进件的管理模块。更也有个人信贷平台是将信贷客户的管理和催收的管理，都强耦合在一个系统框架内的。

不过以往在信用卡业务管理系统中，已有不少较大规模的商业银行，采用了将发卡系统和主卡系统分离的模式。这里的发卡系统其实就是一个独立的业务（申请）进件管理系统。因为在信用卡的业务中，多年前即便是尚未采用数据驱动自动化审批的模式，但已经采用了后台集中审批的模式，由此也造成了在审批环节，可以产生大量的申请进件被拒绝案例并将长期留存在系统中，而对于历史拒绝案例与原因的分析则对于标准化的风控框架是必不可少的。随着技术和理念的不断更新，也进一步建立了在发卡系统之上的以决策引擎为核心的自动化审批系统或称为风控系统，并且是以在发卡系统中的工作流程管理来驱动对风控系统的调用。

所以我们看到在今天的互联网信贷业务系统的解决方案中，不少解决方案就像是从信用卡业务系统解决方案中衍生出来的。不少线上信贷平台，就是将业务进件管理、贷款账务管理、智能化风控管理（审批决策管理）、外部大数据管理、互联网客户管理和催收管理等，都各自以独立的模块来设计和配置，从而形成一个完备的线上信贷业务平台。

而更进一步，为了满足商业银行更为有效地与各种外部场景相互结合，目前比较热门的开放平台，其实也可以理解为是我们这里所指的业务进件管理的一个强力提升。在开放平台上，银行所希望的是具备一套尽可能标准化的接口去对接众多的外部信贷场景。关于将业务进件的管理提升为开放平台，笔者在此不予展开。

但当我们回头来看国内传统银行，其中大多数是没有能力为了很快开展线上信贷业务的探索就去建设一整套完备的系统平台，不少传统银行还都是采纳从现有的系统群中尽可能去做一些改造和增添模块，或者还是摆脱不了传统个人信贷系统的思路来简单设计线上信贷的业务系统功能需求。同时，一些参与线上信贷业务系统建设的传统开发商，也都还习惯于只是在传统的业务逻辑和系统框架上进行改造。

随着市场上对于线上信贷业务的数字化风控和自动化审批的依赖性的普遍认可，现在绝大多数线上信贷平台已经实现了运用独立的决策引擎进行数字化风控策略及其模型的部署和决策，但一般传统银行还尚不能全力搭建完备的开放平台。因此，优化线上信贷业务场景申请进件的管理，则应该成为一项重要且现实可行的工作。

线上信贷业务进件管理系统的重心

笔者认为，线上信贷业务的业务进件管理系统的重心，应该就是配合和支持自动化决策的落实。业务进件管理系统将从客户申请端及合作渠道端传送过来的各种数据及其每个申请子流程的相关环节节点的状态信息予以整理好，并且在自身系统中设计和配置好业务工作流程的调用，为自动化审批决策系统进行风控决策和其他相关业务决策提供服务。

传统个人信贷系统中即使有的申请管理模块，因实质上的审批决策是靠人工在做的，故其主要作用往往就是为后续的贷款账户开立核算结算这些贷后业务主要功能提供信息过滤，所以一般也就结构不复杂。但是对于线上信贷业务的整个系统平台来说，业务进件管理这块对于后续的贷款主要管理功能所起到的衔接作用则要相对小于对于自动化审批决策所起到的衔接作用。

对于线上信贷业务来说，尤其是对于与多方获客导流渠道合作的线上信贷业务来说，其实贷款产品本身核心要素与传统信贷业务相比没有多大的不同，还就是围绕着诸如放款额、利率、期限、放款方式、还款频率与方式等等的参数配置，通过业务进件管理系统需要传递到贷款业务主系统去的参数不见得增加多少，并且也还基本上属于标准化的。而变化多的都是前端渠道的场景特性及其由此带来的客户特性，由此需要在自动化审批决策系统中使用的数据和信息增添不少，并且往往是五花八门非标准化的。

当然线上信贷业务的自动化审批决策在起作用的时候，也还是非常依赖于非申请发起渠道传送过来的数据，这个是今日线上信贷业务的特点，与传统信贷业务的管理系统很不一样。不过现在一般开展线上信贷业务的传统银行，基本上都已经有了独立的外部数据接入管理模块，并且与信贷业务主系统是分离的。进一步，个人征信的获取和解析也都是分离的。而比较容易受到疏忽的则是业务进件管理自身这一块。

线上信贷业务的文档保管存储也都是采用电子文档。对于与获客导流场景方合作的线上信贷业务，其电子文档也会是多种多样并且格式很不一致。这些文档中除了授信合同与贷款合同，还有比如贷款须知确认书、征信和第三方数据获取授权书、身份证及个人在借贷现场照片、个人持消费贷款对应消费购置产品或发票的照片、个人与消费场景分期贷款服务员的合影、借款人个人合规承诺视频录像、消费退货或撤销凭证等等，若业务有第三方的融资担保公司参与并提供保证保险的话，则还有诸如对应于每笔贷款层面的保证保险协议的电子文档等。所有这些既然都是电子文档，都是需要在贷款审核审批环节或贷款发放环节作为对照对比校验使用的，则都应该建立起相应的电子文档存储与索引功能。另外还有一点，所有上述这些电子文档的获取节点和传送节点，又也都是很不统一的。

一般地讲，除了授信合同和贷款合同，上述提到的其他各种各类的电子文档，都是在申请审批过程中使用的，与贷款业务管理的主系统功能则关联度不大，并且在线上信贷业务整体中，的确存在大量的业务申请进件最终并不能被批准通过从而最终不需要在系统中建立起相应的贷款账户。所以此时建立起独立的业务进件管理系统，则可以把这些附带的各种各类与申请审批相关的电子文档也一并管理起来，而让线上信贷业务的主系统模块专注于在每笔贷款批准发放后的综合管理。

独立的业务进件管理系统，除了直接支持审批决策系统的决策流程运行决策之外，还有一个重要作用，就是支持线上信贷业务对于申请进件和合作渠道综合状况的实时监控和历史分析。传统个人信贷系统在这方面是很弱的，一般现在银行拥有的综合监控系统还就是主要针对贷款产品层面的一些主要指标。而在开展有大量渠道合作方的线上信贷业务中，有很多细节点需要监控和分析，包括对于历史拒绝案例的分析都很重要。这些与申请进件直接相关的原始信息的积累和合理存储，最好是由业务进件管理系统来实现。

做好线上信贷业务进件管理的抓手

笔者认为，做好线上信贷业务进件管理的关键抓手是，对于线上信贷业务从前端发送过来的申请进件，做好其分层分类，重视和理顺各个单元之间的逻辑与流程关系。这里所指的前端包括在客户申请贷款时候所面对的线上自助界面，以及获客导流场景合作方的后台系统。

在业务进件管理系统中，要分别树立起申请过程流和申请进件流的概念，并将申请过程流和申请进件流与申请进件管理系统所负责的工作流以及审批决策系统所配置的决策流相互对应起来。申请过程流更多地是对应一个业务需求需要完成的整个业务流程，而申请进件流则更多地是指在系统中相对应的流程的概念。

对于线上信贷业务，不管其获客场景如何复杂，不管其贷款产品设计如何花样，对于由前端向信贷业务平台发起的各式各样的申请需求，就完成申请审批并最终可以传递到信贷业务主系统的角度来看，无非就是可分为额度申请（或单笔贷款申请）、额度项下提款申请、放款（验证）申请、提前还款申请和提前终止额度申请等。在不少场合，放款申请也是由单笔贷款申请或额度项下提款申请通过后直接触发的，不过在有诸如第三方担保公司参与的情况下，或有多家金融机构共同出资的联合贷款情况下，可能就需要多一步最终放款申请并由系统完成放款验证审批。

这里也注明一下，不是必须需要所有的申请进件的最终审批都是由架在申请进件管理系统上的审批决策系统来完成的，一些上线后一般不需要再去做调整相应决策规则的而只是简单判别极少数信息是与否的审批步骤，由业务进件管理系统自身的自动化工作流程中的程序直接判断往往更有效。但是我们在此解释整个相关的管理理念，则还是通过强调业务进件管理系统与审批决策系统之间的协作来解释。

然后一个申请进件流则是以由前端客户界面操作或合作方平台界面操作或合作方平台系统触发所发起的一个申请请求为起点，一直到由审批决策系统给出一个结论性的决策结果并返回前端或由前端通过异步查询获得决策结果为终点的一个连续性流程为一个单位。

如果由于在整个申请过程中前端需要做一些进一步的配合操作，则一个完整的申请过程流程也可能需要分拆成多个申请进件流来完成。在这种情况下往往有一个特点就是，前面一个申请进件流所获得的审批结果是拒绝或否定的话，则整个申请过程流程到此为止不会再继续下去。

由于数据调用和接口等等的原因，由于决策结论与外部数据调用成本之间的考虑，还由于目前的自动化审批中依旧会考虑穿插一些人工辅助的审核步骤，所以进入了申请管理系统后的一个申请进件流，也可能是对应于多个审批决策系统中的审批决策流，并且由申请管理系统的工作流管理功能来实现分派调用管理。

于是一个申请进件流的最终状态，则是在完成了所调用的多个审批决策流之后的最终状态。而一个申请过程流的最终状态，则是完成了所有申请进件流后的最终状态。

我们有必要要说明，其实申请过程流的最终状态亦可以区分为两种，一种是实际的最终状态，一种是我方的最终状态。因为在多方的合作过程中，一个申请过程流的最后一段申请进件流可能是在我方有了最终状态结果后的因为合作方继续需要做某项审批决策后的结果反馈，其实对于我方来说此时接下来并没有实质性的审批决策，而只是一个登记最多加个验证而已。

上述这种情况常常发生在我方审批通过后合作方继续做一次审批然后再进入放款。以笔者的经验来看，此时这个申请进件流可以不被看成是前面的贷款申请过程中余下的一个申请进件流，而看成是另外一个放款验证申请过程下的申请进件流。这样的区别就做到了在上一逻辑层面的分离。

既然我们讲到线上信贷申请进件管理系统的重心应该是支持（我方）的自动化审批决策，那么对于我方结果状态的关注要远比对于实际结果状态的关注来得重要。当然如果在上一逻辑层面就分离了的话，则也容易理解和处置。

总之，做好线上信贷业务进件管理，不要简单地将各种类型各个层级的申请进件及其相关信息捏在一起，搭建清晰的分层分类数据结构，则将非常有助于线上信贷业务的自动化审批决策及其后续的监控与分析，从而能够更有效地提升传统银行自主风控的基础能力。