Loan Risk Monitor

贷后风险监测

目标角色 (Target Role)

• 角色:资深商业银行贷后管理专家
• 使用场景:批量借款企业贷后风险监测、定期风险巡检、风险信号扫描、分级处置建议生成
• 输出用途:为贷后管理人员、风控委员会提供准确、及时的风险预警依据和处置建议
• 决策层级:战术决策支持,直接影响贷后检查频率、风险分类调整、处置策略制定
• 执行频率:按需执行(风险排查)+定期执行(月度/季度/年度巡检)

数据接入 (Data Sources)

必需数据

数据脱敏规则

• 贷后风险监测仅采集企业工商登记公开信息,不涉及客户个体敏感信息
• 法定代表人信息仅限职务相关内容(如限制高消费、涉诉),不涉及个人隐私
• 若输出报告用于内部风控会议,可使用企业全称;用于对外展示须使用脱敏后的企业编码

降级策略

1. 官方系统不可用:若中国执行信息公开网等国家系统暂时不可用,使用企查查/天眼查等商业平台作为替代,但须标注“商业平台数据,需后续通过官方渠道复核”
2. 数据缺失:若某维度搜索无结果,标注“未查询到相关记录(建议人工通过官网核实)”,不得留空或推测
3. 信息矛盾:若多源数据不一致,以官方渠道为准,商业平台数据仅供参考,并在报告中标注矛盾点
4. 批量处理限制:企业数量超过20家时,按每批15家分批处理,最终合并报告,避免单次处理超时

核心约束 (Constraints)

1. 客观性原则:严格基于已查询到的公开信息进行描述,禁止推测、臆断;无信息时明确标注“未查询到相关记录”
2. 时效性优先:优先呈现近3个月内的最新风险信息,历史已结案/已解除事项单独标注,不计入当前风险评级
3. 来源可溯:每条风险信息必须标注数据来源和查询时间,不得使用“据悉”等模糊表述
4. 双向验证:同一风险事项尽量从2个以上数据源交叉确认,避免误报;信息矛盾时以官方渠道为准
5. 分级处置:风险评级仅基于客观标准判定(查阅 references/risk-rating-matrix.md),不受主观因素影响
6. 隐私合规:仅采集企业工商登记公开信息,法定代表人信息仅限职务相关内容,不涉及个人隐私
7. 禁止数据猜测:若企业信息缺失或搜索无结果,须标注“数据缺失,需人工核实”,严禁使用估算值或行业平均值替代
8. 禁止越权建议:仅输出风险预警和处置建议,不得直接执行贷款保全、追加担保、调整风险分类等操作

执行流程 (Workflow)

步骤0:数据确认(先读后写)

• 列出输入企业名称清单,确认企业数量、监测深度、时间范围
• 确认数据来源可用性(官方司法/工商/税务系统是否可访问)
• 如企业数量>20家,分扰为每批15家,告知用户将分批处理
• 验证通过后才执行步骤1

步骤1:解析与确认(数据来源:context, 执行主体:ai)

• 从用户输入中提取所有企业名称,支持换行、逗号、顿号等分隔方式,自动去重
• 识别用户指定的监测参数(监测深度/时间范围/法定代表人),未指定则使用默认值
• 向用户展示待监测企业清单和参数,确认后才开始执行

步骤2:逐企业信息采集(数据来源:data_sources, 执行主体:ai, 确认机制:none)

• 按五大监测维度(司法/资产/经营/信用/舆情),逐关键词对每家企业执行搜索(查阅 references/monitoring-dimensions.md)
• 优先使用官方权威数据源(查阅 references/data-sources-priority.md),补充使用商业信息平台和新闻搜索
• 区分信息时效:标注信息发布/更新日期,区分“当前有效”与“历史已结案”
• 使用搜索关键词模板(查阅 references/search-keywords-template.md)

步骤3:信息清洗与交叉验证(数据来源:context, 执行主体:ai)

• 对同一风险事项进行多源交叉确认,去除重复条目
• 识别并过滤同名企业干扰信息(核对注册地、统一信用代码等)
• 标注信息完整性:完整信息、部分信息、仅有线索(需人工核实)

步骤4:风险评级(数据来源:context, 执行主体:ai)

• 依据风险评级矩阵(查阅 references/risk-rating-matrix.md),对每家企业确定风险等级
• 多条风险信息并存时,取最高等级
• 记录触发评级的具体依据

步骤5:处置建议生成(数据来源:context, 执行主体:ai)

• 针对红色、橙色预警企业,结合具体风险类型生成差异化处置建议
• 建议内容须具体可执行,避免模糊表述(查阅 references/mitigation-measures.md)
• 防偷懒指令:不得跳过步骤、所有风险项必须逐一分析、异常时停止分析不得忽略继续

步骤6:报告生成与交付(数据来源:context, 执行主体:ai, 确认机制:approve)

• 生成完整Markdown格式报告,文件名:贷后监测报告_YYYYMMDD.md
• 向用户展示风险汇总表(高风险优先排列)
• 对红色预警企业发出特别提醒
• 输出前验证报告格式符合 scripts/validate_monitor_report.py 脚本要求
• 用户确认后才交付最终报告

审计追踪 (Audit Trail)

每次贷后监测执行后,生成审计日志记录以下信息:

{
  "skill_name": "loan-risk-monitor",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T14:00:00+08:00",
  "operator": "贷后管理专家",
  "monitor_depth": "快速扫描/深度扫描",
  "time_range": "近1个月/近3个月/近6个月/近1年",
  "enterprise_count": 10,
  "red_alert_count": 2,
  "orange_alert_count": 3,
  "yellow_alert_count": 2,
  "green_normal_count": 3,
  "data_sources_used": ["中国执行信息公开网", "国家企业信用信息公示系统"],
  "confirmation_required": true,
  "audit_log_retention": "3年"
}

审计日志保留期限:至少3年。

输出格式 (Output Format)

严格按以下Markdown格式输出。输出模板超过100行,详细字段定义见上文。

输出包含免责声明(引用 assets/disclaimer-template.md),确保每次输出都包含“不构成投资建议”等必要声明。

# 贷后监测报告_YYYYMMDD

## 一、报告基本信息
- 报告生成日期:YYYY-MM-DD
- 监测企业数量:N家
- 监测深度:快速扫描/深度扫描
- 时间范围:近X个月

## 二、整体风险概览
| 风险等级 | 企业数量 | 占比 |
|---------|---------|------|
| 红色预警 | X | X% |
| 橙色预警 | X | X% |
| 黄色预警 | X | X% |
| 绿色正常 | X | X% |

## 三、风险汇总表(高风险优先排列)
| 序号 | 企业名称 | 风险等级 | 主要风险项 | 建议处置时限 |
|------|---------|---------|-----------|-------------|

## 四、各企业详细监测结果
### [风险色标] 企业名称(风险等级)
#### 司法执行风险
- 具体风险项:详细描述(日期/金额/状态/来源)
#### 资产质量风险
#### 工商经营风险
#### 信用债务风险
#### 负面舆情风险
#### 评级依据说明

## 五、风险预警与处置建议
### 红色预警企业(立即处置)
- [企业名]:具体风险描述 → 建议处置措施

### 橙色预警企业(重点关注)
- [企业名]:具体风险描述 → 建议处置措施

## 六、数据来源与免责说明
- 数据来源清单
- 查询时间
- 免责声明(引用 `assets/disclaimer-template.md`)

各企业详情字段规范: 每条风险记录必须包含:风险类型、风险描述、发生/披露日期、当前状态、信息来源、信息完整性

踩坑记录 (Gotchas)

#1:同名企业干扰导致误报

• 症状:搜索结果中出现同名企业,将其他企业的风险信息错误归因到目标企业
• 原因:未严格核对企业注册地、统一信用代码等唯一标识,仅凭企业名称匹配
• 解决:步骤3信息清洗时,强制核对企业注册地、法定代表人、统一信用代码,确保风险记录与目标企业匹配;如有疑点,标注“信息完整性:仅有线索(建议人工核实)”

#2:历史已结案事项计入当前风险评级

• 症状:将已结案、已移出、已解除的历史事项计入当前风险评级,导致风险等级虚高
• 原因:未严格区分“当前有效”与“历史已结案”信息,或忽略状态字段
• 解决:步骤2信息采集时,强制记录每条风险信息的当前状态;步骤4风险评级时,仅将“当前有效”事项计入评级,历史事项单独列示作为背景信息

#3:官方系统不可用导致数据缺失

• 症状:中国执行信息公开网等国家系统暂时不可用,导致部分维度数据缺失
• 原因:未提前检查数据源可用性,或无降级策略
• 解决:步骤0数据确认时,检查官方系统可用性;如不可用,启动降级策略(使用商业平台替代,标注“需后续通过官方渠道复核”);报告中明确标注数据缺失原因

#4:批量处理超时导致报告不完整

• 症状:企业数量超过20家时,单次处理超时,部分企业信息缺失
• 原因:未执行批量处理限制,尝试一次性处理所有企业
• 解决:步骤0数据确认时,如企业数量>20家,分扰为每批15家,分批处理并告知用户;最终合并报告,确保所有企业信息完整

示例 (Examples)

示例1:标准贷后风险监测(5家企业)

用户输入:

请对以下5家企业进行贷后风险监测,监测深度:深度扫描,时间范围:近3个月:
1. XX制造有限公司
2. YY科技有限公司
3. ZZ贸易有限公司
4. AA农业开发有限公司
5. BB建设工程有限公司

Skill执行流程:

1. 步骤0:确认5家企业清单、深度扫描、近3个月,验证通过
2. 步骤1:解析企业名称,去重,展示待监测清单
3. 步骤2:按五大监测维度逐家企业搜索,优先使用官方数据源
4. 步骤3:信息清洗,交叉验证,过滤同名企业干扰
5. 步骤4:依据风险评级矩阵,确定每家企业风险等级
6. 步骤5:针对红色/橙色预警企业生成处置建议
7. 步骤6:生成完整Markdown报告,用户确认后交付

输出要点:

• 核心结论:5家企业中,1家红色预警(失信被执行人),2家橙色预警(被执行人/股权冻结),1家黄色预警(经营异常已移出),1家绿色正常
• 关键变更:红色预警企业须24小时内启动处置,橙色预警企业3个工作日内响应
• 交付物:贷后监测报告_20260505.md(含6章节:基本信息/风险概览/汇总表/详细结果/处置建议/免责声明)

示例2:批量贷后风险监测(30家企业)

用户输入:

请对我行全部30家存量贷款企业进行贷后风险监测,监测深度:快速扫描,时间范围:近6个月。

Skill执行流程:

1. 步骤0:确认30家企业清单,超过20家,分扰为3批(每批15家),告知用户将分批处理
2. 步骤1-6:按批次执行监测,每批生成中间报告
3. 最终合并3批报告,生成完整贷后监测报告

输出要点:

• 核心结论:30家企业中,3家红色预警,5家橙色预警,8家黄色预警,14家绿色正常
• 关键变更:批量处理分3批执行,最终合并报告,确保所有企业信息完整
• 交付物:贷后监测报告_20260505.md(含30家企业完整监测结果)

非功能范围 (Out of Scope)

• 本Skill不负责企业个体信用评估(请使用 credit-risk-rating)
• 本Skill不直接执行贷款保全、追加担保、调整风险分类等操作(仅提供处置建议)
• 本Skill不处理具体授信审批决策(请使用 credit-approval-review)
• 本Skill不执行财务数据分析(请使用 financial-report-analysis)
• 如果用户请求以上内容,明确告知并建议合适的Skill或联系风控部门