行业资讯

小贷公司管理系统怎么选?

2026-10-16助销云运营团队16 次阅读

小额贷款公司选系统,和一般企业选 CRM 的逻辑完全不同。一般企业选 CRM,判断标准是"好不好用、能不能提升效率";小贷公司选系统,第一个判断标准是这套系统能不能支撑合规经营——因为监管文件已经把信息系统本身写成了经营要求,而不是可选项。

《小额贷款公司监督管理暂行办法》(金规〔2024〕26 号,2024 年 12 月 31 日印发,自印发之日起施行,共 7 章 60 条)里有一条很明确的表述:小额贷款公司应当加强信息化建设,建设业务管理、财务管理等信息系统,将各业务环节纳入信息系统管理,并加强网络安全、数据安全、业务连续性和信息科技外包管理,贯彻落实国家网络安全等级保护制度,开展网络安全定级备案、定期开展等级保护测评。对网络小额贷款公司,办法的要求更具体:使用的互联网业务信息系统应当能支持贷款申请、评估、审批、签约、放款、还款等业务全流程线上操作,能够完整记录并妥善保存相关数据及资料,网络安全等级保护定级不低于第三级。

这段话决定了小贷公司选系统的底层框架:先看合规能不能覆盖,再看功能够不够用,最后才比价格。这篇文章按这个顺序展开,讲六项硬指标——每项的监管依据、系统里的具体落点、以及选型时怎么验证。文末给出一份可以直接拿去问厂商的问题清单。文中引用的条款均来自公开的监管文件,会标注章条性质。

一、先认清一件事:小贷公司的系统是有"监管红线"的

与助贷机构、贷款中介不同,小贷公司是持牌的地方金融组织——公开办法的定义是"在中华人民共和国境内依法设立的,不吸收公众存款,主要经营小额贷款业务的地方金融组织"。这个身份带来两层约束:一层是业务层面的监管指标,一层是系统层面的技术要求。

小贷公司选系统的三层判断框架:监管合规层、业务能力层、成本服务层,以及每层的关键检查项
图 1 选型的三层判断框架。顺序不能反:合规层不达标,功能再多也不能用;功能层不匹配,合规做完了也跑不动业务。

监管指标这一层,公开办法给出了几个具体数字,它们会直接变成系统里的校验规则:

  • 集中度:对同一借款人的各项贷款余额不得超过其上年末净资产的百分之十;对同一借款人及其关联方的各项贷款余额不得超过其上年末净资产的百分之十五。
  • 单户上限(仅网络小贷):对单户用于消费的贷款余额不得超过人民币二十万元,对单户用于生产经营的各项贷款余额不得超过人民币一千万元。
  • 关联方贷款:对其股东及股东关联方的贷款余额不得超过该股东入股金额。
  • 融资杠杆:通过银行借款、股东借款等非标准化形式融入资金的余额不得超过其上年末净资产的一倍;通过发行债券、资产证券化产品等标准化形式融入资金的余额不得超过上年末净资产的四倍。这就是行业里常说的"1+4"。

还有一条容易被忽略但影响很大的经营约束:小额贷款公司应当立足当地,在经依法批准的区域范围内开展业务,不得跨省、自治区、直辖市开展业务(跨地市展业的条件由省级地方金融管理机构规定)。这意味着系统里的客户归属地、业务发生地不是统计字段,而是准入校验项。

另外,从行业整体看,公开数据显示截至 2024 年 9 月末全国共有小额贷款公司 5385 家、贷款余额 7514 亿元,相比 2014 年 9 月末十年间公司数量减少了约 3200 家。行业在收缩,意味着选系统的试错成本比过去更高——换一次系统的代价,对很多机构来说是一次伤筋动骨的迁移。

二、硬指标一:监管指标能不能做成"运行时校验"

这是最能区分"真系统"和"套壳系统"的一项。

把前面那些数字抄进系统手册不算本事,真正的差别在于:这些指标是在放款前拦住的,还是在事后报表里发现的。

六项需要做成运行时校验的指标

监管指标的两级实现方式对比:事后报表统计与放款前实时拦截,以及六项需要做成运行时校验的指标
图 2 同一组指标,两种实现方式的差别。左边是"事后发现",右边是"事前拦住"——后者需要在业务流程的放款节点设置硬校验。
  • 集中度必须实时算。同一借款人的贷款余额是动态的——他可能有在途的、已放款的、本期还款后减少的。系统需要能随时算出"这个人现在的余额是多少",并在新的放款申请提交时用上年末净资产这个基数去校验。这里有个设计细节:基数用的是"上年末净资产",而不是实时净资产,因此系统必须支持净资产基数按年切换并保留历史基数——否则跨年时所有校验都会算错。
  • 关联方要能识别。"同一借款人及其关联方"这一条要求系统有关联方关系表,而不是靠人工判断。关联方数据从哪来?股东名册、企业公示信息、客户申报,三者都要能录入并标注来源。这也是信贷客户管理系统怎么设计里"关联关系层"存在的意义。
  • 单户上限要区分产品类型。消费类与生产经营类的上限不同(20 万与 1000 万),因此系统里的贷款产品必须带类型标记,且这个标记不能被随意修改——否则改一个字段就能绕过上限校验。
  • 杠杆指标要能盯住资金端。非标融资与标准化融资各有上限,且倍数不同。系统需要维护融资台账:每一笔融入资金的来源、形式(银行借款/股东借款/债券/ABS)、余额、到期日。这个台账与业务侧的放款能力是联动的——融到多少,决定能放多少。
  • 区域限制要落到客户建档。既然不能跨省展业,那么客户建档时就应该有省域字段并做准入判断,而不是等到业务做完了再去整改。
  • 关联交易要单独管。办法要求关联交易"不优于对非关联方同类交易条件",重大关联交易需经股东会或董事会批准,且与关联交易存在关联关系的股东、董事不得参与该笔交易表决。系统层面的对应物是:关联交易单独标记、审批路径区分、表决回避记录。

验证方法很直接:让厂商当场演示一次"超限拦截"——用一笔会导致集中度超限的放款申请,看系统是在提交时就拒绝并在界面上说明原因,还是要等到月底出报表才发现。这个动作能立刻筛掉大部分不达标的系统。

三、硬指标二:放贷专户的钱能不能对得上

公开办法对资金管理的要求写得很细:小额贷款公司应当强化资金管理,对放贷资金实施专户管理,所有放贷资金必须进入放贷专户,所有贷款发放和本息回收必须通过放贷专户;应当向地方金融管理机构报备放贷专户,并按要求定期提供放贷专户运营报告和开户银行出具的放贷专户资金流水明细。同时明确禁止:不得利用股东、董事、监事、高级管理人员、内部职工、关联人员个人账户发放和回收贷款。

这三句话对系统设计有很强的约束:

  • 每一笔放款和回款都要能对应到专户流水。也就是说,业务系统里的放款记录、还款记录,与银行流水的记录必须是可逐笔核对的。这就要求系统里存有银行流水号或对账标识,而不是只有一个金额和日期。
  • 资金通道要受限制。"不得利用个人账户发放和回收贷款"意味着系统里不应该存在"用哪个账户放款"这个自由选项——正确的做法是把收款账户固定为已报备的专户,其他账户在系统层面不可选。
  • 专户运营报告要能生成。这类报告的数据来源必须是业务库的原始记录,而不是人工汇总。如果报告需要财务人员每个月手工整理,就说明系统的资金数据没有结构化。

对于需要按比例分账、按实收利息支付合作费用的场景,专户数据还会影响结算:结算进度应当与本金收回进度相匹配,而"本金收回进度"的权威来源就是专户流水。相关规则设计见助贷佣金结算系统怎么做与助贷分佣管理怎么做。

四、硬指标三:不良认定不能自定义

公开办法有一条定量规定:小额贷款公司应当建立健全资产风险分类制度和风险准备金制度,并将逾期超过九十天的贷款划分为不良贷款。同时要求及时足额计提风险准备。

这条规定对系统设计的影响是决定性的,因为"90 天"是一条硬线:

  • 分类必须自动计算。逾期天数要从还款计划与实际回款记录的差额里算出来,而不是靠人工登记。系统需要每天跑一次分类计算,把逾期超过 90 天的贷款自动置为不良。
  • 手工调整要有方向限制。行业内通用的五级分类是正常、关注、次级、可疑、损失,系统通常提供"自动分类 + 手工调整"两种方式。关键是:手工调整不能把已超过 90 天的贷款调回正常。如果系统允许这么做,那它就在事实上提供了规避监管的工具。选型时要专门确认这一点。
  • 分类变更要留痕。每一次分类调整都要记录操作人、时间、依据。这也是助贷贷后管理怎么做里强调"分类不是枚举字段"的原因。
  • 风险准备金要有计算依据。计提比例通常与分类结果挂钩,因此分类数据的准确性直接决定准备金数字。系统至少要能按分类维度输出余额明细。

五、硬指标四:监管报送能不能自动出

这是选型时最容易被当成"附加功能"、实际却最耗人力的一项。公开的系统方案普遍把报表能力作为核心模块,常见分类包括:监管上报类、客户统计类、贷前风控类、业务统计类、财报类、抵质押物统计类。

判断标准不是"支不支持导出 Excel",而是三件事:

  • 数据来源是不是业务库原始数据。如果报表需要业务人员先手工整理一张底表再导入系统,那它只是把线下工作量搬到了系统里。真正的报送能力是"点一下生成"。
  • 口径能不能锁定。同一个"贷款余额",在日报、月报、监管报表里的口径可能不同(是否含在途、是否含已核销)。系统需要能把口径写成规则,而不是每次由人判断。
  • 改动会不会断链。业务字段改名、产品类型新增,会不会导致历史报表算不出来?这是长期使用后才会暴露的问题,选型时可以通过问"字段变更后历史报表怎么处理"来试探厂商的设计成熟度。

六、硬指标五:合作机构名单制与业务边界

公开办法专设一条要求:小额贷款公司应当加强对合作机构的名单制管理,建立覆盖各类合作机构的统一准入机制,明确相应标准和程序;应当确保合作机构的网站、APP、小程序等经过依法备案;应当及时识别、评估因合作机构违法违规可能导致的风险。办法还明确了合作机构的范围:营销获客、出资发放贷款、支付结算、风险分担、信息科技、逾期清收等各方面开展合作的各类机构。

与此同时,对合作业务本身也有明确边界,包括:不得将授信审查、风险控制等核心业务外包;不得与无放贷业务资质的机构共同出资发放贷款;不得与不具备相应资质的机构合作接受其融资担保或保险服务;不得帮助合作机构规避异地经营等监管规定;不得仅提供不实际出资的营销获客、客户信用画像和风险评估、信息科技支持、逾期清收等服务;与商业银行联合发放的网络贷款,单笔出资比例不得低于百分之三十。

这组要求落到系统上,需要三类能力:

  • 合作方档案要按合作类型分类。营销获客的合作方和出资发放贷款的合作方,适用的规则完全不同。用一张表加一个"合作类型"字段勉强可行,但更稳妥的是在合作方档案里保留"合作事项清单"这个子表。
  • 名单状态要带时间。与前面讨论过的名单制一样,这里的核心是"能证明业务发生时对方在名单内"。名单的准入记录、变更记录、退出记录都要保留。
  • 出资比例要可核算。与银行联合发放的贷款,单笔出资比例不低于 30%,这个比例需要系统能算出来并留痕。把出资比例做成人工填写的字段,就等于放弃了这项校验。

七、硬指标六:合同、年化利率与披露

合同相关的要求在小贷业务里密度最高,而且都能落到具体字段上。

  • 年化利率的口径是"全部成本"。公开办法要求:应当将其对借款人收取的所有利息、费用与贷款本金的比例计算为贷款年化利率,在借款合同中载明。如果存在合作机构收取助贷信息服务、担保增信等费用的,应当以书面形式向借款人如实、完整告知。这条要求的系统含义是:费用项必须穷举,不能留"其他费用"这样的自由填写口。这一点在银行中介系统需要哪些能力里也讨论过。
  • 不得预扣。办法明确:应当按照借款合同约定金额,足额向借款人支付贷款本金,不得先行扣除利息、手续费、管理费、保证金等。因此系统里的"合同金额"与"实际到账金额"必须是两个独立字段,且放款金额校验要能发现两者不一致的情况。
  • 强制阅读要可验证。办法要求遵循公开透明原则,充分履行告知义务,将强制阅读合同作为合同签署的前置环节,并在合同中以醒目形式载明涉及消费者利益的内容。这条要求落到系统上就是:签署前必须有阅读确认记录(阅读时长、滚动到底、确认动作),而不能只有一个"我已阅读"的勾选框——勾选框无法证明"阅读"这件事发生过。
  • 公示与报备要有时效。办法要求对通过经营场所、宣传资料、网站、APP、小程序开展营销获客或发布、发放贷款的信息进行全面公示;通过互联网平台开展相关业务的应向地方金融管理机构报备平台信息及产品详细信息;公示信息发生变更的,应在变更后七个工作日内更新。系统层面需要的是公示内容的版本管理与更新时间记录。
  • 营销宣传有负面清单。办法列明了不得有的行为,包括以欺诈或引人误解的方式宣传、片面宣传低门槛低利率高额度诱导过度负债与多头借贷、将贷款列为默认支付选项、违反借款人意愿搭售等。这些条款主要约束话术与页面,但系统里的营销素材库与话术模板也应该按这份清单做审核标记。

八、选型时直接问厂商的六个问题

问题比功能清单更有效,因为它们很难用话术绕过去。下面是六个问题与对应的回答判断。

小贷公司管理系统选型的六个问题与合格回答、需要警惕的回答对照
图 3 六个问题与两类回答的对照。每一个问题都可以要求当场演示或出示实物,而不是听解释。

逐一说明每个问题的判断点

  • 第一个:集中度超限时,系统在哪个环节拦住?正确答案是在放款申请提交时实时校验并给出具体超限原因。如果回答是"报表里能看出来",说明没有做运行时校验。
  • 第二个:净资产基数怎么跨年切换?这道题测的是厂商有没有真正做过小贷业务——基数用"上年末净资产",跨年就要换基数,还要保留历史基数用于回溯校验。答不上来的,基本可以判断是套壳产品。
  • 第三个:逾期超过 90 天的贷款,手工分类能不能调回正常?正确答案是不能,或者至少需要强审批并留痕。允许随意调回的,等于提供了规避监管的通道。
  • 第四个:放款记录的收款账户能不能自由选择?正确答案是只能选已报备的专户,其他账户不可选。
  • 第五个:监管报表是"点一下生成"还是要先导底表?正确答案是前者,且需要演示一份具体的监管报表生成过程。
  • 第六个:等保测评做过吗,定级多少?如果是网络小额贷款公司,公开办法要求业务系统网络安全等级保护定级不低于第三级。这个问题的答案是可以核验的——定级备案和测评报告都是实物。这一条尤其适合用来淘汰那些"我们也能做"的口头承诺。私有化部署与 SaaS 在这个问题上的责任划分不同,可参考私有化部署和SaaS哪个好。

九、常见问题

助贷机构需要按小贷公司的标准选系统吗?不需要照搬,但需要知道哪些要求与自己相关。助贷机构不持小贷牌照,因此不受集中度、杠杆倍数这类指标约束;但涉及客户信息处理、催收行为规范、费用披露这些方面,如果业务与持牌机构合作,就会通过合作协议传导过来。务实做法是把与协作有关的那些能力做齐。相关讨论见金融居间CRM与普通CRM的差异。

系统能不能自己建?可以,但要把成本算全。公开办法要求把各业务环节纳入信息系统管理,还要做等保定级备案、定期测评、数据安全与业务连续性管理。自建的真实成本不只是开发,还包括后续的合规测评、安全运维与持续迭代。选型时这笔账要一起算。

五级分类是自动还是手工?通常是自动为主、手工调整为辅。判断系统是否合格的标准不是"能不能手工调",而是"手工调的边界在哪里"——超过 90 天不能调回正常,调整必须留痕,这两个是底线。分类的具体设计见信贷客户管理系统怎么设计。

厂商报价怎么看?先统一口径再比。同样叫"系统费用",可能一个含实施与迁移、一个不含;可能按主体授权、可能按账号数;可能首年便宜、续费涨幅另算。要问清的第一年总费用、次年费用区间、实施范围、以及后续的接口开发是否单独计价。费用结构的完整拆解见助贷CRM收费标准。

十、小结

  • 小贷公司选系统是合规优先。公开办法已经把"将各业务环节纳入信息系统管理""全流程线上操作""完整记录并妥善保存数据""等保定级不低于三级"写成了经营要求,因此系统能力本身就是合规能力。
  • 六项硬指标:① 监管指标做成运行时校验(集中度 10%/15%、网络小贷单户 20 万/1000 万、股东贷款不超过入股金额、杠杆 1+4、不得跨省展业);② 放贷专户与业务流水逐笔可对应;③ 逾期 90 天认定为不良且分类不能自定义;④ 监管报送能一键生成;⑤ 合作机构名单制与合作业务边界(不得外包核心风控、与银行联合发放出资不低于 30%);⑥ 年化利率含全部费用、不得预扣、强制阅读可验证、公示与报备有时效。
  • 选型的方法是验证而不是听介绍。让厂商当场演示超限拦截、净资产基数跨年切换、专户账户限制、报表生成,以及出示等保定级备案与测评报告。
  • 顺序不能反。先合规达标,再功能匹配,最后比价格。反过来做,往往在第二年续费或第一次检查时付出更大代价。

最后给一个自检:一套小贷公司管理系统值不值得选,可以问五件事——超限的放款能不能在提交时被拦住、净资产基数跨年怎么换、收款账户能不能改成非专户、超过 90 天的贷款能不能调回正常、监管报表要不要先手工做底表。五个问题都有明确且可验证的答案,选型就基本清楚了;有两个以上含糊,先别急着签合同。

这套判断与信贷业务的整体设计是同一套逻辑,可以接着看信贷客户管理系统怎么设计、银行中介系统需要哪些能力与助贷贷后管理怎么做。涉及权限与客户资源保护的部分,见助贷CRM权限怎么分级与助贷进件管理系统怎么做。

—— END ——|本文由助销云运营团队发布,禁止转载