消费金融的门槛核心在于风控系统，面向C端客群的线上产品线，如消费分期、现金贷及信用卡代偿等业务方向，其需实时支持大量业务的自动化处理，风控系统将承担贷前、贷中和贷后的风控评估、处理及预警的角色，极大地解放人工处理的瓶颈与效率。
风控规则
风控决策引擎是一堆风控规则的集合，通过不同的分支、层层规则的递进关系进行运算。而既然是组合的概念，则在这些规则中，以什么样的顺序与优先级执行便额外重要。
风控系统的作用在于识别绝对风控与标识相对风险，如果是绝对风控，则整套风控的审核结果便将是“拒绝”。既然结果必然是“拒绝”，则没必要运行完所有的风控规则，而主要单条触发“拒绝”即可停止剩余规则的校验。因为所有规则的运行，是需要大量的时间、金钱与性能成本的。
所以，整套风控决策引擎的搭建设计思路，基于规则优先级运算的注意要点如下：
（1）自有规则优先于外部规则运行
举例说明：自有本地的黑名单库优先于外部的黑名单数据源运行，如果触发自有本地的黑名单则风控结果可直接终止及输出“拒绝”结论。
（2）无成本或低成本的规则优先于高成本的规则运行
举例说明：借款用户的身份特定不符合风控要求的，诸如低于18岁的用户，则可优先运行。而一些通过对接外部三方征信的风控规则，需支出相关查询费用的，则靠后运行。此外，在外部三方征信的规则中，命中式收费的风控规则（如黑名单与反欺诈）又可以优先于每次查询式收费的风控规则（如征信报告）运行。
（3）消耗低性能的规则优先于高性能消耗的规则运行
举例说明：直接基于用户现有属性的数值，如当前用户的民族是否非少数民族，则可优先运行。而一些风控规则，需借助爬虫接口，且需待将爬取到的数据经过二次加工与汇合之后，再对汇合的总值进行判断，如手机运营商账单中的月总通话分钟时长，则此类风控规则应后置运行。
风控可调整
风控的核心思路是基于大量真实的样本数据，将逾期用户的身份、行为与数据特征进行提炼，从概率学的角度上进行剔除，从而保障到剩余用户群的逾期概率处于一个相对较低的区间。
而对数据的提炼与作用过程，将使用到“参数”的定义。“参数”决定了区间和上下限范围，一条风控规则通常作用于某一数据类型，依据此数值是否满足“参数”的定义范围，得出是否可通过风控的结论。
由于风控最终还是数据“喂出来”的结果，而非主观臆断的设限，故而，随着数据样本与内容的不断发展，必然将会涉及到一些动态的调整，后期可能会发现原本设定的“参数”过于严谨而导致审核通过较低，或者是设定得过于宽松而导致逾期率较高等。
所以，整个风控决策引擎的搭建设计思路，基于可调整与可维护的注意要点如下：
（1）非刚需与必要的风控规则，能够“开关化”
举例说明：一些必要的风控规则，如用户的银行4要素验证是否一致性，这是必要规则，就无需可开关。而一些如校验用户的芝麻信用分是否高于500分，则可做成“开关”。待该规则上线后，可通过分析此项规则的触发率得出是否合理的判断。因为芝麻信用分是否可作为决策依据将主要取决于业务方向与用户群体，因为理论上芝麻信用分的高低主要与用户在芝麻信用体系内的数据绑定维度的多与少相关，并不一定绝对反映用户的信用程度。
举例说明：很多风控体系通常会加入对手机运营商的校验，所以有一些风控规则，诸如校验用户手机号的使用时间长度是否大于6个月。其中的“6个月”便是所定义的参数，此处最好可调整与配置。因为去验证用户的稳定性，是否用“6个月”，还是用“3个月”的长度更合适？
具体合理的参数是需要通过数据分析的结论进行得出，如果由于定义“6个月”长度的要求而发现其他一些手机使用时长虽然短一些，并未与用户是否逾期形成直接必然因素，那么可将该参数放松调整到“3个月”。
风控最终到底是“跑出来”的，所以，整个风控系统对所有不同风控规则的触发需进行有效的记录与统计，以便后期可支持数据分析与风控模型调整的相关工作。
具体的记录与统计内容如下：
举例说明：通过两种不同的视角进行记录，一是用户与订单层面，记录其所触发的明细规则；二是风控规则层面，记录某条风控规则具体的触发率。例如接了多家三方征信的反欺诈服务，通过比对这几家的触发效果，将反欺诈触发率较高的风控规则可前置执行。
