submit-credit-application

name: submit-credit-application description: > 授信申请提交辅助技能。自动盘点客户档案中的笔记与材料,对照银行贷前尽调材料标准评估完备性,检查案件冲突与授信到期状态,生成结构化评估报告并引导客户经理确认提交。当用户需要提交授信申请、发起审批流程、续贷申请、追加授信或评估材料是否齐全时使用此技能。触发词包括:"提交授信申请"、"发起审批"、"submit credit"、"续贷申请"、"追加授信"、"评估材料"、"授信申请提交"、"发起授信流程"。不适用于:贷后管理、风险分类调整、不良资产处置、授信审批决策、或无具体客户背景的泛泛咨询。 target_role: 对公客户经理、信贷审批官 business_domain: 对公业务 > 信贷管理 > 授信审批 risk_level: high version: 2.0.0 status: draft data_sources: - 客户笔记(尽调报告、拜访记录、走访小记) - 客户材料(营业执照、财务报表、银行流水、担保材料) - 案件状态(信贷系统案件管理模块) - 授信台账(现有授信额度、到期日、使用情况) upstream_skills: - credit-due-diligence - visit-memo - financial-report-analysis - equity-penetration-analysis - credit-industry-analysis downstream_skills: - credit-approval-decision

提交授信申请（Submit Credit Application）

当用户要求提交授信申请时，按以下流程执行。

目标角色 (Target Role)

• 角色：对公客户经理、信贷审批官
• 使用场景：新客户首贷申请、存量客户续贷、追加授信申请
• 输出用途：评估材料完备性，引导客户经理确认提交，发起授信审批流程
• 决策层级：授信审批前置环节，直接影响案件是否进入审批流程
• 执行频率：每次授信申请前执行一次

数据接入 (Data Sources)

必需数据

数据脱敏规则

• 客户身份证号：显示前3后4，中间用 * 替代
• 银行账号：仅显示后4位
• 案件编号：完整展示（内部流转需要）
• 授信金额：完整展示（审批决策需要）
• 客户商业机密信息（如核心客户名单）：在评估报告中使用“某客户”代替

降级策略

• 如果信贷系统影像档案不可用：标注“客户笔记和材料未核验”，基于用户提供的信息继续评估
• 如果案件状态查询超时：标注“案件冲突未核查”，提示用户手动确认无活跃案件
• 如果授信台账不可用：标注“授信到期状态未知”，由用户确认案件类型（续贷/新增/追加）
• 如果历史尽调报告不可用：标注“尽调报告缺失”，提示用户上传或补充

约束条件 (Constraints)

监管依据:《商业银行授信工作尽职指引》、《贷款风险分类指引》、 《商业银行法》第35条贷款审查要求、银监会《流动资金贷款管理暂行办法》

1. 严格确认前置:未获用户明确确认,禁止发起案件创建,无论材料是否充分
2. 材料评估独立判断:完备性评估基于材料实质内容,不得以“材料数量充足”代替“内容质量达标”
3. 案件冲突不覆盖:同一客户存在活跃审批案件时,禁止重复提交,须向用户提示冲突
4. 不确定性显式告知:材料存疑或缺失时须向用户明确告知,不得主观判断“可能不重要”而跳过
5. 案件类型不猜测:续贷与新增授信类型须由用户确认,不得根据客户历史记录自动推断
6. 拒绝越权判断:不对审批结果做预测(如“这个应该能批”),聚焦材料完备性
7. 数据溯源:材料评估须注明每项材料的来源、上传日期、有效期状态
8. 禁止跳过步骤:不得跳过步骤0(数据验证)和步骤1(案件冲突检查),必须确认无活跃案件后方可继续
9. 红线执行强制:如触发任何红线(R1-R3),必须立即停止生成并提示用户

金融合规红线(一票否决)

以下情况须立即停止提交并提示用户:

• R1:必备材料缺失(尽调报告、拜访记录、财务资料、营业执照)
• R2:存在活跃审批案件(防止重复提交)
• R3:用户未明确确认提交(禁止静默提交,“好的”等模糊表述不得判定为确认)

授信申请材料清单（评估基准）

以下为银行贷前尽调的标准材料体系，完备性评估的依据。材料分三级：必备（缺失则建议暂缓）、建议（缺失须向用户提示）、补充（有则更优）。

对接提示：材料盘点能力映射至贵行客户档案查询接口，返回字段须含：材料类型、文件名、上传日期、状态（有效/过期/待审）

执行流程 (Workflow)

交互模式:模式 B - 步骤门控型(Step-Gated)

当用户要求提交授信申请时,按以下流程执行:

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

1. 列出所有输入数据源:客户笔记清单、客户材料清单、案件状态、授信台账
2. 确认数据时间范围:尽调报告日期、财务报表期间、拜访记录时间跨度
3. 确认案件类型意图:续贷/新增/追加
4. 运行验证脚本: python scripts/validate_application.py --check-materials --check-conflicts
5. 验证通过后进入步骤1;验证失败则输出缺失清单,要求用户补充

📋 数据来源:system_api(信贷系统影像档案、案件管理、授信台账) 📋 执行主体:ai 📋 确认机制:none ⚠️ 强制指令:不得跳过数据验证步骤,必须确认所有输入数据的有效性

步骤 1:前置状态核查

门控步骤:此步骤不通过不得进入后续流程

案件冲突检查

• 查询该客户是否存在处于“审批中/待补件/待签约”状态的活跃案件
• 门控分支:
  • ✅ 无活跃案件 → 进入授信到期检查
  • ❌ 存在活跃案件 → 立即停止,向用户告知冲突,提示现有案件编号和当前状态,询问是否需要撤销或继续等待,不进入后续流程
  • ⚠️ 查询超时 → 标注“案件冲突未核查”,提示用户手动确认无活跃案件,用户确认后方可继续

📋 数据来源:system_api(信贷系统案件管理模块) 📋 执行主体:ai 📋 确认机制:approve(存在冲突时必须用户明确决策)

授信到期检查

• 核查该客户现有授信额度的到期日,判断本次申请是续贷(到期前90天内)还是新增授信
• 自动标注建议案件类型,提交确认时向用户展示

📋 数据来源:system_api(核心系统授信模块) 📋 执行主体:ai 📋 确认机制:none

步骤 2:材料盘点

• 枚举客户笔记:列出该客户的所有已有笔记(尽调报告、拜访记录、走访小记等)及摘要
• 枚举客户材料:列出该客户已上传文件和已发布材料清单
• 必须读取关键笔记或材料内容,了解材料的实质内容(而非仅确认文件存在)
• 对照references/material-checklist.md中的材料清单逐项核对

📋 数据来源:system_api(信贷系统影像档案) 📋 执行主体:ai 📋 确认机制:none ⚠️ 强制指令:不得仅统计文件数量,必须检查实质内容(如尽调报告须包含经营分析和财务分析)

步骤 3:完备性评估

基于盘点结果,对照授信申请材料清单(见references/material-checklist.md)逐项判断:

评估展示格式

材料完备性评估结果:

✅ 已具备(必备)
  - 尽调报告(2024-01-15,含经营分析和财务分析)
  - 拜访记录(近3个月共2次,有实质经营信息)
  - 财务资料(2021-2023年三年数据)

⚠️ 建议补充
  - 银行流水(仅有3个月,建议补充至6个月)

❌ 缺失(必备材料)
  - 营业执照(档案中未见,请上传)

综合评估:[可以提交 / 建议补充后提交 / 暂缓提交]
原因说明:[1-2句话说明评估依据]

评估判断标准

• 可以提交:必备材料全部齐全,内容质量达标
• 建议补充后提交:必备材料齐全但“建议”类材料有缺失,向用户告知风险后由用户决定
• 暂缓提交:必备材料有缺失,明确建议用户先补充
• 门控分支:
  • ✅ 评估为“可以提交”或“建议补充后提交” → 进入步骤4
  • ❌ 评估为“暂缓提交” → 触发红线R1,立即停止,向用户展示缺失项,建议先补充材料
  • ⚠️ 材料存疑 → 标注存疑项,向用户说明具体情况,由用户决定是否继续

📋 数据来源:context(步骤2盘点结果) 📋 执行主体:ai 📋 确认机制:inform(评估结果须向用户展示)

步骤 4:案件类型确认

• 优先根据步骤1中授信到期检查的结论自动判断
• 有歧义时询问用户确认,不得做假设
• 门控分支:
  • ✅ 案件类型明确 → 进入步骤5
  • ⚠️ 有歧义 → 询问用户确认,用户确认后方可继续

📋 数据来源:context(步骤1检查结果 + 用户输入) 📋 执行主体:ai 📋 确认机制:inform(向用户展示并确认)

步骤 5:确认提交

门控步骤:此步骤不通过不得发起案件创建

• 向用户展示评估结果和建议案件类型
• 如果材料充分:建议提交,询问用户确认(“是否确认提交?”)
• 如果有缺失:告知缺失项和影响,由用户决定是继续提交还是先补充材料
• 用户确认门控:
  • ✅ 用户明确说“提交”或“确认” → 发起案件创建
  • ❌ 用户说“先不提交”或“等一下” → 终止流程,不创建案件
  • ⚠️ 用户说“好的”等模糊表述 → 不得判定为确认,须再次明确询问“是否确认提交?”

📋 数据来源:context(步骤3评估结果) 📋 执行主体:ai 📋 确认机制:explicit(必须用户明确确认) ⚠️ 红线R3:未获用户明确确认,禁止发起案件创建,无论材料是否充分

输出格式 (Output Format)

本输出可被 credit-approval-decision Skill 解析使用

使用 assets/credit-application-template.md 模板。评估报告必须包含以下6个章节:

数据标注要求:所有数据标注:数据来源 + 数据日期 + 是否最新数据。

免责声明:输出末尾必须附加免责声明,引用 shared/disclaimer-template.md 模板,确保包含“本评估仅基于提供的材料进行完备性检查,不构成授信审批建议”等必要声明。

审计追踪 (Audit Trail)

每次授信申请提交结束后，生成审计日志 audit/{客户简称}_{日期}_audit.json：

{
  "skill_name": "submit-credit-application",
  "skill_version": "1.0.0",
  "execution_time": "2026-05-05T10:30:00+08:00",
  "input_params": {
    "customer_name": "XX企业",
    "application_type": "renewal/first_credit/additional",
    "application_amount": 50000000
  },
  "operator": "客户经理姓名（工号：XXX）",
  "steps": [
    {
      "step": "前置状态核查",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "信贷系统案件管理模块"},
      "result": "pass",
      "conflict_detected": false
    },
    {
      "step": "材料盘点",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "信贷系统影像档案"},
      "result": "pass",
      "materials_found": 8,
      "materials_missing": 1
    },
    {
      "step": "完备性评估",
      "executor": "ai",
      "data_source": {"type": "context"},
      "result": "pass",
      "assessment": "建议补充后提交"
    },
    {
      "step": "确认提交",
      "executor": "ai",
      "data_source": {"type": "context"},
      "confirmation": {"type": "explicit", "confirmed_by": "客户经理姓名（工号：XXX）", "confirmed_at": "2026-05-05T10:35:00+08:00"},
      "result": "pass",
      "case_id": "CASE-2026-001234"
    }
  ],
  "red_line_triggered": [],
  "warnings": ["银行流水仅有3个月，建议补充至6个月"],
  "references_used": ["references/material-checklist.md"]
}

踩坑记录 (Gotchas)

#1：材料数量充足但质量不达标

• 症状：尽调报告仅1页，缺少经营分析和财务分析，但系统判定“已具备”
• 原因：仅统计文件数量，未检查实质内容
• 解决：必须读取关键材料内容，验证是否包含必要分析维度（企业基本情况、经营分析、财务分析、还款来源）

#2：案件冲突未检测到

• 症状：同一客户存在两个活跃审批案件，导致审批流程混乱
• 原因：案件状态查询接口超时，未触发降级策略
• 解决：查询超时必须标注“案件冲突未核查”，提示用户手动确认

#3：用户未明确确认就提交

• 症状：用户说“好的”，系统即判定为确认提交
• 原因：确认机制不严格，“好的”可能是对评估结果的认可，而非提交指令
• 解决：必须用户明确说“提交”或“确认”后才可发起案件创建

#4：案件类型推断错误

• 症状：用户说“续一下”，系统判定为续贷，但实际是追加授信
• 原因：未结合授信到期检查结论，仅凭用户口语判断
• 解决：优先根据授信到期检查结论自动判断，有歧义时询问用户确认

#5：必备材料缺失仍建议提交

• 症状：营业执照缺失，但评估结论为“可以提交”
• 原因：未严格执行红线R1（必备材料缺失）
• 解决：必备材料（尽调报告、拜访记录、财务资料、营业执照）缺失必须触发红线，建议“暂缓提交”

示例 (Examples)

示例1：标准续贷提交

用户输入：

请为XX制造企业的续贷申请提交授信申请。客户授信5000万将于2026-06-15到期，需要续贷。

Skill 执行流程：

1. 前置状态核查 → 无活跃案件，授信到期前41天，判定为续贷
2. 材料盘点 → 尽调报告、拜访记录、财务资料齐全，银行流水仅有3个月
3. 完备性评估 → 必备材料齐全，建议类材料有缺失，评估为“建议补充后提交”
4. 用户确认 → 用户明确说“提交”，发起案件创建
5. 提交成功 → 返回案件编号 CASE-2026-001234

输出要点：

• 综合评估：建议补充后提交
• 缺失项：银行流水（仅有3个月，建议补充至6个月）
• 案件类型：续贷（renewal）

示例2：首次授信提交（触发红线）

用户输入：

为新客户YY贸易公司提交首次授信申请。

Skill 执行流程：

1. 前置状态核查 → 无活跃案件，无现有授信，判定为新增授信
2. 材料盘点 → 尽调报告缺失，营业执照缺失
3. 完备性评估 → 触发红线R1（必备材料缺失），评估为“暂缓提交”
4. 用户告知 → 告知缺失项和影响，建议先补充材料
5. 用户决定 → 用户说“先补充材料”，终止提交

输出要点：

• ⚠️ 红线触发：R1（必备材料缺失）
• 缺失项：尽调报告、营业执照
• 综合评估：暂缓提交

非功能范围 (Out of Scope)

• 本 Skill 不处理授信审批决策，仅提供材料完备性评估
• 本 Skill 不生成尽调报告或拜访记录（请使用 credit-due-diligence 或 visit-memo Skill）
• 本 Skill 不直接修改客户数据或提交审批结果
• 本 Skill 不处理个人信贷/零售业务
• 本 Skill 不处理贷后管理、风险分类调整、不良资产处置
• 如果用户请求以上内容，明确告知并建议合适的 Skill 或联系相应部门