摘要：银行催收正从"打电话"走向"打信息战"。本文梳理催收行业三个时代的信息演进，拆解贷后监控、催前尽调、失联修复、不良处置四个环节的数据盲区，并给出基于企查查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催收技术公平性做出全面规范。
合规成本上升，但不不良资产处置市场也在快速扩容：
| 指标 | 数据 | 来源 |
|---|---|---|
| 2024年个贷不良批量转让成交 | 1583亿元 | 银登中心 |
| 2025年全年挂牌 | 超3500亿元 | 银登中心 |
| 信达+中信金融资产年收购规模 | 超5400亿元 | 财联社 |
| 2025年四季度末不良贷款余额 | 3.5万亿元 | 国家金融监督管理总局 |
3.0时代的工具变了：外部数据基础设施成熟（工商/司法/知识产权/招投标/舆情多维度覆盖），AI让数据查询从人工翻档案变成自然语言提问。谁先接入，谁先拿到优势。
二、催收效率的本质：信息对称问题
银行对借款人的信息掌握程度，往往远低于对贷款账面数据的了解：
- 账面数据是结构化的（金额/利率/期限/担保方式）
- 借款人真实风险是分散的（被执行？资产已抵押？关联企业互保？）
这些信息分布在工商、司法、知识产权、招投标、舆情等多个系统里，不主动去查，根本不知道。
催收时机卡在「不知道」和「知道了」之间。
催收工作中有一个「信息窗口期」概念——从风险信号出现到损失真正形成，中间有一段可干预的时间。窗口期有效性取决于信息到达速度。数据的作用，就是在窗口期内把信息送到决策者面前。
三、四个信息盲区与技术方案
银行催收工作通常分为三个阶段：贷后监控 → 深度催收 → 处置回收。每个阶段都存在信息不对称的典型盲区。
盲区一：贷后监控滞后
大部分银行贷后管理还处于定期翻档案阶段，每季度或半年翻一次还款记录，没有逾期就默认正常。但很多风险信号不等季度报告。
更隐蔽的是关联企业风险——借款企业本身正常经营，但同一实控人名下另一家公司正在被法院执行，或刚被吊销。传统贷后管理没有触发条件。
技术方案：批量导入存量客户清单，持续监控风险信号，任意一项触发即推送预警。
"""
贷后风险监控 - 批量企业风险扫描示例
使用企查查API对企业列表进行风险扫描，返回命中风险的企业
"""
import requests
import json
API_BASE = "https://api.qcc.com/api"
API_KEY = "your_api_key_here"
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
}
def batch_risk_scan(company_list: list[str]) -> list[dict]:
"""
批量扫描企业风险信号
输入：企业名称列表
输出：命中风险的企业及风险类型
"""
risk_signals = []
for company in company_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 = []
if dishonest.get("Result"):
signals.append({"type": "失信被执行", "detail": dishonest["Result"]})
if executed.get("Result"):
signals.append({"type": "被执行人", "detail": executed["Result"]})
if abnormal.get("Result"):
signals.append({"type": "经营异常", "detail": abnormal["Result"]})
if restriction.get("Result"):
signals.append({"type": "限制高消费", "detail": restriction["Result"]})
if signals:
risk_signals.append({
"company": company,
"risk_count": len(signals),
"signals": signals
})
return risk_signals
# 示例调用
if __name__ == "__main__":
watch_list = ["某某科技有限公司", "某某贸易有限公司", "某某实业有限公司"]
results = batch_risk_scan(watch_list)
for r in results:
print(f"[风险预警] {r['company']} - 命中{r['risk_count']}项风险")
for s in r["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类风险一键查询
使用合作风险排查接口，一次性获取企业全维度风险画像
"""
def full_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": []
}
for category, items in risk_categories.items():
count = sum(1 for item in items
if any(item in str(result.get("Result", "")))
)
if count > 0:
profile["risk_summary"][category] = count
profile["total_risks"] += count
return profile
盲区三：债务人失联
企业的备案网站、APP、小程序、招聘网站联系方式、分支机构地址、历史变更记录里的旧地址，都是可追溯的触达路径。关联方同样是突破口——股东、主要人员、上下游合作伙伴、担保人。
技术方案：从单一企业出发，拓展催收线索网络。
"""
失联修复 - 多维度线索挖掘
通过企业信息API挖掘联系人和关联方线索
"""
def find_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()
if personnel.get("Result"):
for person in personnel["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()
if related.get("Result"):
for comp in related["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()
return leads
# 实战场景：互联网银行催收部的做法
# 收集申贷企业有进行中的司法案件 → 提取对手方企业 → 获取对手方联系方式/地址
# 同地址的其他关联企业同样是线索
# 线索拉出来，催收方向就清晰了
盲区四：不良资产处置效率
进入处置阶段，资产包里混入了大量看起来有债权、实际无资产可执行的空壳公司。空壳特征：注册地址异常、零纳税、零社保、频繁变更法人。
另一部分企业虽然表面正常，但动产抵押记录显示设备已抵押，股权出质记录显示股权已质押——这类资产线索直接影响回收价值判断。
技术方案：批量空壳识别 + 资产线索挖掘 + 企业财税评估，分层处理。
"""
不良资产处置 - 空壳识别与资产线索挖掘
"""
def shell_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()
if len(history.get("Result", [])) >= 3:
flags["frequent_legal_change"] = True
flags["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" if flags["shell_score"] >= 60 else "priority"
}
四、MCP智能体接入实战
4.1 为什么用MCP
传统API对接需要写代码、做接口映射、处理返回结构。对于有AI应用规划的金融机构，MCP协议让催收人员直接在AI对话系统里用自然语言查询，不需要切换系统。
MCP核心价值：让AI「长出」企业数据查询能力。
4.2 6大Server工具对照表
| Server | 代码名 | 工具数 | 覆盖数据 | 催收场景适用 |
|---|---|---|---|---|
| 企业基座 | qcc-company | 16 | 工商登记结构化数据（股东、实控人、受益所有人） | 实控人穿透、受益所有人识别 |
| 风控大脑 | qcc-risk | 35 | 失信/被执行/严重违法/税务异常 | 贷后监控红线、催前尽调 |
| 知识引擎 | qcc-ipr | 18 | 专利/商标/软著/APP/小程序/公众号/抖音 | 资产线索挖掘、数字资产估值 |
| 经营罗盘 | qcc-operation | 35 | 招投标/资质/舆情/纳税/土地/私募 | 经营状态判断、异常预警 |
| 历史存档 | qcc-history | 34 | 历史股东/法代/失信轨迹（企业专享） | 识别「洗白型」主体 |
| 董监高画像 | qcc-executive | 42 | 个人司法风险+关联企业穿透+UBO识别 | 以人查风险、实控人关联扫描 |
总工具数：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设计）
| 特性 | 说明 | 催收场景价值 |
|---|---|---|
| 实体强锚定 | 强制验证信用代码，降低名称幻觉 | 避免把「乐视影业」查成「乐视网」 |
| 参数下推 | 引导Agent按需索取，不全量返回 | 降低Token消耗，行内AI集成成本更低 |
| 强语义负向防御 | 空数据转强语义状态码（如"核验通过"） | 没有风险=明确正向信号，不是"查不到" |
4.5 自然语言查询示例
催收人员不需要写代码，直接在AI对话里提问：
# 贷后监控
"帮我查一下某某科技有限公司有没有新增的失信记录"
# 催前尽调
"扫描某某贸易有限公司实控人名下的所有关联风险"
# 失联修复
"某某实业有限公司的法人还担任了哪些公司的职务？有哪些联系方式？"
# 不良资产评估
"批量核查这10家企业的空壳特征和资产抵押情况"
4.6 支持平台
| 平台 | 类型 | 说明 |
|---|---|---|
| WorkBuddy | AI办公助手 | 腾讯云原生，国产Agent工作流首选 |
| Cursor | AI代码编辑器 | 开发者优选 |
| Trae | AI IDE | 字节跳动AI原生IDE |
| Claude Code | CLI工具 | Anthropic旗下代码助手 |
| QoderWork | AI办公Agent | 阿里Qoder旗下 |
| OpenClaw | Agent开发平台 | 企业级，支持多MCP Server协同 |
| Cherry Studio | 桌面客户端 | 多模型AI客户端 |
已适配 ** 多家AI应用**，3步完成接入（注册获取Key → 加载SKILL → 自然语言提问）
五、四套数据服务方案对照
| 接入方式 | 适用场景 | 计费方式 | 催收场景适配 |
|---|---|---|---|
| API数据接口 | 系统对接、实时查询 | 按调用量计费 | 催前尽调、失联修复按需调用 |
| 企业户监控清单 | 存量客户批量监控 | 按客户数固定计费，不限调用次数 | 贷后监控，性价比最高 |
| 离线数据库 | 批量尽调、数据湖建设 | 全量数据交付 | 不良资产批量处置、AMC对接 |
| MCP智能体 | 行内AI应用数据注入 | 按调用量计费 | 城商行/农商行AI助手场景 |
常用API接口参考
| 接口名称 | 接口代码 | 说明 |
|---|---|---|
| 失信核查 | 740 | 查询企业失信被执行记录 |
| 被执行人核查 | 741 | 查询企业正在执行的案件 |
| 经营异常核查 | 739 | 查询企业经营异常记录 |
| 司法拍卖核查 | 744 | 查询企业司法拍卖记录 |
| 动产抵押核查 | 747 | 查询动产抵押登记信息 |
| 限制高消费核查 | 742 | 查询实控人限高情况 |
| 严重违法核查 | 748 | 查询严重违法记录 |
| 合作风险排查 | 2006 | 34类司法风险全覆盖，一次查询 |
| 客户身份识别 | 2003 | 受益所有人识别+实控人穿透 |
数据场景与能力映射
| 数据场景 | 核心能力 | 典型应用 |
|---|---|---|
| 贷后监控 | 工商变更、失信/被执行新增、经营异常、司法拍卖、股权冻结 | 风险信号触发即推送，替代人工定期查询 |
| 催前尽调 | 合作风险排查（34类风险一次查）、实控人穿透、关联企业扫描 | 新增逾期客户一键生成风险画像 |
| 失联修复 | 联系方式挖掘、地址关联企业、关联方追溯 | 拓展催收线索网络，重新触达债务人 |
| 不良资产处置 | 空壳扫描、资产线索挖掘、企业财税评估 | 批量识别高/低价值资产，分层处置 |
| AMC对接 | AMC营销公告监控、资产包质量筛查 | 快速对接转让需求，提升资产盘活效率 |
六、实战案例：某互联网银行催收部的做法
该银行企业风险部在日常催收中遇到一个典型问题：催收人员拿到不良贷款，知道企业名字，能看到的基本信息有限。
他们的解决思路：
- 收集申贷企业有进行中的司法案件
- 提取案件中的对手方企业及其联系方式、地址、主要人员
- 通过地址字段匹配，找到同地址的其他关联企业
- 对手方和同地址企业都是催收可直接用的线索
底层逻辑：催收本质上是信息挖掘工作，信息的完整性决定了催收的效率和质量。
"""
司法案件对手方追踪 - 互联网银行催收实战
"""
def trace_adversary(company_name: str) -> list[dict]:
"""
通过司法案件追踪对手方，挖掘催收线索
"""
leads = []
# 1. 查询企业当前在审/在执的司法案件
cases = requests.post(
f"{API_BASE}/judicial/getInfo",
headers=HEADERS,
json={"searchKey": company_name}
).json()
for case in cases.get("Result", []):
adversary = case.get("Adversary", {})
# 2. 获取对手方企业信息
if adversary.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. 同地址关联企业
if lead["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)
return leads
数据来源
| 编号 | 来源 |
|---|---|
| [1] | 国家金融监督管理总局，《2025年四季度银行业金融机构主要监管指标数据》，2026年2月12日 |
| [2] | 银登中心，《2024年不良贷款转让业务统计》，2025年 |
| [3] | 财联社，《两大全国性AMC年收购不良资产超5400亿》，2026年4月 |
| [4] | 中国银行业协会，《金融机构个人消费类贷款催收工作指引（试行）》，2026年1月30日 |
| [5] | 国家金融监督管理总局，《金融机构合规管理办法》，2024年12月25日 |
