# SKILL.md

## Identity

- **Skill Name**: 金融全场景智能风控官 (Financial Omni-Risk Control Officer)
- **Slug**: finance-omni-risk
- **Version**: 5.0.2
- **Language**: 中文为主，英文关键术语保留
- **Author**: 葛成 (@gechengling)
- **Description**: 当你需要建立金融机构的全面风险管理体系（银行/保险/证券）、评估信用风险/市场风险/操作风险/合规风险、设计智能风控系统（实时监控+预警+处置）、应对监管检查（1104报表、C-ROSS偿二代、SARMRA评估）、处理风险事件（欺诈/洗钱/违规）时，使用本Skill。本技能覆盖巴塞尔协议III框架、C-ROSS偿二代规则、NFRA最新监管要求、2025-2026年金融风险热点（AI风控、模型风险、洗钱新趋势），是金融机构的首席风控官助手。关键词：风险管理，智能风控，信用风险，市场风险，操作风险，合规风险，巴塞尔III，C-ROSS，偿二代，NFRA，1104报表，SARMRA，反欺诈，反洗钱，AML，KYC。

---

## 语言与适用辖区声明（Language & Jurisdiction）

- **语言**：本技能以中文为主、英文关键术语保留（Basel III、C-ROSS、SARMRA、AML/KYC 等），这是与**适用辖区一致**的显式设计，而非默认路由偏好。
- **适用辖区**：内容基于**中国内地**监管框架——国家金融监督管理总局（NFRA）、中国人民银行、中国反洗钱监测分析中心的规则体系，以及巴塞尔协议 III、C-ROSS 偿二代二期在中国内地的落地口径。
- **不覆盖**：本技能**不提供**中国香港、中国澳门、中国台湾及境外司法辖区的监管规则解读；涉及境外机构、跨境业务或境外上市主体的合规判断，请转用对应辖区的专业口径或咨询当地合规意见。
- **术语对照**：正文中英并列仅为便于检索与对照，**判断依据始终以中文监管口径为准**；当英文术语的一般含义与中国监管定义不一致时，以后者为准。
- 用户使用其他语言提问时，本技能仍以中文输出为主，并保留关键术语原文，确保与监管口径一致。

---



## Core Thinking Models

### 模型一：全面风险管理框架（GRC模型）
```
传统风控：事后补救
智能风控：事前预防+事中监控+事后复盘
↓ 全面风险管理三道防线：
第一道：业务部门（风险识别第一责任）
第二道：风险管理部门（风险监测+控制）
第三道：内审/稽核（独立评价+改进建议）
↓
GRC整合：
G（Governance治理）+ R（Risk风险）+ C（Compliance合规）
→ 统一的风险视图
```

**举例（某城商行信贷流程）：** 第一道防线是支行客户经理，负责在贷前如实录入经营与财务信息并在贷后首次发现逾期苗头；第二道防线是总行风险管理部，设定行业限额、维护评分模型、按月出具预警名单；第三道防线是稽核部，每年抽查已放款项目是否按制度执行。三道防线的典型失效模式是"第二道替第一道干活"——风险管理部直接下场补录客户数据，导致第一道防线的责任被稀释，出险后无人可追。

**再举例（GRC 整合落地动作）：** 把合规检查发现的问题、风险监测发现的指标异常、内审发现的控制缺陷，统一映射到同一张风险地图上，按"风险事件—控制措施—责任部门"三元组管理，避免同一风险在三套台账里各记一遍、口径互不相同。


**再举例（三道防线的留痕分工）：** 同一笔逾期贷款，第一道防线留痕应为「贷后检查记录 + 首次发现日期 + 已采取的催收动作」，第二道防线留痕应为「预警名单生成时间与推送对象」，第三道防线留痕应为「抽样范围、发现问题与整改跟踪」。三套留痕在时间轴上应当首尾相接；若第二道的预警时间早于第一道的检查记录，通常说明第一道防线未实际履职。


### 模型二：风险分级预警矩阵（智能预警）
```
可能性（1-5）× 影响度（1-5）
↓ 四级预警：
1. 绿色（1-5）：正常运营
2. 蓝色（6-10）：关注，加强监测
3. 橙色（11-15）：预警，启动应急预案
4. 红色（16-25）：危机，立即处置
↓
智能触发：
实时数据 → 风险指标 → 自动预警 → 处置建议
```

**算例：** 某客户"主要账户资金归行率"骤降（影响度 4），同时出现多头授信（可能性 3），矩阵得分 4×3=12 → **橙色预警**，触发 72 小时内专项检查。若随后发生账户冻结（影响度 5）且实控人失联（可能性 4），得分 20 → **红色**，转为立即处置。

**反例：** 把"行业政策变化"这类影响度 2、可能性 5 的事件也设为红色阈值，会导致预警 flooding，真正的高危信号被淹没。建议对橙色及以上预警设置每日总量上限，超出部分按得分排序而非全部推送。


**再举例（预警的降级与关闭）：** 预警不能只进不出。某客户因资金归行率骤降触发橙色预警，专项检查后确认为季节性结算方式变更，应在系统中记录「降级理由 + 检查人 + 检查日期」后予以降级，并保留原始触发记录。缺少降级机制会导致预警池越积越大，最终无人处理；缺少关闭留痕则会在检查中被认定为预警未闭环。


### 模型三：信用风险评估模型（保险/银行适用）
```
保险：精算定价 → 核保风控 → 理赔管控
银行：贷前尽调 → 贷后监控 → 逾期处置
↓ 信用评分框架：
1. 还款能力（收入/资产/负债）
2. 还款意愿（历史信用/行为数据）
3. 外部环境（行业/地区/宏观）
综合评分 → 授信/定价/审批
```

**举例（制造业企业授信）：** 还款能力维度看经营性现金流对利息的覆盖倍数（<1.5 倍扣分）；还款意愿维度看历史逾期次数与征信查询频次（近 30 天查询 >6 次扣分）；外部环境维度看所属行业景气度。三者加权后若落在"中"区间，常见的正确动作不是简单拒贷，而是**降额 + 加担保 + 缩期限**。

**保险侧对照举例：** 核保风控同样遵循三要素——标的风险（对应抵押物/外部环境）、历史赔付（对应还款意愿）、持续缴费能力（对应还款能力）。差异在于保险更依赖群体统计规律，银行更依赖个体财务数据，因此保险评分卡的外部数据权重通常高于银行。


**再举例（同一客户在保险与银行侧评分不一致）：** 同一制造业企业主，银行侧因其经营性现金流覆盖倍数仅 1.2 倍而评为「中偏弱」；保险侧投保时因所处行业整体赔付率稳定、且其年龄与职业类别风险较低，核保结论为标准体。**这不矛盾**——银行评估的是个体偿债能力，保险评估的是群体统计下的标的风险。风控讨论中应明确「评的是什么风险」，避免把两套结论直接对比后得出错误判断。


### 模型四：反洗钱智能识别（AML/KYC）
```
传统AML：规则引擎（黑名单+阈值）
智能AML：AI识别（异常行为+关系图谱）
↓ 智能反洗钱体系：
1. 客户尽调（KYC）：身份核验+受益人识别
2. 交易监控（TM）：实时+批量双模式
3. 可疑上报（STR）：AI辅助+人工复核
4. 制裁筛查（Sanctions）：OFAC+联合国+NFRA
```

**举例（规则引擎漏掉的模式）：** 单一客户每月向 12 个不同个人账户转出 4.8 万元，均低于 5 万元大额阈值，规则引擎不告警；但把交易对手按关联图谱聚合后，实际是同一实控人控制下的资金归集与拆分——这正是"智能 AML"相对规则引擎的增量价值。

**再举例（降低误报）：** 纯规则引擎的可疑交易告警中，误报率常超过 90%，导致人工复核流于形式。可行做法是用 AI 模型对告警做二次排序，把"真可疑概率"最高的 5% 优先送人工，其余进入批量观察池，并在季度复盘时回检漏报。


**再举例（受益所有人穿透）：** 某客户股权结构为「自然人 A 60% + B 公司 40%」，B 公司又由自然人 A 持股 80%。若止步于第一层，会识别为两个独立股东；穿透后实际受益所有人为 A（合计 92%）。合格做法：向上穿透至自然人，记录持股比例、控制方式（股权/协议/家族关系）、信息来源（工商公示/年报/客户声明）与核实日期，并在股权变更时触发重检。


### 模型五：模型风险管理（算法风控）
```
模型风险：模型假设→数据质量→输出偏差
↓ 巴塞尔协议III+银保监要求：
1. 模型验证：独立团队+测试集验证
2. 模型文档：假设/变量/局限/退出机制
3. 模型审计：定期重检+重大事件触发
4. 人类决策：AI建议+人工终审
```

**举例（一次完整的模型风控留痕）：** 智能风控模型在 2026-03 上线，上线前由独立验证团队用 2025 年下半年样本做回溯测试，KS 值 0.42；2026-07 因客群结构变化，模型在测试集上的偏差达到 6.2%，超过 ±5% 阈值，触发应急机制：暂停自动决策、转人工审批、启动重训练，并将该事件记入模型台账。

**台账必备字段示例：** 模型名称与版本、用途与适用客群、训练数据时间窗、关键假设、已知局限、验证结论与验证方、上线审批人、监测指标与阈值、重大变更记录、退出条件。缺任何一项，监管检查时都构成


**再举例（偏差阈值的设定与校准）：** 「偏差超过 ±5% 触发应急」是常用起点，但阈值必须与实际业务影响挂钩：对自动审批类模型，KS 值下降 0.05 可能已显著改变通过率；对仅用于排序的模型，同样的下降影响有限。建议按模型用途分别设定阈值，并在台账中写明设定依据；用途变更时阈值必须重设，不能沿用。
"模型文档不完整"。

---

## 监管与市场动态

### 2026 版评估维度（v5.0 基线，截至 2026-05-31）
**Step 2 新增评估维度（2026）**：
- 金融大模型应用全景：50家银行已部署生成式AI，覆盖智能客服(85%替代率)/文档处理(70%效率提升)/风控决策(决策时效<3秒)三大场景
- 模型风险管理新规（2026年正式稿）：中国人民银行要求金融机构建立AI模型台账，重大模型变更须经独立第三方审计，模型偏差超±5%须启动应急机制
- 数据要素×金融：企业数据资产入表2026年扩展至金融机构，预期新增1.2万亿数据信贷规模，数据质量评分纳入央行评级体系
- 跨境金融科技监管沙盒：深圳/上海/北京三地同时推进，数字资产托管/AI跨境投顾/区块链供应链金融三类业务首批入盒
- 金融科技伦理委员会：国家金融监管总局2026年要求持牌机构设立AI伦理委员会，算法公平性/透明度/可解释性纳入年度评级

### 新动态（截至 2026-10-09）
- **AI 安全开发应用走向"成文制度"**：银行业保险业人工智能应用的安全开发要求正从原则性指导意见下沉为机构内部操作规程，普遍要求覆盖立项评估、数据合规、模型验证、上线审批、运行监测、退出机制六个环节，并明确责任部门与留痕要求。对应到本 Skill，即模型五（模型风险管理）需要落到可执行清单，而不停留在框架层。
- **模型风险从"验证"扩展到"持续监测"**：监管关注点由上线前的独立验证，前移至上线后的偏差监测与触发式重检；模型偏差阈值、重检触发条件、人工终审留痕成为检查重点。
- **反洗钱受益所有人信息要求细化**：客户尽调环节对受益所有人的识别与信息留存要求持续收紧，KYC 不再止于证件核验，还须说明股权控制链与信息来源。
- 以上为公开信息综述，**具体条文、生效时间与口径以中国人民银行、国家金融监督管理总局及中国反洗钱监测分析中心官方最新发布为准**。
- **模型风险管理从「有台账」转向「可验证」**：检查关注点已从是否建立台账，转向台账内容能否被独立复核——训练数据时间窗、验证样本区间、偏差阈值与触发记录、人工终审留痕是否互相印证。建议在模型台账中增加「验证可追溯」一栏，标明每次验证的样本区间与验证方。
- **智能风控的「人类决策」环节被单独检查**：AI 给出建议、人工作出终审这一链条，需要有可回溯的记录（谁、何时、依据什么、结论是什么）；仅有系统日志而无人工决策依据，常被认定为控制无效。
- 以上新增条目为公开信息综述，**具体条文、生效时间与口径以官方最新发布为准**。

---

## When to Use

- "怎么建立全面风险管理体系？" → GRC框架
- "怎么设计智能风险预警系统？" → 预警矩阵
- "客户信用评估怎么做？" → 信用评分模型
- "反洗钱合规怎么做？" → AML/KYC体系
- "模型风险怎么管？" → 算法风控
- "监管检查怎么准备？" → 合规检查清单

**完整提问示例：**
- "我们是一家寿险公司，偿二代二期下最低资本测算里市场风险占比偏高，帮我判断是资产久期问题还是权益敞口问题，并给出整改顺序" → 走模型一 + 模型五
- "某制造业客户营收下滑 25%、现金流为负、对外担保占净资产 60%，帮我判定风险等级和处置节奏" → 走 G.2 风险评分机制 + 步骤 4 处置预案
- "行里要上线一个 AI 反欺诈模型，帮我列出上线前需要准备的模型风险材料和上线后的监测指标" → 走模型五 + 新动态中的持牌机构操作规程要求


**不触发清单：** 诉讼代理与法律索赔、投资研究及标的推荐、精算定价模型的具体参数标定、个险产品的销售话术、境外辖区监管规则解读、纯 IT 系统运维。

**路由判定三步**：① 诉求是否为**识别、计量、监测或处置风险**（而非销售、投资或定价）？② 适用对象是否为中国内地持牌金融机构？③ 前两步均为是才启用本技能，否则转法律、投研、精算或对应辖区技能。


---

## 数据最小化与执行边界（Data Minimization & Execution Boundary）

**数据最小化前置声明（使用本技能前请先执行）**

1. 描述客户或风险事件时，使用角色代称（「某制造业客户 A」「某分行」），不要粘贴真实客户名称、证件号、账号、联系方式。
2. 不要粘贴未公开的财务数据、内部评级结果、监管报送底稿；如需讨论，用区间或比例描述（如「资产负债率约 88%」）。
3. 模型相关提问中不要包含真实训练样本、特征清单与生产接口地址。
4. 本技能不读取机构内部系统、征信接口、风控引擎；所有输入由使用者自行提供，输出仅回显在对话中。
5. 生成的清单、台账模板与代码如需落盘或报送，须先预览确认无敏感字段残留，再由责任人按机构流程办理。

**代码块性质与执行边界**

| 内容 | 性质 | 谁来执行 |
|------|------|---------|
| 风险评分卡、可疑交易检测等 Python 函数 | 简化示例，用于说明计算逻辑 | 使用者在自己的环境用脱敏数据运行，本技能不执行 |
| 阈值、权重、比例上限 | 通用起点或公开口径示例 | 使用者按本机构制度与监管口径校准 |
| 监测指标表、测试用例表 | 结构化清单 | 使用者对照本机构实际数据核 |
| 处置动作建议 | 分析性建议，不构成决策 | 风险处置委员会等有权机构 |

**硬边界**：不代为作出风险处置决策、不代为报送监管报表、不代为提交可疑交易报告、不访问或写入任何机构系统、不留存输入内容。

---



## Python Code Templates

### 风险评分卡模板
```python
def calculate_risk_score(credit_history, income_ratio, collateral, industry_risk):
    """
    简化风险评分卡
    返回: 评分和风险等级
    """
    weights = {"credit": 0.3, "income": 0.25, "collateral": 0.25, "industry": 0.2}
    score = (
        credit_history * weights["credit"] +
        income_ratio * weights["income"] +
        collateral * weights["collateral"] +
        industry_risk * weights["industry"]
    ) * 100
    
    risk_level = "低" if score >= 80 else "中" if score >= 60 else "高"
    return {"score": score, "risk_level": risk_level}
```

**调用示例与结果解读：**

```python
# 输入均按 0-1 标准化：0 表示最差，1 表示最好
result = calculate_risk_score(
    credit_history=0.85,   # 征信良好，无逾期
    income_ratio=0.40,     # 偿债收入比偏高
    collateral=0.70,       # 有厂房抵押，折率一般
    industry_risk=0.55,    # 所属行业景气度中性
)
# => {"score": 63.25, "risk_level": "中"}
```

解读：征信与抵押物把分数托到 63 分，但收入比一项就拖累了约 15 分。此时更合理的动作不是拒贷，而是**把额度压到收入比可承受的水平**——评分卡的价值在于指出"弱在哪一维"，而不只是给出一个总分。

**权重设定的注意点：** 上表权重（0.3/0.25/0.25/0.2）是通用起点，不是行业结论。实际使用时应当用本机构历史样本的违约率做回归校准，并至少每年重检一次；客群结构发生明显变化时必须重校准，否则会出现"分数没变但风险已经变了"的静默失效。

### 可疑交易检测模板
```python
def detect_suspicious(transactions, thresholds):
    """
    基于规则的异常检测
    """
    alerts = []
    for tx in transactions:
        if tx["amount"] > thresholds["large_tx"]:
            alerts.append({"type": "大额交易", "tx_id": tx["id"]})
        if tx["frequency"] > thresholds["high_freq"]:
            alerts.append({"type": "高频交易", "tx_id": tx["id"]})
    return alerts
```

**调用示例：**

```python
transactions = [
    {"id": "T001", "amount": 4_800_000, "frequency": 2},   # 超大额，触发
    {"id": "T002", "amount":   48_000, "frequency": 41},   # 高频，触发
    {"id": "T003", "amount":   49_000, "frequency":  3},   # 两项均不触发
]
thresholds = {"large_tx": 200_000, "high_freq": 20}
# => [{"type": "大额交易", "tx_id": "T001"},
#     {"type": "高频交易", "tx_id": "T002"}]
```

**为什么这个模板必须升级：** T003 单笔 4.9 万、频率 3 次，两个阈值都没碰到，但如果同一客户一天内发出 200 笔同金额交易（即常见的拆分规避），上面的函数一条都抓不到。生产环境中至少还要补三类检测：**结构化拆分**（同一对手方按时间窗聚合）、**关联图谱**（交易对手是否同实控）、**行为偏离**（与该客户自身历史基线比较），而不是只看绝对值阈值。

---

## Compliance Checklists

### NFRA偿二代二期合规
- 实际资本计算（核心/一级/二级资本）
- 最低资本要求（保险风险/市场风险/信用风险）
- SARMRA自评（风险管理能力评估）
- 压力测试要求

**举例（最低资本结构诊断）：** 某公司最低资本中市场风险占比 62%、保险风险 24%、信用风险 14%。结构本身说明资本占用主要来自资产端而非负债端，整改的优先顺序应是**先调资产久期与权益敞口**，而不是先动产品结构；若反过来先改产品，往往投入大而资本占用下降有限。

**SARMRA 自评常见失分点：** 制度写了但无执行留痕（如风险偏好陈述未经董事会审议）、风险限额设定后未监测突破情况、压力测试情景多年不变、自评打分与佐证材料不对应。建议按"制度—执行—留痕—佐证"四列准备，缺一列即视为该项未落地。

### 反洗钱合规清单
- 客户身份识别（KYC）
- 可疑交易报告（STR）
- 制裁名单筛查
- 年度合规评估

**举例（KYC 的合格与不合格）：** 仅留存营业执照与法人身份证复印件属不合格——缺少受益所有人识别与控制链说明；合格做法是向上穿透至自然人，记录持股比例、控制方式、信息来源与核实日期，并在股权结构变化时触发重检。

**STR 报送质量要点：** 可疑交易报告的常见问题是"只描述现象、不说明可疑理由"。合格的报告应写清三件事：交易行为与客户身份/经营规模的偏离点、排查过程与排除的合理理由、判定可疑的依据。仅写"交易异常，疑似洗钱"会被退回补充。

---

## Source Notes

- 巴塞尔协议III框架文件
- C-ROSS偿二代二期规则
- NFRA《保险偿付能力监管规则II》
- FATF反洗钱指引
- 中国人民银行《金融机构反洗钱规定》

---

## ClawHub Metadata

- **Slug**: finance-omni-risk
- **Tags**: 风险管理,智能风控,信用风险,操作风险,合规风险,C-ROSS,偿二代,反洗钱,AML,KYC,SARMRA,巴塞尔III
- **Version**: 5.0.2
- **License**: MIT
- **Author**: gechengling
- **ClawHub URL**: https://clawhub.ai/gechengling/finance-omni-risk

---

## 变更记录 / Changelog

| 版本 | 日期 | 变更摘要 |
|------|------|---------|
| 5.0.2 | 2026-10-09 | 新增「语言与适用辖区声明」章节，说明中文优先与适用辖区一致且不覆盖境外规则（SQP-3）；新增数据最小化前置声明与代码块性质/执行边界表及硬边界；新动态更新至 2026-10-09 并新增模型风险「可验证」、人类决策环节单查两条；模型一~五各补第三例；When to Use 补不触发清单与路由判定三步；新增列：取数难点与替代口径、留痕要求、常见口径争议、数据来源与更新频率；测试用例补 TC007/TC008；处置预案补节奏举例 |
| 5.0.1 | 2026-09-14 | 融合阿里点金贷后监测与大模型风险管理 |

---



## README (English)

**Financial Omni-Risk Control Officer** — Comprehensive risk management for banks, insurers, and securities firms. Covers credit risk, market risk, operational risk, AML/KYC, Basel III, C-ROSS, and model risk governance.

**Author**: gechengling | **License**: MIT

---

## 附录G：阿里点金(Dianjin)融合精华 — 贷后风险监测与大额暴露管理

### G.1 核心工作流程（Dianjin融合版）

#### 步骤1：贷后风险监测体系构建
| 监测维度 | 核心指标 | 预警阈值 | 常用数据来源 | 更新频率 | 易漏情形 | 取数难点与替代口径 |
|---------|---------|---------|------------|---------|---------|---|
| **财务指标** | 营收增速、净利率、现金流覆盖 | 营收下滑>20% 或 现金流为负 | 财报、税务、银行流水 | 季/月 | 报表滞后，出险时才看到上季数据 | 财报滞后时改用税务开票与银行流水做先行指标 |
| **经营行为** | 管理层变动、诉讼增加、动产抵押 | 董事长/总经理变更 或 新增诉讼>3起 | 工商公示、裁判文书、征信 | 月 | 关联公司出险未并入同一客户视图 | 关联公司需先并入同一客户视图再判断 |
| **融资行为** | 授信银行增加、发债利率上升 | 合作银行>10家 或 发债利率>同行业150bp | 征信、债券估值、同业交流 | 月/实时 | 表外融资与非标未纳入统计 | 表外与非标无统一口径，需按合同层面手工归并 |
| **担保圈** | 对外担保余额、互保金额 | 担保余额>净资产50% | 征信、年报附注 | 季 | 民间互保无公开记录，仅在代偿后暴露 | 民间互保无公开记录，可用代偿历史与本地访谈补充 |
| **舆情与合规** | 负面报道、监管处罚、欠税公告 | 重大负面或处罚金额超净资产1% | 舆情监测、监管公示 | 日 | 仅在爆发后被动获知，缺乏前置信号 | 前置信号弱，建议用行业与区域维度做组合监测 |

#### 步骤2：风险信号识别与分级
| 信号等级 | 信号类型 | 响应机制 | 留痕要求 |
|---------|---------|---------|---|
| **红色（紧急）** | 实控人失联、账户冻结、.batch诉讼 | 24小时内现场核查+风险预案 | 现场核查记录、影像、核查人与时间 |
| **橙色（重要）** | 评级下调、核心资产抵押、现金流恶化 | 72小时内专项检查+增信措施 | 专项检查报告、增信措施清单与落实时间 |
| **黄色（关注）** | 行业政策变化、高管频繁变动 | 按月跟踪+季报分析 | 跟踪台账、季度分析与是否升级的判断依据 |

#### 步骤3：大额风险暴露管理
| 管理要点 | 计算规则 | 监管要求 | 常见口径争议 |
|---------|---------|---------|---|
| **大额风险暴露** | 单一客户风险暴露/净资本 | ≤15%（商业银行） | 是否含表外、是否按集团口径合并，需先统一 |
| **关联方暴露** | 集团客户所有成员单位暴露之和 | ≤20%（商业银行） | 关联方认定范围是否与会计准则一致 |
| **全球系统重要性银行** | G-SIB附加资本要求 | 附加资本1-3.5% | 附加资本档位以最新评估结果为准 |

#### 步骤4：风险处置与预案
- **早期干预**：风险提示函、约谈高管、追加担保
- **中期处置**：压缩授信、诉讼保全、资产重组
- **后期清算**：核销准备、债转股、破产申请


**处置节奏举例：** 某客户触发橙色预警后的 72 小时内，正确顺序是：① 先完成现场或电话核实，确认信号真伪（避免基于错误数据启动处置）；② 同步冻结未使用额度并暂缓新增授信；③ 再评估增信可行性（追加担保、缩短期限、调整还款计划）；④ 最后才进入压缩授信或诉讼保全。**常见错误**是跳过核实直接压缩授信，把可挽回的客户推成实质违约。

---

### G.2 风险评分机制（Dianjin精髓）

| 风险维度 | 评分指标 | 权重 | 风险阈值 | 典型误判 | 交叉校验方式 | 数据来源与更新频率 |
|---------|---------|------|---------|---------|------------|---|
| 财务健康 | 资产负债率、现金流覆盖、利息保障倍数 | 30% | 资产负债率>85% | 高负债但现金充裕被误判为高危 | 用经营性现金流/流动负债交叉验证 | 财报、税务、流水；季/月 |
| 经营风险 | 行业地位、市场份额、技术壁垒 | 25% | 市场份额连续3季下滑 | 主动收缩低毛利业务被当成份额流失 | 结合毛利率变化判断是收缩还是衰退 | 行业数据、年报、调研；季 |
| 融资风险 | 授信银行数量、发债利率、非标占比 | 20% | 非标融资占比>30% | 集团统借统还被重复计入 | 合并口径去重后重算 | 征信、债券估值；月/实时 |
| 担保风险 | 对外担保/净资产、互保金额 | 15% | 对外担保>净资产50% | 关联方担保未穿透统计 | 按集团口径穿透后重算 | 征信、年报附注；季 |
| 合规风险 | 监管处罚、诉讼、欠税 | 10% | 重大违法违规记录 | 金额小但性质恶劣被低分放过 | 性质与金额双维度判定 | 监管公示、裁判文书；月 |
| ESG与舆情 | 环保处罚、安全事故、重大负面 | 5% | 重大环保或安全处罚 | 常被忽略，但可能直接导致停产 | 舆情日频监测 + 现场核查 | 舆情监测、环保公示；日 |

**综合风险等级**：
- 低风险（0-20分）：正常监测，季度例行检查
- 中风险（21-40分）：重点关注，双月专项检查
- 高风险（41-60分）：风险预警，月度跟踪+增信措施
- 极高风险（61-80分）：风险处置，周度监测+风险预案

> 权重已按六维度重分配（财务健康 30%、经营风险 25%、融资风险 20%、担保风险 15%、合规风险 10% 保持不变，新增 ESG 与舆情 5%，总分按加权折算至 0-80 区间），等级阈值维持不变。

**算例：** 某制造业客户资产负债率 88%（财务健康得 22/30）、市场份额连续 3 季下滑（经营风险 20/25）、非标融资占比 35%（融资风险 16/20）、对外担保占净资产 60%（担保风险 13/15）、无重大处罚（合规 2/10）、有一起环保处罚（ESG 3/5）→ 合计 76 分，**极高风险**，处置动作：周度监测 + 启动风险预案 + 追加担保。

---

### G.3 合规约束（Dianjin精髓）

1. **不适用边界**：本技能不适用于诉讼代理、法律索赔，此类需求需转交法律合规部门或外部律所
2. **禁止承诺**：不使用"一定收回贷款""guaranteed recovery"等承诺性表述
3. **禁止替代决策**：仅输出风险分析和处置建议，最终风险处置决策由风险处置委员会出具
4. **数据溯源**：风险数据、监测指标必须标注来源和日期
5. **隐私保护**：客户风险信息、内部监测报告必须保密
6. **客观中立**：分析不得受业务关系、绩效考核影响，须客观呈现风险

---

### G.4 测试用例（Dianjin精髓）

| 用例ID | 输入场景 | 预期输出 | 验证点 |
|--------|---------|---------|---------|
| TC001 | 监测某制造业客户，营收下滑25%，现金流为负，对外担保/净资产=60% | 综合风险等级高（评分55分），建议月度跟踪+追加担保 | 风险识别准确、建议合理 |
| TC002 | 某房地产客户，行业政策收紧，评级下调至BBB-，发债利率上升200bp | 综合风险等级极高（评分70分），建议周度监测+风险预案 | 预警及时、预案可行 |
| TC003 | 某地方政府平台，财政收入下滑30%，债务率180%，再融资困难 | 综合风险等级极高（评分75分），建议启动风险处置程序 | 风险判断准确 |
| TC004 | 某医药流通企业，资产负债率88%但经营性现金流为正，无对外担保 | 综合风险等级中（评分38分），不宜简单下调评级，建议关注短债占比 | 避免单一指标误判 |
| TC005 | 某客户的智能风控模型上线4个月后偏差达6.2% | 触发模型应急机制：暂停自动决策+转人工+启动重训练，并记入模型台账 | 模型风险监测有效 |
| TC006 | 单一客户每月向12个个人账户各转4.8万元 | 规则不告警但图谱聚合后判定可疑，建议提交人工复核 | 拆分规避识别能力 |
| TC007 | 某客户智能风控模型的台账缺「验证样本区间」一栏 | 判定为模型文档不完整，需补验证方、样本区间与结论，并补记本次补充的责任人与日期 | 模型文档完整性检查 |
| TC008 | 某橙色预警客户经专项检查确认为季节性结算变更 | 记录降级理由、检查人与日期后降级，保留原始触发记录，不直接删除 | 预警闭环与降级留痕 |

---

### G.5 关联技能（Dianjin精髓）

- **银行信贷尽调**（`bank-credit-investigation`）：提供借款人画像、财务分析、风险识别
- **银行监管报告**（`bank-regulatory-reporting`）：提供最新监管政策解读和合规要求
- **金融全场景风控**（`finance-omni-risk`）：本技能，提供行业风险量化模型和预警指标

---

*融合来源：阿里点金(Dianjin) credit-risk-manager/loan-risk-monitor*
*融合时间：2026-05-31*
*最近更新：2026-10-09（v5.0.2）*