银行中介系统需要哪些能力？

"银行中介系统"这个说法在行业里指两件事，而且经常被混在一起讲。一件事是银行侧用来管理与中介、助贷平台合作的系统——准入谁、给多少额度、合作情况如何、什么时候该退出。另一件事是中介机构侧用来对接多家银行渠道的系统——一个客户往哪几家报、材料怎么给、进度怎么跟、费用怎么算。

这两件事的能力清单有一半是重叠的，重叠的部分正是监管最在意的地方：准入与名单、进件与分流、费用与披露、留痕与行为合规。所以把两侧放在一起讲，比只讲一侧更有用——中介侧做系统时知道银行会查什么，银行侧做系统时知道中介侧能给什么，双方的能力才能对上。

这篇先说明两侧的能力差异，然后逐项展开六类核心能力，每项都给出：监管要求的原文口径、系统里的具体落点、以及落地时最容易缺的东西。文中引用的监管条款均来自公开文件，会标注文件名与条款性质。

一、两侧的定位不同，能力清单也不同

• 银行侧的管理对象是"合作机构"。需要的能力是准入审核、名单管理、额度与规模控制、合作情况评估、退出机制。它的核心动作是"审"和"看"。
• 中介侧的管理对象是"客户与通道的匹配"。需要的能力是客户资质建档、通道匹配、材料准备、进度跟踪、费用核算、结算对账。它的核心动作是"推"和"跟"。
• 两侧的交集是"进件"。这是唯一一个双方都要有完整记录的对象：银行侧要知道这批进件是谁推的、质量如何；中介侧要知道这批进件到了哪一步、卡在哪。进件记录的口径不一致，双方的对账永远对不上。

一个容易被忽略的现实是：银行希望同时与多家获客导流平台合作（监管也一直强调集中度管理），而平台也希望同时服务多家金融机构，借款人本人同样希望多试几家以提高最终通过概率。公开资料对这个结构的描述很准确：在中小银行与助贷平台的合作中，借款人申请界面上很难见到从头到尾只属于一家银行的专用申请流程，往往是平台自己的流程，在稍后端某个节点再把客户分发导入具体一家银行的流程。这个"分发点"就是中介系统最关键的功能位置。

二、能力一：合作机构名单制与准入退出

这是监管要求最明确、也最容易被系统做轻的一块。

监管要求：名单制、准入审核与黑名单

• 公开的监管通知（金规〔2025〕9 号《关于加强商业银行互联网助贷业务管理提升金融服务质效的通知》，2025 年 4 月发布、2025 年 10 月 1 日起施行）要求：商业银行总行应当对平台运营机构、增信服务机构实行名单制管理，通过官方网站、移动互联网应用程序等渠道披露名单，及时对名单进行更新调整，不得与名单外的机构开展互联网助贷业务合作。通知同时要求加强准入管理：审慎制定准入标准、有效实施尽职调查、从严审批，并签订要素完整、分工清晰、权责对等、公平合理的合作协议。
• 地方监管文件（某地监管局关于进一步规范银行业金融机构与中介机构合作的通知）进一步细化：要建立健全自上而下、统一管理的合作机构准入退出机制，由总行或一级分支机构及以上层级审核中介资质，并实行名单制管理；合作应签订书面合作协议，明确合作范围、各方权责、客户权益保护、数据保密、禁止性行为等内容；鼓励建立贷款中介黑名单制度，将诱导、帮助借款人违规申请贷款的中介机构纳入黑名单。

系统落点：名单是一个带时间戳的状态

• 机构档案要能区分角色。平台运营机构、增信服务机构、贷款中介是三类不同的合作方，承担的责任和适用的要求都不同。把它们放在同一张表里只靠一个字段区分，会让后续的名单披露和风险计量都做不准。
• 名单不是一张表，是一个状态。名单要有生效时间、更新记录、对外披露记录。因为"不得与名单外机构合作"这条要求的验证方式是：任何一笔业务发生时，都能证明当时的合作方在名单内。这就要求名单状态是带时间戳的，而不是一个当前布尔值。
• 黑名单要有准入拦截能力。黑名单的价值在于"拦住"，如果只是记录在案但业务照样能推，它就退化成了一个备注。系统需要在进件、结算这类关键动作上做实时校验。
• 退出要有完整记录。退出往往伴随未结清的费用、在途的业务、需要交接的客户。这几件事都需要系统里的结构化数据支撑。合作方准入与退出的具体设计，和金融居间CRM与普通CRM的差异里讨论的居间人档案是同一套机制。

三、能力二：多通道进件与分流

这是中介系统最难做、也最容易被低估的一块。公开资料对银行互联网贷款进件的描述值得完整引用。

进件的类型比想象的多

公开资料列举的进件类型包括：授信额度或单笔贷款资格申请、额度项下提款资格申请、放款验证申请、提前还款申请、提前终止额度申请，有时还会有预申请流程。更麻烦的是流程本身不一定是单向的：有些流程会中间被折回前端合作平台，需要先完成某一个插入的操作才能继续。

这组事实对系统设计有三个直接要求：

• 进件是一类对象，不是一种状态。把进件做成"客户阶段"里的一个值，就没法表达一个客户同时有"额度申请在途"和"提款申请在途"两件事。正确做法是进件独立成表，与客户是一对多关系。这一点在贷款中介客户管理系统怎么搭里已经讨论过。
• 流程必须支持"折返"。如果系统只支持单向推进，遇到需要回到前端补动作的节点就只能靠人工标记，结果就是流程状态与真实进度脱节。流程引擎需要支持回退、挂起、等待外部动作这类状态。
• 材料清单必须按通道配置。不同银行的材料要求不一样，把清单写成全局统一的一份，最终一定会有人用微信传补充材料，进件记录就断了。

分流点怎么设计

回到前面那个"分发点"：平台侧完成信息采集后，要在某个节点把客户分发给具体某家银行。这个动作的设计要点是分流规则要可配置、可解释、可回溯。

• 可配置，是因为银行的准入政策会变，某家银行暂停某类客户时，分流规则要能临时调整而不需要改代码。
• 可解释，是因为客户会问"为什么给我报这家不报那家"，业务人员需要一个能说清楚的理由。
• 可回溯，是因为事后要能回答"这笔进件当时是按哪条规则分出去的"。这三条里"可回溯"最容易被省掉，做法很简单：分流时把命中的规则和当时的客户特征快照一并落库。

四、能力三：风控边界——做得越前越要对得起这条线

中介能做风控筛选吗？能。但边界非常清楚。

监管划的三条线

• 不得因业务合作降低风险管控标准。地方监管文件明确要求，对于助贷推介的客户，银行的信贷人员应坚持以我为主、独立审慎的准入决策，准入和审批条件不应低于自主拓客标准。
• 严禁将贷前调查和贷后管理的实质职责交由贷款中介承担。这是明令禁止的。中介可以协助收集材料、可以前置筛选，但不能替代银行的实质调查与管理职责。
• 风控不能外包。公开资料强调，即便助贷平台自身已经做过一道筛选，商业银行也必须建立自身的二道风控流程或终审风控流程。

对中介系统的含义

这三条线放在一起，得到一个清晰的设计原则：中介侧的风控是为"提高匹配效率"服务的，不是为"替代银行判断"服务的。具体落成三类能力：

• 资质建档，标注数据来源。客户的收入、负债、抵押物、征信概况要记录，但每一条都要标清是客户自述、人工核验还是第三方数据。这个来源标注在系统里体现为一个字段，看起来不起眼，但在争议时它是唯一能说明"我们凭什么这么判断"的依据。
• 前置筛选结果要与银行结果分开存。中介侧的预筛结果是"我们建议往哪报"，银行侧的结果是"批没批"。两个结果混在一个字段里，会导致通过率统计彻底失真——分母里既有我们筛掉的，也有银行否掉的。
• 不做替银行决策的表述。系统里的字段命名和文案要避开"审批通过""授信额度"这类词，改用"预筛通过""建议申请额度"。这不只是措辞问题：如果系统界面上显示的是银行的审批结论，而实际是中介自己的判断，这在合规上就是实质性的误导。相关的界面与文案要求，在金融行业CRM系统怎么选里有更完整的讨论。

另外，公开资料提到银行侧会设置两个专门岗位：进件管理人员（负责与助贷机构指定专员核对信息、确定申请客户清单、按规则分配订单）和集中访谈人员（负责与每个借款申请人访谈，重点核实资金是否为借款人本人使用、用途是否合理、第三方机构是否存在撮合资金用途以及不合理收费或额外收费）。这两个岗位在系统里都需要对应的功能：核对清单、访谈记录表单、以及"访谈结论"这个独立的状态。中介侧的系统如果能主动输出这份核对清单和访谈要点，与银行的协作效率会高很多，这也是中介侧系统值得做的一个差异化能力。

五、能力四：费用可算、成本可披露

费用是银行中介合作里监管最细的一块，也是系统最容易算错的一块。

监管要求：费用项、综合融资成本与支付进度

• 合作协议中要明确平台服务、增信服务的费用标准或区间；将增信服务费计入借款人的综合融资成本并明确综合融资成本区间；明确平台运营机构不得以任何形式向借款人收取息费；增信服务机构不得以咨询费、顾问费等形式变相提高增信服务费率。
• 向借款人充分披露的关键信息包括：贷款主体、年化贷款利率、增信服务机构、增信服务费率、年化综合融资成本、贷款违约后可能产生的各项息费；并明确除已披露的息费项目外不再向借款人收取其他费用。
• 商业银行按照贷款实收利息的一定比例支付合作费用的，支付进度应当与贷款本金收回进度相匹配。同时要求审慎核定合作费用上限并严格执行。
• 地方监管文件另有一条明确的禁止性规定：禁止合作机构以银行业金融机构名义向客户收取任何费用。

系统落点：四件必须做到的事

• 费用项必须穷举，不能有"其他"。综合融资成本的计算前提是知道有哪些费用。如果费用表里有一个"其他费用"的自由填写字段，这个数就永远算不准。设计上应该做成费用项字典加金额，字典之外不给入口。
• 综合融资成本要能按笔计算并留存计算过程。它不是一个展示数字，而是一个需要被披露、可能被复核的口径。系统至少要能还原"这笔业务当时算出来的综合成本是多少、由哪几项构成"。
• 披露动作要留痕。披露六项信息是规定动作，那么"什么时候向谁披露了哪些内容、对方是否确认"就该是记录。做到这一点的机构，在客户投诉时能拿得出东西；没做的，只能靠回忆。
• 结算设计要与本金收回进度挂钩。这是对系统结构影响最大的一条：如果合作费用按实收利息的一定比例支付，那么付款计划必须跟着回款流水走，而不是按签约时间一次性计提。这意味着结算模块需要读取还款进度数据，而不能只看放款记录。具体规则设计见助贷佣金结算系统怎么做与助贷分佣管理怎么做。

这里还要提醒一个实操层面的坑：金额单位不统一。回款流水与订单金额在行业系统里常采用不同的计量单位（一个以分为单位存储、一个以元为单位展示），两套数据一旦在同一个计算式里混用，系统不会报错，只会安静地算错，等到对账时才发现差异。资金相关的字段单位必须在数据模型层面统一并写在文档里，这是所有费用能力的地基。

六、能力五：对接方式要选对

中介系统与银行的对接方式，不是纯技术选择，而是合规架构的一部分。公开资料对这个演变过程的记录很清晰：助贷与放贷机构之间的信息交互方式经历了调整，形成了两类合规模式——风控数据通道模式与直连跳转模式。两者的区别在于：客户的申请信息和风控数据是由助贷机构通过征信机构转提供至放贷机构，还是由放贷机构自行获取；更深层的区别在于与客户交互的界面由谁来做，也就是谁获取一手客户信息。

公开资料对风控数据通道模式的流程描述可以作为设计参照：

• 助贷机构先做客户的要素核验与人脸活体核验，连同贷款金额、期限等申请信息，一并推送至征信机构封装接口。
• 接口作为转接站，将信息推送给放贷机构；放贷机构受理后出于审慎考虑往往还会再做一遍身份核验。
• 放贷机构核实通过后，从各类合规数据来源调用客户风险字段，形成风险判断与决策依据；其中也可能调取助贷平台的独有风险字段与模型结果，但须从征信机构封装的风险字段接口中调取。
• 审批意见反馈至征信机构接口，再推送至助贷平台完成结果展示。
• 进入放款环节后，无需再通过征信机构中转，而是通过直连接口同步放款与贷后信息：客户在线签署贷款协议、放贷机构启动放款，并将放款状态、贷款要素、还款计划等信息实时或批量同步至助贷平台；后续还款履约信息同样处理。

这段流程对系统设计的启示有三点：其一，客户要素与风控字段是两类不同性质的数据，所处环节并不同步，因此接口层要分别封装、采用不同的查询或推送策略，而不是打包成一个请求。其二，贷前与放款后的链路是两套，贷前走中介通道、放款后走直连，系统需要同时支持这两种链路并标记清楚每笔业务走的是哪种。其三，每一次数据外发都要留痕，因为数据的合规性依赖于"在客户充分授权前提下输出"这个前提。

关于数据外发的合规底线，地方监管文件有一句非常明确的表述：严禁以业务营销、拓展客户等任何名义，将客户信息泄露给中介机构。对中介侧系统的含义是：客户信息的每一次流动都应有明确的目的与授权依据，且能被审计。

七、能力六：过程留痕与行为合规

监管对"人"的要求，最终都会变成对系统的要求。

几条明令禁止的行为

• 禁止合作机构以银行业金融机构名义向客户收取任何费用。
• 严禁将信贷资金直接或间接支付划拨给合作机构。
• 不得允许合作机构及其工作人员在银行营业网点或者自营网络平台以银行名义向消费者推荐或者销售产品和服务；严禁非本机构人员利用银行营业场所、办公区域开展业务。
• 员工行为管理方面，要重点关注基层工作人员是否存在私下勾结贷款中介、向客户推荐贷款中介、放松对贷款中介推荐客户的审贷标准和贷后管理标准等问题。
• 信贷调查或审批时，助贷机构人员应进行履职回避，不应参与银行业务流程。

系统落点：从操作日志到回避机制

• 操作日志要能按人、按时间、按对象查。这是所有行为合规的基础。日志的关键指标不是"有没有"，而是"能不能查出'谁在什么时候对哪条数据做了什么'"。权限设计见助贷CRM权限怎么分级。
• 人员与机构要分开授权。驻场人员、外部合作方人员如果在同一套系统里操作，必须有明确的范围限制，且范围之外不可见。这正是"严禁非本机构人员利用营业场所开展业务"在系统里的对应物。
• 回避机制要有系统支持。履职回避要求中介方人员不参与银行流程，那么系统就应该在中介侧账号上禁止访问银行侧的审批环节记录。做不到技术隔离，就只能靠人自觉。
• 合作方评估要有一组固定指标。公开资料提到银行应通过系统对助贷机构的推荐业务量、通过率及还本付息情况进行持续监测和反馈，对合作情况定期走访评估时关注退件率、客户质量、业务风险以及内部管理情况。这两组指标就是合作方评估模块的字段清单——中介侧如果能主动产出同口径的数据，评估环节会顺畅得多。

八、常见问题

中介机构需要按银行的合规标准来建系统吗？不需要照搬银行的全部要求，但需要覆盖与协作有关的那些。判断标准很简单：凡是银行会向你要数据、要凭证、要对账的环节，就要按结构化记录来做。其余部分按自身管理需要设计即可。

只有在两三家银行报件，还需要多通道进件的结构吗？需要。通道数量少不改变"一个客户对多个通道"的关系结构，只改变并发数量。而且通道是会更替的——今天两家，明年可能五家。数据模型一开始就建对，后期扩通道是加数据；建错了，是改模型。

系统里能不能直接显示"审批通过"？不能用于中介侧的自有判断。银行给出的结果可以按原样记录（并标注来源是银行），但中介自己筛出来的结论必须使用"预筛"这类表述。把中介判断显示成银行结论，是实质性的误导。

合作费用按什么口径结算？如果约定按贷款实收利息的一定比例支付，那么支付进度要与贷款本金收回进度相匹配，结算模块必须能读取回款数据。只按放款计提的做法与这条要求不符。结算规则的具体设计见助贷佣金结算系统怎么做。

九、小结

把六类能力收成一张清单：

• 名单制与准入退出。名单要有生效时间与披露记录，因为"不得与名单外机构合作"的验证方式是"能证明业务发生时对方在名单内"；黑名单必须能实时拦截，不能只是记录。
• 多通道进件与分流。进件类型至少包括额度申请、提款资格申请、放款验证、提前还款、提前终止额度，还可能有预申请；流程要支持折返；材料清单按通道配置；分流规则要可配置、可解释、可回溯。
• 风控边界。不得降低风控标准、不得把贷前调查与贷后管理的实质职责交给中介、风控不能外包。中介侧的对应做法是资质建档标注数据来源、预筛结果与银行结果分开存、界面文案不做替银行决策的表述。
• 费用与披露。费用项要穷举、综合融资成本要能按笔还原、披露要留痕、结算要与本金收回进度挂钩；资金字段单位必须统一。
• 对接方式。风控数据通道与直连跳转的区别在于信息由谁转提供、交互界面由谁来做；客户要素与风控字段分别封装接口；贷前链路与放款后直连链路并存；每次数据外发留痕。
• 留痕与行为合规。操作日志按人、时间、对象可查；内外部人员分开授权；回避机制有技术支撑；合作方评估固定到指标（推荐业务量、通过率、还本付息、退件率、客户质量、业务风险、内部管理）。

最后给一个判断方法：一套系统能不能支撑银行中介业务，可以问五个问题——能不能证明某笔业务发生时的合作方在名单内、一个客户能不能同时挂多条进行中的进件、综合融资成本能不能按笔还原出构成、能不能说清每笔业务走的是哪种对接链路、合作方的评估指标能不能自动算出来。五个都能答上来，这套系统就是能对接银行的；有两个答不上来，先补齐再谈业务量。

这套能力与客户管理系统的设计是同一套底子，可以接着看信贷客户管理系统怎么设计、助贷进件管理系统怎么做与贷款中介客户管理系统怎么搭。涉及客户资源保护与费用结构的部分，见助贷防飞单系统怎么选与助贷CRM收费标准。