银行催收3.0：用企业数据API打通信息孤岛，MCP接入实战指南

摘要：银行催收正从"打电话"走向"打信息战"。本文梳理催收行业三个时代的信息演进，拆解贷后监控、催前尽调、失联修复、不良处置四个环节的数据盲区，并给出基于企查查API和MCP智能体的技术接入方案——含Python调用示例、MCP Server配置JSON、6大Server工具对照表。

数据版本：截止于企查查MCP/20260604最新版本（180个原子工具/6大Server）

一、行业演进：催收的三个时代

1.0 关系催收（2000年代初）

对公信贷催收依赖客户经理的「个人关系」——打电话约谈，谈不下来走诉讼。核心能力是「关系」，信息高度依赖个人经验。同一家企业，不同客户经理了解的风险程度可能完全不同。

2.0 系统化外呼（2010年前后）

催收管理系统（CMS）上线，债务台账、催收记录、案件分配搬到线上，批量外呼系统让催收从「一对一谈」变成「一对多打」。核心能力变成「流程」，效率来自标准化。

结构性问题：数据在机构内部流转，与外部世界隔离。企业的被执行记录在法院系统，工商信息在市场监管系统，关联方散落在十几张数据库里。银行只看得到自己系统里的还款记录，看不到借款人外部真实风险——信息孤岛。

3.0 合规重塑（2021年至今）

《个人信息保护法》《数据安全法》落地，2026年1月中国银行业协会发布《金融机构个人消费类贷款催收工作指引（试行）》，对催收时间、频率、方式、AI催收技术公平性做出全面规范。

合规成本上升，但不不良资产处置市场也在快速扩容：

3.0时代的工具变了：外部数据基础设施成熟（工商/司法/知识产权/招投标/舆情多维度覆盖），AI让数据查询从人工翻档案变成自然语言提问。谁先接入，谁先拿到优势。

二、催收效率的本质：信息对称问题

银行对借款人的信息掌握程度，往往远低于对贷款账面数据的了解：

• 账面数据是结构化的（金额/利率/期限/担保方式）
• 借款人真实风险是分散的（被执行？资产已抵押？关联企业互保？）

这些信息分布在工商、司法、知识产权、招投标、舆情等多个系统里，不主动去查，根本不知道。

催收时机卡在「不知道」和「知道了」之间。

催收工作中有一个「信息窗口期」概念——从风险信号出现到损失真正形成，中间有一段可干预的时间。窗口期有效性取决于信息到达速度。数据的作用，就是在窗口期内把信息送到决策者面前。

三、四个信息盲区与技术方案

银行催收工作通常分为三个阶段：贷后监控 → 深度催收 → 处置回收。每个阶段都存在信息不对称的典型盲区。

盲区一：贷后监控滞后

大部分银行贷后管理还处于定期翻档案阶段，每季度或半年翻一次还款记录，没有逾期就默认正常。但很多风险信号不等季度报告。

更隐蔽的是关联企业风险——借款企业本身正常经营，但同一实控人名下另一家公司正在被法院执行，或刚被吊销。传统贷后管理没有触发条件。

技术方案：批量导入存量客户清单，持续监控风险信号，任意一项触发即推送预警。

""" 贷后风险监控 - 批量企业风险扫描示例 使用企查查API对企业列表进行风险扫描，返回命中风险的企业 """importrequestsimportjson API_BASE="https://api.qcc.com/api"API_KEY="your_api_key_here"HEADERS={"Authorization":f"Bearer{API_KEY}","Content-Type":"application/json"}defbatch_risk_scan(company_list:list[str])->list[dict]:""" 批量扫描企业风险信号 输入：企业名称列表 输出：命中风险的企业及风险类型 """risk_signals=[]forcompanyincompany_list:# 1. 查询失信被执行dishonest=requests.post(f"{API_BASE}/dishonest/getInfo",headers=HEADERS,json={"searchKey":company}).json()# 2. 查询被执行人executed=requests.post(f"{API_BASE}/executed/getInfo",headers=HEADERS,json={"searchKey":company}).json()# 3. 查询经营异常abnormal=requests.post(f"{API_BASE}/abnormal/getInfo",headers=HEADERS,json={"searchKey":company}).json()# 4. 查询限制高消费restriction=requests.post(f"{API_BASE}/consumptionRestriction/getInfo",headers=HEADERS,json={"searchKey":company}).json()# 汇总风险信号signals=[]ifdishonest.get("Result"):signals.append({"type":"失信被执行","detail":dishonest["Result"]})ifexecuted.get("Result"):signals.append({"type":"被执行人","detail":executed["Result"]})ifabnormal.get("Result"):signals.append({"type":"经营异常","detail":abnormal["Result"]})ifrestriction.get("Result"):signals.append({"type":"限制高消费","detail":restriction["Result"]})ifsignals:risk_signals.append({"company":company,"risk_count":len(signals),"signals":signals})returnrisk_signals# 示例调用if__name__=="__main__":watch_list=["某某科技有限公司","某某贸易有限公司","某某实业有限公司"]results=batch_risk_scan(watch_list)forrinresults:print(f"[风险预警]{r['company']}- 命中{r['risk_count']}项风险")forsinr["signals"]:print(f" →{s['type']}")

预期返回（以失信核查接口为例）：

{"Status":"200","Message":"查询成功","Result":[{"Id":"123456","CompanyName":"某某科技有限公司","CreditCode":"91310000XXXXXXXXXX","ExecCourt":"上海市浦东新区人民法院","ExecMoney":"1500000","CaseCode":"(2026)沪0115执XXXXX号","PublishDate":"2026-03-15"}]}

盲区二：催前尽调信息不足

贷款进入M1（逾期1-30天），催收人员拿到企业名称，能看到的基本信息有限。真实风险藏在看不见的地方——实控人名下其他公司已被执行，或实控人已收限高令。

技术方案：一键尽调，生成完整风险画像。

推荐使用「合作风险排查」接口（接口代码2006），一次查询覆盖34类司法风险：

""" 催前尽调 - 34类风险一键查询 使用合作风险排查接口，一次性获取企业全维度风险画像 """deffull_risk_profiling(company_name:str)->dict:""" 合作风险排查：34类司法风险全覆盖 接口代码：2006 """response=requests.post(f"{API_BASE}/riskScan/getInfo",headers=HEADERS,json={"searchKey":company_name})result=response.json()# 风险分类统计risk_categories={"司法风险":["失信被执行","被执行人","限制高消费","裁判文书","法院公告"],"经营风险":["经营异常","严重违法","行政处罚","税收违法","欠税公告"],"资产风险":["动产抵押","股权出质","司法拍卖","土地抵押","查封冻结"],"关联风险":["关联企业异常","实控人风险","担保链风险","同地址企业"]}profile={"company":company_name,"total_risks":0,"risk_summary":{},"high_priority":[]}forcategory,itemsinrisk_categories.items():count=sum(1foriteminitemsifany(iteminstr(result.get("Result",""))))ifcount>0:profile["risk_summary"][category]=count profile["total_risks"]+=countreturnprofile

盲区三：债务人失联

企业的备案网站、APP、小程序、招聘网站联系方式、分支机构地址、历史变更记录里的旧地址，都是可追溯的触达路径。关联方同样是突破口——股东、主要人员、上下游合作伙伴、担保人。

技术方案：从单一企业出发，拓展催收线索网络。

""" 失联修复 - 多维度线索挖掘 通过企业信息API挖掘联系人和关联方线索 """deffind_contact_leads(company_name:str)->dict:""" 从企业出发，挖掘催收线索网络 """leads={"contacts":[],"related_companies":[],"same_address":[]}# 1. 获取企业主要人员（法人、股东、高管）personnel=requests.post(f"{API_BASE}/company/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()ifpersonnel.get("Result"):forpersoninpersonnel["Result"].get("Employees",[]):leads["contacts"].append({"name":person.get("EmployeeName"),"position":person.get("Position")})# 2. 获取关联企业（同地址、同联系方式）related=requests.post(f"{API_BASE}/relatedCompany/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()ifrelated.get("Result"):forcompinrelated["Result"]:leads["related_companies"].append({"name":comp.get("CompanyName"),"relation":comp.get("RelationType")})# 3. 司法案件对手方追踪# 找到申贷企业当前在审/在执的司法案件，提取对手方联系方式judicial=requests.post(f"{API_BASE}/judicial/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()returnleads# 实战场景：互联网银行催收部的做法# 收集申贷企业有进行中的司法案件 → 提取对手方企业 → 获取对手方联系方式/地址# 同地址的其他关联企业同样是线索# 线索拉出来，催收方向就清晰了

盲区四：不良资产处置效率

进入处置阶段，资产包里混入了大量看起来有债权、实际无资产可执行的空壳公司。空壳特征：注册地址异常、零纳税、零社保、频繁变更法人。

另一部分企业虽然表面正常，但动产抵押记录显示设备已抵押，股权出质记录显示股权已质押——这类资产线索直接影响回收价值判断。

技术方案：批量空壳识别 + 资产线索挖掘 + 企业财税评估，分层处理。

""" 不良资产处置 - 空壳识别与资产线索挖掘 """defshell_company_check(company_name:str)->dict:""" 空壳企业识别：多维度特征交叉验证 """flags={"address_abnormal":False,# 注册地址异常"zero_tax":False,# 零纳税"zero_social_security":False,# 零社保"frequent_legal_change":False,# 频繁变更法人"shell_score":0# 空壳概率评分 0-100}# 查询企业基本信息info=requests.post(f"{API_BASE}/company/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()result=info.get("Result",{})# 检查法人变更频率history=requests.post(f"{API_BASE}/historyLegal/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()iflen(history.get("Result",[]))>=3:flags["frequent_legal_change"]=Trueflags["shell_score"]+=30# 检查动产抵押mortgage=requests.post(f"{API_BASE}/chattelMortgage/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()# 检查股权出质pledge=requests.post(f"{API_BASE}/equityPledge/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()asset_status={"has_chattel_mortgage":bool(mortgage.get("Result")),"has_equity_pledge":bool(pledge.get("Result"))}return{"company":company_name,"shell_flags":flags,"asset_status":asset_status,"recommendation":"skip"ifflags["shell_score"]>=60else"priority"}

四、MCP智能体接入实战

4.1 为什么用MCP

传统API对接需要写代码、做接口映射、处理返回结构。对于有AI应用规划的金融机构，MCP协议让催收人员直接在AI对话系统里用自然语言查询，不需要切换系统。

MCP核心价值：让AI「长出」企业数据查询能力。

4.2 6大Server工具对照表

总工具数：180个原子工具 |数据规模：3.65亿+市场主体、2.5亿+司法诉讼、2.1亿+知识产权

4.3 MCP配置示例

以Cursor为例，在.cursor/mcp.json中配置：

{"mcpServers":{"qcc-company":{"command":"npx","args":["-y","@anthropic/mcp-proxy"],"env":{"MCP_API_KEY":"your_qcc_api_key","MCP_SERVER":"qcc-company"}},"qcc-risk":{"command":"npx","args":["-y","@anthropic/mcp-proxy"],"env":{"MCP_API_KEY":"your_qcc_api_key","MCP_SERVER":"qcc-risk"}},"qcc-executive":{"command":"npx","args":["-y","@anthropic/mcp-proxy"],"env":{"MCP_API_KEY":"your_qcc_api_key","MCP_SERVER":"qcc-executive"}}}}

注意：其中5个Server统一searchKey一键接入；qcc-executive（董监高画像）需「企业名称+董监高姓名」双参数锚定。

4.4 技术特性（Agent-Native设计）

4.5 自然语言查询示例

催收人员不需要写代码，直接在AI对话里提问：

# 贷后监控 "帮我查一下某某科技有限公司有没有新增的失信记录" # 催前尽调 "扫描某某贸易有限公司实控人名下的所有关联风险" # 失联修复 "某某实业有限公司的法人还担任了哪些公司的职务？有哪些联系方式？" # 不良资产评估 "批量核查这10家企业的空壳特征和资产抵押情况"

4.6 支持平台

已适配 ** 多家AI应用**，3步完成接入（注册获取Key → 加载SKILL → 自然语言提问）

五、四套数据服务方案对照

常用API接口参考

数据场景与能力映射

六、实战案例：某互联网银行催收部的做法

该银行企业风险部在日常催收中遇到一个典型问题：催收人员拿到不良贷款，知道企业名字，能看到的基本信息有限。

他们的解决思路：

1. 收集申贷企业有进行中的司法案件
2. 提取案件中的对手方企业及其联系方式、地址、主要人员
3. 通过地址字段匹配，找到同地址的其他关联企业
4. 对手方和同地址企业都是催收可直接用的线索

底层逻辑：催收本质上是信息挖掘工作，信息的完整性决定了催收的效率和质量。

""" 司法案件对手方追踪 - 互联网银行催收实战 """deftrace_adversary(company_name:str)->list[dict]:""" 通过司法案件追踪对手方，挖掘催收线索 """leads=[]# 1. 查询企业当前在审/在执的司法案件cases=requests.post(f"{API_BASE}/judicial/getInfo",headers=HEADERS,json={"searchKey":company_name}).json()forcaseincases.get("Result",[]):adversary=case.get("Adversary",{})# 2. 获取对手方企业信息ifadversary.get("CompanyName"):adv_info=requests.post(f"{API_BASE}/company/getInfo",headers=HEADERS,json={"searchKey":adversary["CompanyName"]}).json()lead={"case_code":case.get("CaseCode"),"adversary_company":adversary["CompanyName"],"adversary_contact":adv_info.get("Result",{}).get("Contact"),"adversary_address":adv_info.get("Result",{}).get("Address"),}# 3. 同地址关联企业iflead["adversary_address"]:same_addr=requests.post(f"{API_BASE}/sameAddress/getInfo",headers=HEADERS,json={"address":lead["adversary_address"]}).json()lead["same_address_companies"]=same_addr.get("Result",[])leads.append(lead)returnleads

数据来源