助贷新规讲了什么？四条要求落到助贷机构的系统上

助贷新规施行满一年，变化最直观地写在银行的合作名单上：吉林亿联银行的导流获客合作机构从 2024 年 11 月的 56 家降到 2026 年 7 月的 10 家；兰州银行在 2026 年 7 月更新的名单里，把 12 家营销获客平台和 13 家融资担保公司的合作状态一次性改为「停止合作」；上海华瑞银行从 85 家降到 65 家。名单在缩短，这是能看见的那一半。看不见的那一半是：留下来的每一家，被要求随时能拿出的东西，比一年前多得多。

这篇文章不解读政策，也不预测监管走向，只做一件事——把助贷新规的四条要求，逐条翻译成「系统里要有什么字段、什么记录、什么动作」，以及被检查的时候，你手上要能拿出什么。政策条文解决的是「应该怎么做」，机构真正卡住的地方是「怎么证明我做了」。这两件事之间隔着一层数据结构。

一、助贷新规讲了哪四条？先把文号和施行日对齐

把名称统一，是为了避免以后对不上账。业内说的「助贷新规」「9 号文」「9·30 新规」，指的是同一份文件：《国家金融监督管理总局关于加强商业银行互联网助贷业务管理 提升金融服务质效的通知》，文号金规〔2025〕9 号，2025 年 4 月发布，2025 年 10 月 1 日施行。

它的核心要求是四条：

第一条，名单制管理。商业银行对平台运营机构、增信服务机构实行名单制管理，在官网或 APP 公示并更新，不得与名单外机构合作，名单由总行统一管控。

第二条，综合融资成本上限。借款人单笔贷款的综合融资成本不超过 24%，与司法保护上限对齐。关键词是「综合」——不是利息不超过 24%，是利息加上各项费用之后的总成本不超过 24%。

第三条，平台不得直接收费。平台运营机构不得以任何形式向借款人直接收取息费，会员费、服务费、担保费等各种名目的费用，一律计入综合融资成本。

第四条，风控不得外包。银行承担全流程风控主体责任，核心授信环节不得外包。

这一年里还有两个配套文件需要一并知道，因为它们决定了「留痕」要留到什么颗粒度：2026 年 3 月发布的《个人贷款业务明示综合融资成本规定》，2026 年 8 月 1 日施行，要求把息费逐项折算年化并明示；2026 年 9 月 30 日施行的《金融产品网络营销管理办法》（八部门联合发布），把「谁有资格卖、在哪卖、内容谁审、怎么留痕」纳入统一规则。前者管「算清楚」，后者管「说清楚」。两个都指向同一件事：记录要能调出来。

这里必须说清边界：本文只陈述公开的文件要求，不评价具体业务的合规性，也不对监管后续动作做任何推断。机构自己的合规判断，应当由法务或外部专业机构出具。我们只谈一件事——这四条要求，落到一套管理系统里，是什么样子。

二、名单制：合作机构档案至少要能停用、能到期提醒

名单制听起来是银行的事——名单由银行公示，机构在不在名单里由银行决定。但对助贷机构来说，这件事会立刻变成一个内部管理问题：你怎么知道自己在不在名单里？你怎么知道自己合作的每一家资金方、每一家增信机构，当前是什么状态？

现实中出问题的场景往往是这样的：某家合作机构的资质在几个月前被撤销，业务员不知情，照旧把客户往那条通道推，材料收了、征信查了、客户等了两个星期，最后被告知通道停了。客户流失是小事，这段时间里产生的客户信息处理行为怎么解释，是大事。

所以名单制落到系统上，第一件事不是「加一个名单字段」，而是建一份能维护、能停用、能提醒的合作机构档案。这份档案至少要有七个字段：机构全称（不是简称）、分支机构、业务类型、对接联系人、当前状态（合作中／暂停／终止）、成本口径、最近一次资质核对日期。

我们自己的生产库里，对应的是 channels 这张表，字段是齐的：financial_org（机构名称）、branch_name（分支机构）、business_type（业务类型）、contacts（联系人，JSON）、status（状态位）、cost_type 与 cost_value（成本口径）、approval_amount、customer_count、loan_amount、repayment_amount 等经营统计字段。但截至 2026 年 10 月 18 日，这张表里只有 3 条记录，全部为测试数据（中国银行、招商银行深圳分行等）。

这个「3 条」值得多说一句。它说明的不是系统缺字段，而是「维护档案」这个动作没有被当真。字段和表单是可交付的，维护是每天要花时间的。名单制的第一道坎从来不在技术侧，而在「谁负责更新、多久核一次、停用之后新进件会不会被立刻阻断」这三件事上。如果停用一个状态位之后，业务员还能在那个通道上建进件，那这份档案就只是一张好看的表格。

检查时你要能拿出的东西很具体：一张导出表，含机构全称、当前状态、最近核对日期，以及每家机构名下的在途笔数。能在一分钟内导出这张表，说明档案是活的；导不出来，或者导出来发现最近核对日期全是空的，说明它只是上线那天填过一次。银行中介系统需要哪些能力那篇把名单制的准入与退出机制拆得更细，可以对照着看。

三、24% 综合融资成本：费用要能汇总到「这一笔」

第二条是最容易被误读的一条。很多机构的内部口径是「利息不超过 24% 就行」，然后服务费、担保费、账户管理费另算。但条文说的是「综合融资成本」，这几个字决定了所有费用必须能加总到同一笔业务上。不能加总，就无法自证。

要能加总，数据结构上必须有三层，缺一层就散：

第一层，业务笔。一个客户在同一家资金方的一次申请，算一笔。注意是「笔」不是「户」——同一个客户今年报了三家，是三笔，不是一笔。这一层很多机构是有的，就是进件记录。

第二层，费用明细行。每一笔业务下面挂若干条费用行，每条费用行至少五个字段：费用科目、金额、收取主体、收取时点、关联业务笔号。费用科目要能细分（利息／服务费／担保费／其他），收取主体要落到具体的法人主体，不能只写「平台」。

第三层，汇总口径。把某一笔下面所有费用行按统一口径折算加总，得出一笔业务的综合成本。这一层决定了你能不能在被问到的时候，把「这笔到底收了多少」一次性说清。

我们生产库里的实际情况可以直接作为对照：filings（进件）表有 10 条记录，字段包括 pre_approval_amount、repayment_amount、repayment_count、current_status、approval_status；channels 表有 cost_type 和 cost_value，记的是机构付给渠道的成本。也就是说：成本口径有，但那是「我方付出去的钱」；向借款人收取的费用明细，目前没有独立的表去承载。

这个缺口不是技术难题，是设计顺序问题。多数系统是先做「业务跑通」，费用记在合同附件和 Excel 里；等要自证的时候才发现，Excel 是按月按人汇总的，跟具体的业务笔对不上。对不上的账，在检查现场就等于没有。

还有一个细节常被漏掉：跨期费用的归属。同一笔业务，服务费分两次收，第一次在本季度、第二次在下个季度，费用的归属期要不要跟着收款的时点走？如果系统里只有「金额」一个字段、没有「收取时点」，这个问题永远算不清。所以第二层的五个字段里，收取时点是必须的，不是可选的。

四、不得直接收费：把「谁收钱」和「收什么钱」拆成两个字段

第三条看起来最简单——平台不能向借款人直接收费。但落到系统设计上，它要求把一件在现实中被揉在一起的事，拆成两个独立字段：收费主体（谁收）和费用科目（收什么）。

为什么必须拆开？因为同一笔钱，收取主体不同，计入综合融资成本的方式就不同，能不能收也不同。如果系统里只有一个「服务费 3000 元」的字段，你无法回答「这 3000 是谁收的」，也就无法判断它该不该出现在这张账单上。

我们见过三种典型的错法，都是字段设计不足导致的：

错法一，费用挂在平台公司名下。合同是资金方的，钱进了平台公司的账。系统里这笔费用记在「服务费」科目下，没有主体字段，事后没人说得清这是谁的收费权。

错法二，会员费与具体业务笔脱钩。客户先买了一个年度会员，之后才办业务。系统里会员费是一笔独立的收入，没有关联到任何业务笔上。等到要算这笔业务的综合成本时，会员费该不该摊进来、怎么摊，没有依据。

错法三，担保费由担保公司收，但合同在平台签。这三方关系在系统里如果只有一条记录，就永远理不清责任链。

正确的做法是让每条费用行都回答四个问题：谁收、收什么、多少钱、对应哪一笔。四个问题都能答，费用结构就是清楚的；有一个答不上来，这笔账在检查时就是模糊的。

顺带说一句，这套结构和「回款台账」是同一套骨架。进件管理的全流程节点那篇讲过「一个客户对应多条并发进件」的数据结构，费用行就是挂在这个结构下面的。签单与放款怎么线上化里提到的合同一致性校验，也依赖同一个业务笔号把合同、费用、回款串起来。骨架建对了，后面加什么都是挂件；骨架没建对，每加一个需求就要改一次表。

五、风控不外包：进件与尽调的「留痕密度」怎么算

第四条要求银行承担全流程风控主体责任、核心授信环节不得外包。对助贷机构来说，这句话的落点不在「谁审批」，而在「你交上去的材料和过程，能不能证明你做了什么」。银行不会因为你说「我们审过了」就认可，它要的是过程记录。

这里引入一个可以量化的指标：留痕密度——一条业务从建单到结案，产生了多少条状态变更和审批记录。这个数字可以直接从库里算出来，比任何制度文件都诚实。

以我们生产库 2026 年 10 月 18 日的快照为例：filings（进件）10 条，filing_status_logs（进件状态日志）59 条，filing_approval_records（进件审批记录）50 条。三个数字一除：平均每条进件有 5.9 条状态变更、5.0 条审批记录。

5.9 和 5.0 这两个数字，比「我们有完整的审批流程」这句话有用得多。它意味着任取一笔进件，时间轴上至少有十来条记录可看：什么时候提交、材料什么时候补齐、退回过几次、谁批的、什么时候到下一节点。

反过来用这个指标也很有效。如果一条进件只有 1 到 2 条状态日志，说明系统只记了结果、没记过程——业务员直接在系统里把状态从「新建」改成「已签约」，中间的材料收集、资质核对、风险确认全部发生在系统之外（微信里、纸质上、口头中）。这种系统在内部管理上勉强能用，在需要自证的时候就完全使不上力，因为它连「做过」这件事都没有记录。

所以第四条落到系统上，具体是三件事：一是每个节点的状态变更必须由动作触发，不能由人手改；二是退回必须填原因，且原因要能分类统计；三是审批人必须是具体的账号，不能是「风控部」这种部门名。第三点最容易被忽略——写部门名的审批记录，事后无法追到人。

需要提醒的是，留痕密度不是越高越好。一条简单的业务被拆成二十个节点，业务员会绕过系统。合理的密度是「每个真正会改变责任归属的动作都有一个节点」，比如材料交接、资质核对、风险确认、提交、退回、批复。数得清、说得明，就够了。

六、日志不会说谎：7246 条操作记录里，哪两类留痕最薄

前面四节讲的都是「应该有什么」。这一节看「实际发生了什么」，数据来自我们自己的生产库 operation_logs 表，2026 年 10 月 18 日快照共 7246 条，覆盖 38 个模块、10 类动作（CREATE、UPDATE、DELETE、APPROVE、SUBMIT、EXTRACT、CLAIM、RETURN、BLACKLIST、REJECT），其中成功 6972 条、失败 274 条。

按模块分布，前三位是：通话记录 4072 条、客户 1406 条、消息 1075 条。三者合计 6553 条，占全部日志的 90.4%。这个分布本身是合理的——系统的日常高频动作就是打电话、改客户、发消息。

但把视线移到后面几行，就能看出问题：进件 102 条（1.4%）、档案 9 条（0.12%）、授权类操作 116 条（1.6%，模块名为 auth）。而名单制要查的合作机构档案、风控不外包要查的进件过程、不得直接收费要查的授权与告知，恰好落在这三处。

这张图给出的结论，比任何功能清单都直接：留痕能力存在，不等于留痕在发生。系统可以记录进件状态变更，但如果业务员习惯在系统外推进流程，日志里就永远是空的。同理，系统可以记录档案变更，但如果档案本身没人维护，日志里就只有上线那天的那几条。

还有两个数字值得单独看。DELETE 动作 69 条、EXTRACT 动作 37 条。这两类是合规检查最敏感的动作——删除和导出。它们能被记录下来，说明系统在这一层是可信的；总量不大，说明高频删除和高频导出的行为目前没有发生。真正需要警惕的情况恰恰相反：如果某个月 DELETE 突然涨到几百条，或者 EXTRACT 集中在某一个人身上，那才是最该被看见的信号。

失败 274 条（占 3.8%）也值得留一句。失败日志同样是有用的记录——它证明某人在某个时间点尝试过某个动作但没有成功。很多机构清理日志时会把失败记录一起删掉，等于把「尝试过」这件事抹掉了。日志的价值在于完整，不在于好看。

这一节的用法很实际：把它当成一次自查。导出你自己的操作日志，按模块排个序，看看「名单／进件／档案／授权」这几类动作占比多少。低于 5% 的，说明这几件事在系统里还没有真正跑起来，而不是系统不支持。权限怎么分级那篇讲了日志与权限的关系，金融行业 CRM 怎么选里提到的「记录不可变」，说的也是同一件事的另一面。

七、上线顺序：先做哪一条，做错顺序会白干

四条要求一起上，是最常见的失败方式。把顺序排对，能用最小的动作拿到最大的确定性。

第一步，先让「一张表」能导出来。合作机构档案加单笔费用明细，两件事都不需要改业务流程，只需要把现有数据搬进结构化的表里。这一步的价值在于：它立刻给了你一个可以对外交付的东西——被问到的时候，你能导出一张表，而不是打开一个文件夹找 Excel。周期通常一到两周，取决于历史数据有多乱。

第二步，再让「一条时间轴」能拉出来。任取一笔进件，能把状态变更、审批记录、材料提交记录按时间排成一条线。这一步要改的是流程——把散落在微信和纸面上的动作搬进系统。周期比第一步长，因为它动的是人的习惯，不是代码。判断这一步做成了没有，用前面那个指标：留痕密度能不能稳定在 5 条以上。

第三步，最后做提醒与阻断。机构档案到期提醒、资质核对到期提醒、状态为「暂停」的通道禁止新建进件。这些是「防错」能力，必须建立在前面两步之上——档案没维护，提醒就是空转；进件没在系统里跑，阻断就是形同虚设。

顺序反过来做，结果通常是：阻断上线了，业务员绕开系统直接线下推进；提醒上线了，因为档案没更新，每天都在弹无效提醒；最后大家把提醒关掉，回到原点。这类失败在行业里很常见，原因不是技术，是顺序。

还有三个误解值得提前说清。误解一：以为制度文件够用。制度写的是「应当」，检查看的是「证据」，两者之间隔着一次数据导出。误解二：以为有日志就行。日志要能按人、按笔、按时间三个维度查，只能按时间顺序往下翻的日志，在检查现场翻不出来。误解三：以为一次配完就结束。政策会出配套文件，配套文件会改口径，字段设计必须留扩展位——费用科目要能加，机构类型要能加，别把枚举值写死在代码里。

这三步做完，其实也就把「合规」这件事从「文件夹里的制度」变成了「数据库里的记录」。它不会让业务变快，但会让业务在被问到的时候答得出来。防飞单那一层也是同样的逻辑，客户资源保护的分层机制讲的是客户维度，本文讲的是政策维度，两者用的是同一套留痕思路。

八、助贷新规落地后，机构最常问的四个问题

助贷新规和「9 号文」是同一份文件吗？是。全称是《国家金融监督管理总局关于加强商业银行互联网助贷业务管理 提升金融服务质效的通知》，文号金规〔2025〕9 号，2025 年 4 月发布、2025 年 10 月 1 日施行。业内因为施行日接近 9 月底，也叫「9·30 新规」。本文引用的条文口径都以这份文件为准。

24% 是利息上限还是总成本上限？是综合融资成本上限。条文表述是「借款人单笔贷款的综合融资成本」，而第三条明确要求平台不得以任何形式向借款人直接收取息费，各种名目的费用一律计入综合融资成本。所以判断口径必须是「加总后」的数字，不是单看利息那一项。这也是为什么费用明细必须能挂到具体的业务笔上——不能加总，就无法判断。

我们不做互联网助贷，只在本地做居间撮合，还需要按这个改吗？这个问题超出本文范围，我们不给结论。只能说清两件事：这份文件的规范对象是商业银行的互联网助贷业务；而《个人贷款业务明示综合融资成本规定》与《金融产品网络营销管理办法》覆盖的范围更宽，涉及息费明示与营销宣传。具体适用性请由法务或专业机构判断。从管理角度说，即使不在适用范围内，把「费用能加总到单笔、过程能拉出时间轴」这两件事做起来，本身不亏。

名单是银行的事，我们机构内部要留什么？留三样：一是你合作过的每一家机构的档案（全称、分支机构、业务类型、状态、最近核对日期）；二是每次状态变化的时间和依据；三是停用之后新进件被阻断的记录。这三样东西合起来，能回答一个很实际的问题——「某段时间里，我们有没有往一个已经停用的通道推过客户」。答得出来，说明管理是闭环的。

如果你正在对照这四条做自查，可以先查看价格与版本说明，看看现有版本里档案、进件、费用、日志这四块能力的边界在哪；也可以从助贷 CRM 和普通 CRM 的区别读起，先把数据结构这层想清楚，再决定改什么。通话与沟通那一层的留痕，通话录音怎么管那篇有更细的口径。