文档

• 1: 智慧信贷
  • 1.1: 业务架构
    • 1.1.1: 业务架构总览
    • 1.1.2: 授信模式
    • 1.1.3: 架构图集
      • 1.1.3.1: 业务架构总览图
      • 1.1.3.2: 授信模式体系
      • 1.1.3.3: 额度体系
      • 1.1.3.4: 客户管理体系
      • 1.1.3.5: 押品管理体系
      • 1.1.3.6: 产品管理体系
    • 1.1.4: 额度体系
    • 1.1.5: 客户管理体系
    • 1.1.6: 押品管理体系
    • 1.1.7: 产品管理体系
    • 1.1.8: 业务架构成果汇报（V1.4）
  • 1.2: 应用架构
    • 1.2.1: 应用架构设计
  • 1.3: 技术架构
    • 1.3.1: 技术架构设计
  • 1.4: 集成架构
  • 1.5: 部署架构
    • 1.5.1: 部署架构设计
  • 1.6: 非功能需求
• 2: 投资代销
• 3: 金融市场
  • 3.1: 新一代资金交易管理系统架构总览
  • 3.2: 新一代资金交易管理系统数据移植方案
  • 3.3: 配合系统建设架构方案
  • 3.4: 新资金交易管理系统适配改造方案
• 4: 资产托管
  • 4.1: 资产托管运营驾驶舱业务架构说明书
• 5: 风险防控
  • 5.1: 受害人精准拦截业务需求
  • 5.2: 受害人精准拦截技术实现方案
• 6: 市场风险
  • 6.1: 数据接口 ESB 化实施方案
• 7: AI
  • 7.1: 综合智慧信贷
    • 7.1.1: 智能信审平台业务架构
    • 7.1.2: 综合智慧信贷 AI 架构方案
    • 7.1.3: 智能信审平台需求文档
      • 7.1.3.1: 总体概述
      • 7.1.3.2: 业务架构与端到端流程
      • 7.1.3.3: 悬浮按钮与任务管理
      • 7.1.3.4: 风险检查（小查）
      • 7.1.3.5: 类案对比（小审）
      • 7.1.3.6: 审查报告
      • 7.1.3.7: 智能审核（小核）
      • 7.1.3.8: 评价分析
      • 7.1.3.9: 对外交互方案
      • 7.1.3.10: 10 财务风险分析
    • 7.1.4: 财务风险分析系统详细设计与实施方案
  • 7.2: 星辰智能
    • 7.2.1: VLAgent 智能文档识别平台架构解读
    • 7.2.2: 结算类凭证要素核验需求规格说明书
    • 7.2.3: 智能文档识别平台规划方案
    • 7.2.4: 智能文档识别平台建设实施计划与详细方案
    • 7.2.5: StarWork 桌面端技术架构
    • 7.2.6: StarWork 云控服务端技术架构
• 8: 其他
  • 8.1: 简介
    • 8.1.1: 项目概览
    • 8.1.2: 架构
  • 8.2: 快速上手
    • 8.2.1: 前置条件
    • 8.2.2: 安装
  • 8.3: 教程
    • 8.3.1: 完成第一次修改
    • 8.3.2: 添加文档页面
  • 8.4: 参考
    • 8.4.1: 配置
    • 8.4.2: 命令参考

1 - 智慧信贷

智慧信贷项目按架构视角组织文档：

• 业务架构：业务建模成果与五大体系架构图集
• 应用架构：应用划分与服务依赖
• 技术架构：技术选型与关键技术决策
• 集成架构：接口、上下游依赖与数据流
• 部署架构：环境与部署拓扑
• 非功能需求：性能、安全等质量属性要求

1.1 - 业务架构

智慧信贷项目的业务架构文档，覆盖业务建模、领域划分与五大体系设计。

• 业务架构总览：三类领域、11 领域 40 组件 68 能力 33 对象的架构基线
• 授信模式：五类授信模式的组织方式、授用信关系与额度管控差异
• 额度体系：额度分类组织、双维度管控、生命周期及双占多占机制
• 客户管理体系：统一客户主体、关系网络、管户责任与统一视图
• 押品管理体系：押品五层结构与从准入到解押退出的连续管理
• 产品管理体系：五级产品目录、组件化配置与四维状态运营管控
• 业务架构成果汇报（V1.4）：新一代口径 19 领域 23 组件，额度/集团/授信作业三大重构与风控引擎升级
• 架构图集：五大体系的交互式架构图

1.1.1 - 业务架构总览

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》提炼。智慧信贷二期业务架构基线形成 11 个业务领域、40 个业务组件、68 项核心业务能力和 33 项核心业务对象，对公信贷和个人信贷作为两类主要端到端业务场景，专项业务和关联专业能力通过明确协作关系与核心业务架构衔接。

总体结构：三类领域

专业对象管理领域负责客户、产品、担保与押品、额度等跨阶段核心对象的持续管理；公共管理横向提供政策计划、外部信息、影像档案、知识、作业协同、台账报表和费用等公共服务。对公信贷和个人信贷不作为独立业务领域，而是分别形成端到端业务场景，贯穿六个生命周期领域，并在业务过程中调用专业对象、公共管理及关联专业能力。

11 领域与 40 组件

一个业务组件只具有一个主要业务领域归属，跨领域依赖通过业务协作表达，不复制相同责任：

组件是否独立成立取决于稳定责任、对象或事项、规则及生命周期边界，不取决于组织、系统或总览图展示颗粒度。

68 项核心业务能力

业务能力表达"银行持续需要会做什么"，全部唯一归属一个主责业务组件。代表性归属：授信额度管理承载额度结构、生命周期、统一视图、调账四项能力；限额管理承载集中度与国别限额；尽职调查作业管理承载现场/非现场调查、尽调资料、尽调报告；放款管理承载放款申请、贷款发放、受托支付。总览图或流程图中的多个步骤可归属于同一组件下的不同能力；同一场景中被调用的能力不因发生位置变化而改变主责组件。

33 项核心业务对象与端到端对象链

核心业务对象按稳定身份、主要信息、业务规则和生命周期确定唯一主责组件。并非每个组件都拥有独立核心对象——部分组件围绕业务事项或公共服务承担责任，其对象作为其他主对象的状态、属性或过程信息存在。主要对象：客户、客户群组、供应链、客户关联关系、目标客户清单、同业准入名单、产品、产品条件、担保协议、抵质押品目录、抵质押品、押品资产池、价值评估、权证、押品分配关系、授信额度、限额方案、营销方案、信贷调查资料、授信/贷款申请、授信方案、授信批复、贷款协议、放款协议、放款执行证据、还款计划、信贷经营政策与计划、客户征信授权、外部信用信息、征信业务关联、信贷费用。

对象关系描述端到端信贷业务的形成过程，但不改变唯一主责：

客户提出授信/贷款申请 → 尽调资料支撑授信方案形成 → 方案经审查决策形成授信批复 → 额度管理依据批复建立/调整授信额度 → 需要缓释时通过担保协议和押品分配关系建立价值使用关系 → 批复条件在签约阶段落实为贷款协议 → 满足用信条件后形成放款协议和放款执行证据 → 进入还款计划和后续履约管理

客户、产品、授信额度、抵质押品等专业对象在上述各阶段被持续复用，被其他领域使用不改变其主责组件。

端到端场景与协作

对公与个人信贷均贯穿业务准备、尽职调查、授信申请、审查审批、签约放款、贷后管理六个生命周期领域，差异体现在各阶段的活动组合上：业务准备阶段对公以线下受理与主动授信为主、个人以渠道进件为主；尽职调查阶段客户准入和尽调作业为本阶段主责，征信、评级等结果作为协作输入。场景在稳定责任结构之上组合组件和能力，表达实际端到端业务如何运行。

关联专业能力与系统边界

客户评级、风控引擎、资产保全、风险驾驶舱等关联专业能力由行内其他系统承接，通过明确协作关系与核心业务架构衔接（如尽调阶段引用评级结果、审查审批调用风控引擎、贷后与资产保全衔接）。贷后管理领域保留在业务架构基线内；上述范围决策属于系统实施边界，不改变业务架构的责任结构。

全景可视化见业务架构总览图；五大体系的详细设计见授信模式、额度体系、客户管理体系、押品管理体系、产品管理体系。

1.1.2 - 授信模式

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第六部分。授信模式表达不同客户类型和业务场景下，授信申请、方案形成、审查审批、批复、额度建立以及后续用信之间如何组合运行，不改变已确定的业务领域、业务组件及其主责关系。

总体结构

各类授信模式共享统一的信贷生命周期责任，按需调用客户、产品、额度、押品、公共管理及关联专业能力。模式之间的差异集中在四个维度：

• 以什么对象组织一次授信（客户 / 集团 / 单笔业务 / SPV）；
• 授信时形成到什么业务层级（授信方案 / 业务方案 / 单笔批复）；
• 授信与具体用信在何时衔接（授用信合一 / 授用信分离）；
• 需要接受哪些上层或关联额度约束（客户总量 / 集团总量 / 分组 / 预留额度）。

单一对公客户统一授信

以客户作为统一授信组织单元。一次授信可同时形成综合授信额度、专项授信额度和非授信额度中的一种或多种授信安排，在同一客户维度形成统一的授信方案和额度视图，改变按单一产品逐笔割裂管理的方式。

核心机制：

• 授信方案与业务方案分层：授信方案确定客户整体授信结构（类型、层级、金额、期限、条件）；需要提前明确具体业务的分项，在最末级额度下维护业务方案（项目、产品使用方式、担保安排等）。一个最末级额度可对应多个业务方案。
• 授用信合一：授信阶段能明确用信的场景，同时形成额度安排和业务方案；仅核定额度的业务，具体信息留待合同或用信环节落实。
• 单笔单批为补充：贴现、委托贷款等特定业务可单笔单批作业，但不形成独立于统一授信之外的客户额度体系——单笔信用安排仍进入客户统一额度视图，接受客户总额度等管控。

集团客户统一授信

以客户关系管理中维护的集团成员关系为基础，将集团整体风险识别、成员授信需求、集团总额度和成员额度使用纳入统一管理。集团可包含对公、同业及符合管理要求的个人客户，成员保留自身授信模式，在集团层接受统一约束。

组织方式：集团主办责任统一组织，成员形成各自的授信方案，主办、协办协同汇总为集团整体授信申请，形成"集团整体信用判断 → 集团总额度及管控结构 → 成员授信方案 → 成员具体业务办理"的分层模式。

管控机制：集团成员可按成员、经营机构或业务板块分组，分组额度限制特定成员集合对集团信用资源的使用；预留额度为新增成员或新增融资需求保留可调配空间。集团额度不足时通过集团授信变更、续作或预留额度领用调整，不允许绕开集团管控单独扩大成员授信。

同业客户授信

同一金融机构相关授信业务纳入统一客户信用管理，但与对公不同，采用授用信分离模式：授信阶段形成客户授信方案和额度安排，票据、贸易融资、金融市场等具体业务在后续专业交易场景中根据有效额度办理。

同业授信额度按专项业务和风险等级组织，适配不同专业业务的风险特征；授信审批确定客户信用风险边界，额度管理持续维护风险资源，交易场景按额度映射和风险等级规则调用。模式概括为：统一客户授信 + 专项风险额度 + 专业业务用信。

个人信贷作业模式

继续以单笔业务授信为主要作业模式：围绕具体融资申请开展准入、调查、申请、审查、审批、批复、合同签订和放款，每笔业务形成业务批复和单笔业务额度。个人不存在对公式的客户维度统一授信方案；预授信、线上转人工、模型审批属于获客和审批路径变化，不改变单笔授信的基本单元。

客户层仍形成统一额度和风险视图：单笔批复额度按客户汇总，结合个人客户总限额、信用限额和保证限额等风险边界控制新增业务，实现"业务逐笔审批、客户统一看险"。依赖合作项目、合作方或集群的业务，同时受项目额度、合作方额度或集群额度约束；个人经营贷涉及集团客户时纳入集团统一授信管控，形成"个人单笔业务额度 + 项目/合作方/集群额度 + 集团额度"的多层约束。

SPV 及专项授信

对 SPV 等特殊目的载体或特定投资对象，以具体 SPV 或投资对象为独立管理单元核定投资或业务额度。授信过程除识别 SPV 本身及底层资产外，还识别担保人、差额补足人、管理方、增信方等相关主体，并在后续投资或用信时关联其信用资源。SPV 授信仍经过申请、审查审批和批复等通用责任，但额度对象和用信方式按专项业务特点组织，不并入普通对公客户统一授信结构。

与核心业务架构的关系

授信模式是稳定业务架构在不同业务场景中的组合表达：不同模式不重新划分业务责任，而是在统一业务架构上，根据客户类型、授信组织方式和额度管理要求形成不同的端到端业务组合。

1.1.3 - 架构图集

本栏目收录《智慧信贷项目业务架构说明书》的交互式架构图，由 archify 生成。图内支持缩放拖拽、语义视图切换、关系追踪与 PNG/SVG 导出。

• 业务架构总览图：三类领域与生命周期主干的全景
• 授信模式体系：五类授信模式与统一责任链的映射
• 额度体系：授信金额与敞口双维度的额度树与占用控制
• 客户管理体系：统一视图与专业责任划分
• 押品管理体系：押品全生命周期五层结构
• 产品管理体系：五级产品目录与状态运营机制

需要在一个页面内对照浏览全部图集时，可打开 图集总览入口。

1.1.3.1 - 业务架构总览图

依据《智慧信贷项目业务架构说明书》第四部分绘制的业务架构全景：专业对象管理、信贷生命周期、横向公共管理三类领域共同构成智慧信贷业务架构，对公与个人信贷作为端到端场景贯穿六个生命周期阶段。

全屏打开 ↗

1.1.3.2 - 授信模式体系

授信模式体系回答"同一套责任链如何承载不同风险特征的业务"：五种授信模式在申请受理、方案设计、批复、额度管控与用信放款各环节各有差异，前端模式差异化、底层链路统一，最终落到最末级额度与业务方案的共用机制上。

全屏打开 ↗

1.1.3.3 - 额度体系

额度体系以授信金额与敞口双维度管控为核心：额度树向下延伸到最末级额度并挂接业务方案，向上承接集团客户总量、分组与预留额度管理，用信环节实施额度双占多占控制，对公授用信合一、同业授用信分离。

全屏打开 ↗

1.1.3.4 - 客户管理体系

客户管理体系以客户统一视图为核心：面向客户的身份、关联、评级、押品等信息集中展示，而各专业条线的管理责任分别落实，形成"集中展示、分别管理"的协同结构。

全屏打开 ↗

1.1.3.5 - 押品管理体系

押品管理体系按五层结构组织：准入规则、押品主体、价值与缓释、权利落实、持续监控。核心缓释公式为"有效担保价值 = 认定价值 × 适用抵质押率"，抵质押率按产品差异化取用。

全屏打开 ↗

1.1.3.6 - 产品管理体系

产品管理体系维护产品线→产品组→基础产品→可售产品→组合产品的五级目录，实行四维状态管理与停用/暂停/停牌三档运营机制，不良率超限时自动触发停牌。

全屏打开 ↗

1.1.4 - 额度体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第七部分、《额度体系方案 v0.2（汇报版）》与《业务需求说明书·额度中心分册 V1.2》（2026-10-13）提炼。额度是授信决策向业务执行传递信用风险边界和业务资源约束的核心业务对象——授信审批回答"是否给予信用、给予什么条件"，额度管理则将批复结果转化为可持续查询、校验、占用、释放和调整的业务资源。额度中心为全行额度管理、风险管理及业务办理人员提供统一额度能力，管理个人、对公、同业、集团及 SPV、集群额度，支撑额度建立、启用、占用、释放、冻结解冻、失效及限额检查；业务系统负责发起业务和传送处理请求，额度中心按相应规则执行并返回结果。上图（V0.2）呈现三大核心机制：对公额度树与超额/等额切分、同业风险等级串用、集团三层结构与两级分组。

额度分类与对象结构

基于统一授信管理要求，额度分为主体类额度（集团客户、对公客户、同业客户、个人客户四类主体）与非主体类额度（集群额度、SPV 额度等场景类）。额度体系中每类客户均形成"总额度 → 母行额度 / 并表机构额度 → 授信大类 → 额度分项 → 产品额度"的树形结构，并区分两类节点：

• 实体额度：授信报批形成的额度，参与占用控制；
• 分类额度：仅用于统计汇总（含反向汇总生成的管理额度），不直接控制。

额度生成有两种方式（V1.2 明确）：授信审批生成——批复确认或批复发布时经【单一客户额度建立】【集团客户额度建立】【集群额度建立】【SPV 额度建立】等接口建立；业务反向汇总生成——多数在当日日终批量按借据维度生成，且在额度建立时自动完成占用。

对公客户额度体系

结构体系（区分自用与他用）：法人客户总额度 = 母行额度 + 并表机构额度（并表机构总量控制，下分自营与代客额度，按其内部审批执行）。母行总额度 = 综合授信额度 + 专项授信额度 + 非授信额度，按授信金额与敞口金额双维度管控：

• 综合授信额度：满足客户经营周转需要、还款来源依赖综合还款能力，项下包含一般产品额度、担保场景业务额度（分离式保函）、代客衍生品额度、低风险额度、贴现额度与他用额度（供应链核心企业额度、商票额度、集团共享额度、证信通共享额度、合作方额度）。低风险额度为非产品额度，采用授用信分离模式——先审批低风险额度，再经单笔融资申请走用信流程，业务范围按《授信审批授权手册》确定；
• 专项授信额度：用途专用或还款来源与项目收益密切相关，与其他额度不可串用——固定资产贷款额度（按方案额度汇总、不可循环）、组合产品（铸剑产品，产品额度与组合内传统额度双占）、项目链融（无追保理与项目贷款额度共用、均可循环，组合产品按用信余额控制：无追保理借据余额 + 项目贷款借据余额 ≤ 组合产品额度，周转期内存量占用可暂时为负）、投资类额度（金市投资、信用风险缓释工具、包销；金市投资与包销共用额度、按用信余额管控、均可循环）；
• 非授信额度（管理额度）：委托贷款、债券承分销、合作方非授信、供应链非授信、银团他行承贷、企业常规行内保证担保、个人经营贷管理、保理非授信、交易对手全额保证金等——债券承分销/合作方非授信/场景额度为审批额度，其余为反向汇总金额。非低风险业务按双维度占用，部分保证金业务占用"授信额度 − 敞口金额"。

产品类额度分单一额度（传统产品）与组合额度（组合产品采用产品额度与组合内具体额度双占控制）；合作方额度按资源类/担保类/其他类划分（资源类为平台与业务来源机构，担保类为承担不可撤销保证或兜底/回购责任机构），按"项目额度"维度设置、属不可循环的专项额度。额度与产品的映射关系见《青岛银行智慧信贷二期额度映射-对公客户》。

切分模式（占用校验的核心算法）：综合授信项下为超额切分——占用时先判最底层额度，够用则递归汇总校验各上层直至综合授信层，任一层任一维度不足即失败并返回具体提示；专项授信中的项目链融、投资类额度同样逐级向上校验至本大类（V1.2 校正），其他专项额度与非授信额度为等额切分——仅判最底层额度。占用与释放只在最底层额度发生，非底层额度按底层实时汇总计算；反向生成额度在额度建立时自动完成占用。

额度启用：批复确认后额度生效，须由客户经理发起启用、经总行风险部用信条件确认后才能用信。启用状态按授信类型推送至最底层额度分项：授信新增【未启用】、变更【变更未启用】、续作【续作未启用】、年检【年检未启用】，启用后为【启用】；V1.2 增设【额度部分启用】，用于授信变更增额场景——增额部分批复确认后自动增额冻结，用信条件落实（额度启用）后解冻，且只能按本次冻结金额全部启用、不能分批。自用与他用额度启用流程一致（均选最底层额度启用）；非授信额度自批复确认时启用并生效；房产开发商（个人按揭）额度仍需启用流程。

有效期三层控制：批复有效期 6 个月（期间未签订合同则批复失效；批复失效 = 手工失效或 6 个月未完成批复确认）；额度有效期内启用不重算起始日、到期日受最顶层额度控制；产品额度到期日 = 首笔合同放款成功（额度启用日）+ 期限，最底层产品额度期限可以超过上层（控制合同最长期限）；仅有项目贷款或委托贷款时各层级期限一致，其余各层级（除产品层）有效期不超过 3 年。V1.2 校正：自批复确认日起六个月仍未启用的额度分项执行冻结（区别于到期或业务失效后不可逆恢复的失效处理，可按授权流程解冻）。

占用、释放与串用：

• 合同项下首笔借据出账审批完成后按合同金额占用（当日核心未放款、出账审批撤销则同步释放），按授信金额与敞口金额双维度记录与更新；
• 循环额度释放区分合同类型：非额度类（一般）合同借据还款成功后按还款金额恢复授信占用，并按合同签订时总量与敞口金额的比例计算本次敞口释放金额，全部借据还清后占用归零、合同结清；额度类合同借据还款不更新占用，提前全部结清或到期当天全部还款才按合同金额归零，到期日仍存在未还款借据时按当前合同余额和敞口更新占用；
• 不可循环额度已到期或提前还款终止不释放；合同部分未放款提前终止则释放未放款部分（合同状态【部分提前终止】）；
• 非循环额度下借新还旧须先将原合同占用清零结清，再按新合同金额占用；
• 循环/非循环转换（V1.2）：额度未占用时直接转换；占用中转换时，非循环→循环按借据余额占用（已还款借据不占用，流水为借据维度）、循环→非循环按合同金额重新占用额度有效期内全部合同（流水为合同维度），循环转非循环可能使综合授信可用额度变少或为负、影响该层级额度使用；
• 双占规则：占用贷款人主体额度按双维度，占用三方额度（合作方、集群、供应链、同业）按合同金额占用授信额度；
• 串用按产品风险等级执行（低风险可占高风险，不可逆向）——通过在"综合授信→一般产品"下增加对应业务产品额度实现；对公客户项下不另行配置串用列表，由业务端按产品属性处理，额度中心不单独实现对公产品串用。

错币种与汇率：授信只能人民币，用信可用外币；占用按当日人民币汇率中间价（实时取自核心，每工作日更新一次）折算四舍五入后处理；日终按最新汇率"先释放前日授信与敞口占用、再按重算结果重新占用"并保留汇率版本，恢复更新先占用后释放。综合授信下折算后超出授信金额时最底层占用可为负数，但不得挤占其他额度；授信或敞口占用超过一定比例（如 90%）时向客户经理、分/总行风险管理岗推送风险提示；已失效、已终止和未启用额度不参与错币种预警扫描，单笔通知失败不影响其他记录并由下次批处理重推，连续三日失败升级告警。

票据与应收账款规则：贴现额度按低风险业务管控（敞口默认 0）；一个贴现申请有且仅有一种票据类型，可打包不同笔同类型票据；商票按每张由客户经理指定占用兑付人的商票额度，银承/财票由票据系统自动占用同业客户票据专项 R1 额度；银承贴现无同业额度或不足时可占用贴现人商票额度（同一张票不能拆分占用两类额度）；商票入池按张指定占用兑付人商票额度，银承/财票入池由资产池系统通知票据系统占用同业票据专项额度。应收账款：一般质押模式关联任意基础/组合产品；保理模式按类型映射管控；资产池应收账款作为入池资产不占对公授信额度，占用"电子凭证核心企业额度"非授信额度，由资产池系统通知占用和释放。

垫款处理：银承、保函、信用证垫款当日日终先释放原协议（合同）的授信与敞口占用，再按垫款本金重占原业务同一额度节点（含组合产品下票证函，防止重复占用；切换失败按该垫款业务流水回滚本笔）；V1.2 新增无追索权保理垫款额度节点——“综合授信→供应链额度→无追索权保理垫款额度”（承接应收链融与线下无追保理）与"专项授信→项目链融→无追索权保理垫款额度"，垫款申请审批通过后先释放原无追保理额度占用、同时反向生成垫款额度；垫款额度为不可循环且全额占用，项下可包含多笔垫款业务，额度到期日 2099-12-31，日终批量检查该额度关联借据全部结清后方更新为失效。

保证金变更与特殊场景：银承、信用证、保函通过柜面变更保证金后释放敞口金额；银承填仓经 OA 审批 + 柜面操作，按每张票关联保证金账户与本次填仓金额，由票据通知授信执行、授信执行通知额度中心释放。信用证短溢装（付款金额与开证金额差额）按付款金额占用额度。不良资产：贷款核销按借据维度核销，合同状态【未结清】、额度不释放；资产卖出按整笔合同卖出，完成后合同【已结清】、释放对应额度。

冻结与解冻：同一客户同一额度编号已有在途冻结或解冻审批时不得重复发起；冻结申请提交后该额度暂停占用，解冻申请提交后暂停释放，审批完成后按审批结果更新（待发起或退回的申请可修改，退回可作废）。冻结类型四类——普通冻结（人工/自动）、批复冻结、风险预警冻结、增额冻结；人工冻结由分支行/总行冻结岗位按层级发起，综合授信下可选任意层级全额或部分冻结（部分冻结校验"已占用金额 + 合同申请额度 ≤ 未冻结金额"），专项授信按业务方案冻结；冻结金额 = 已冻结 − 已解冻，可用授信额度 = 授信金额 − 已冻结授信金额，合同申请校验"本次申请金额 + 已占用额度 − 还款释放金额 ≤ 可用额度"。九类客户维自动冻结场景及触发来源（V1.2 明确）：信用评级超期 1 个月未更新（评级系统）、集团成员退出（客户中心，紧凑型不变、松散型扣减）、应收链融上游未按期评级（授信执行/供应链平台，冻结核心企业供应链额度）、业务逾期超 60 天（贷后系统）、禁贷/黑名单（预警平台）、红色预警信号（预警平台）、集团解散（客户中心，集团额度失效保留查询、成员可基于冻结额度变更）、两集团合并（客户中心，被合并成员冻结、并入集团可用）、年检超期 30 日（授信作业中心，完成年检自动解冻）。解冻分级执行：自动冻结由总行有权部门解冻；人工冻结按审批层级由分支行或总行解冻；批复冻结→总行审批部，风险预警冻结→总行风险部，普通冻结按冻结流程判断；增额冻结只能通过额度启用解冻（人工解冻最大金额 = 授信金额 − 增额冻结金额）；解冻流程分总行权限（额度管理岗、复核岗）与分支行权限（分支行发起的加总行两岗）。

单笔融资与额度建立：单笔融资申请涉及低风险业务（用信流程）、贴现额度申请、委托贷款；客户无额度信息时批复确认后生成完整额度树推送额度中心，已有有效额度且为新增时按对应节点生成（贴现=“综合授信→贴现”；贷款类低风险=“综合授信→正常产品→具体产品（全额保证金）"；委托贷款=“非授信→对公委托贷款→具体委托贷款”）；贴现额度变更/续作按额度编号覆盖更新。无论统一授信、单笔融资还是线上渠道入口，均必须生成完整单一客户额度结构。对公集群授信经复核审批完成由【集群额度建立接口】建立。

关联额度与反向汇总：一般产品、组合产品（含项目链融无追暗保理，明保理占用核心企业额度）、固定资产方案额度在合同申请时选择具体额度编号关联（银团贷款自 8.27 起不再作为组合产品、按标签管理）；分离式保函、应收链融/线下买方保理核心企业、代客衍生品（X-FUNDS）、商票、低风险、金市投资与包销（COMSTAR）、信用风险缓释工具（投行业务系统）、债券承分销、供应链非授信等非产品/管理额度按场景自动或选定关联；经销易贷核心企业、其他供应链核心企业、合作方额度按项目额度维度关联。六类反向汇总额度——个人经营贷管理额度、有/无追索权保理核心企业额度（生成贷款人额度时同步生成）、上游企业无追索权保理额度（放款时生成）、银团他行承贷额度（银团合同签订时）、企业常规行内保证担保额度（签订担保合同时）——除上游企业无追保理额度外，多数为当日日终批量按借据维度生成。

同业客户额度体系

同业客户将"母行与子公司、实有与或有、本币与外币"全部纳入统一授信，按敞口金额维度控制。同业客户总额度 = 母行授信额度 + 并表机构额度（青银理财仅代客额度；青银金租含自营与代客，实际业务仅自用、预设代客）。母行授信额度 = 综合授信额度 + 专项授信额度 + 非授信额度；综合授信 = 票据业务专项 + 贸金业务专项 + 金融市场专项，专项之间不可互串，各专项下按风险等级 R0～R3 划分：

• 风险等级产品：R0 为国债、政策性银行债、地方政府债、央行票据质押的买入返售与债券借贷（按产品管控，业务汇总金额为 R0 额度）；R1 一般风险（贴现、转贴现、票据普通质押/入池质押、国内国际福费廷、代开非融资性保函、有追保理融资等）；R2 中风险（同业存单、债券投资（除二级资本债与永续金融债）、非利率债回购、信用拆借、同业借款、外汇买卖、贵金属及衍生品、代开融资性保函等）；R3 较高风险（二级资本债、永续金融债）；新增品种从属类别以授信批复为准，归入对应风险等级后办理；
• 串用规则：低风险级别授信可占用同级或高风险级别额度（R1 可占 R1/R2/R3，R2 可占 R2/R3），不可逆向，R0 不参与串用；
• 调剂规则：专项额度之间按风险等级额度调剂（调出 = 调入，如票据专项 R1 −10000、金融市场专项 R2 +10000），R0 为金融市场专用额度不允许调剂；
• 专项授信额度：同业客户作为合作方提供的担保项目额度（如中债增）；非授信额度含资管代销额度与资管代销项目额度（审批额度，由主体授信批复核定）、金融市场 SPV 管理人额度（不含通道，按 SPV 对应同业主体反向汇总）、委外底层资产额度（反向汇总），反向汇总额度自动汇总至非授信额度、母行授信额度与同业客户总额度。同业对外担保额度从额度结构移除，改为数据双占（发行人产品额度 + 保证人金融市场专项 R2），汇总至母行授信与总额度。

批复与有效期：同一时间点仅一个有效额度批复；批复下发即生效（无批复确认环节）；批复到期日 = 生效日期 + 12 个月（与对公不同），期内未出账放款则批复自动失效；客户层级、额度大类与风险等级相关期限与批复生效日一致，额度到期日 = 生效日 + 额度期限，到期后不能发起用信与出账；低风险业务额度期限不受同业额度有效期控制。币种：授信按汇率折算人民币申报（同业授信币种默认人民币），用信可用人民币或外币。

建立与更新：单一/批量同业授信批复发布后建立额度结构，各层额度已生效、所有额度项已启用；变更/续作采用覆盖更新——先备份该客户当前额度信息，再按推送信息全量更新，已存在业务的额度分项变更后额度可小于等于存量业务余额之和（不做强制校验），批复发布后原额度分项即刻生效、新增分项按启用规则启用。低风险业务授信采用单笔更新——无有效批复时生成完整额度结构（R0 下债券回购（质押利率债）与债券借贷产品额度），已有批复时按最末级额度层层向上汇总生成缺失层级，额度项变更时更新该分项并逐级更新上层金额。

占用释放与集成：票据专项 R1 额度推送至票据系统，直贴、转贴、买断等票据业务在票据系统占用释放，票据系统日终回传已用金额与当日跑批始点占用明细，额度中心记录数据用于展示；金融市场专项按"可售产品-风险等级额度映射"管控——可售产品基本信息及映射关系（R0/R2/R3）在星图平台维护，发布后推送智慧信贷产品列表，COMSTAR 发生占用/释放时按传入的可售产品代码与映射关系处理（如质押式回购→R0 债券回购（质押利率债）、债券借贷→R0 债券借贷、各类金融债投资→R2）；贸金专项由贸金系统调用额度中心处理，二级市场福费廷在智慧信贷出账审批完成后占用贸金专项额度；理财自营业务纳入金融市场专项，通过理财子投前审批管理系统与额度中心实时交互（审批完成按审批额度预占、实际资金录入后释放预占并按实际金额重占），代客额度随批复推送由其自管、业务数据日终同步。

冻结与解冻：人工冻结可选全部冻结或风险等级额度冻结（部分冻结校验"已占用额度 ≤ 未冻结金额”）；自动冻结场景（评级超期 1 个月、逾期超 60 天、禁贷/黑名单、风险预警）由风险事件来源系统（预警平台/评级系统/贷后系统）判断触发条件并确定客户、额度范围及冻结金额后调用额度中心冻结接口，额度中心不重复实现预警识别；解冻按同业适用授权流程由承接系统调用解冻接口，总行/分支行权限流程与对公一致。

个人客户额度体系

个人业务为单笔单批模式，个人客户总额度为各单一授信批复的反向汇总视图——除委托贷款外按部门、渠道维度汇总，汇总来源跨系统：智慧信贷、星云平台（个贷/微贷）、信用卡系统、新希望平台、互联网融资平台，交易信息携带系统名称与产品部门在额度视图中展示；个贷部/微贷部层级仅做汇总数据展示，不进行额度控制也不生成数据。结构上另设个人委托贷款额度（按委托贷款批复汇总、不受限额管控）与个人行内保证担保额度（按个人行内保证担保贷款反向汇总，担保合同签订生成、失效同步失效，不受总限额、信用限额与保证限额管控）。

控制规则：批复确认推送额度中心（生效/未启用，批复确认、合同启用、放款占用分别处理），一个批复有且仅有一个业务合同（一般合同或额度协议），合同签订后额度启用，已签订合同可作废（作废时批复作废、额度失效）；放款按借据金额占用，按额度编号、合同编号、占用金额同步更新；批复失效审批完成后通知额度中心失效。申报时受个人总限额、保证类限额、信用类限额管控——额度中心记录个人总限额、信用限额、保证限额，个贷提交后由评级系统计算并推送更新（存在超限时按超限金额更新评级数据），个贷授信作业根据额度中心接口信息判断是否执行超限流程；外围系统按相同接口获取超限判断数据自行应用限额规则。个人经营贷纳入集团统一额度管控时按先到先得占用（个人主体层不单独占用、仅占集团层），建议通过单独分组进行额度保护。

个人业务关联对公供应链额度（V1.2 明确）：经销易贷（个贷）风险共担模式关联"综合授信→供应链额度→经销易贷核心企业额度→供应链方案额度"，非风险共担模式关联"非授信→供应链非授信额度→经销易贷核心企业额度→供应链方案额度"（方案额度以客户经理选择为准）；商票作为质押物办理质押贷款时占用"综合授信→供应链额度→商票核心企业额度"（未来个人贴现业务同）；另设"非授信→供应链非授信额度→个贷上游核心企业→供应链方案额度"。个人非授信额度中，房产开发商（个人按揭）额度与二手房中介额度为审批额度（按合作方项目额度申请，个贷单独入口发起、对公额度树不存在时生成完整额度树，关联业务批复确认时占用），个人经营贷管理额度与企业常规行内保证担保额度为反向生成。个贷 ABS 出表转换仅增加 ABS 标签、按正常贷款管理，额度无需特殊处理。自动冻结在评级超期、逾期超 60 天、禁贷黑名单之外，增加红色预警（客户维度冻结全部业务、借据维度冻结对应合同金额，非风险信号可解冻）与集团退出/解散场景——未发生业务的批复直接失效，已发生业务的批复冻结，由个贷部重新审批。

集团客户额度体系

三层结构：授信层（集团客户限额 → 集团客户总额度 = 母行集团授信 + 并表机构额度）→ 成员额度层（对公成员、同业成员额度 + 集团成员关联的所有个人经营类额度（不论是否集团成员）+ 预留授信额度）→ 分组层。

两级分组限额：一级为成员分组（未被选择的成员自动进入缺省分组，缺省金额 = 集团总金额 − 各分组之和）；二级为支行分组或板块分组（二者互斥），机构/板块层对母行额度完全切分（无缺省），其下成员层保留缺省分组。分组仅针对综合授信与个人经营贷款的授信/敞口金额进行限额控制，放款时按所有成员业务数据实时计算校验，审批流程每个节点均需计算；成员用信只校验其所在分组金额，不从缺省分组中切分额度。

管控与占用规则：授权计算包含预留额度、额度管控剔除预留额度；母行总额度双维度实时校验——成员综合授信已用 + 成员专项授信 + 成员个人经营贷 + 新增申请 ≤ 母行额度。集团层占用按先到先得，单一客户额度与集团额度须同时足额，任一不足即占用失败；贷款主体自用额度不占用集团层额度，他用额度（合作方、核心企业、商票、集团共享）占用集团层；自开自贴场景的信用证/银行承兑、福费廷、卖方押汇或贴现不占用集团额度。同一集团内多占场景按占用矩阵处理（如银承额度 + 自开自贴贴现、贴现额度 + 商票/商票低风险额度、经销易贷组合 + 担保公司/核心企业/低风险额度、证信通组合 + 担保公司/证信通担保额度、信用证 + 福费廷/卖方押汇等）。

预留额度领用与恢复（V1.2 校正）：领用审批生效后由授信作业中心通知额度中心记录领用信息，并扣减集团预留授信、敞口可用金额；同一成员存在多次领用场景，仅从未使用的已生效领用记录可按规定失效恢复，恢复须关联原领用记录，恢复金额随授信作业审批结果更新；集团层授信与敞口总金额分别加上领用金额，分组限额计算同步纳入领用金额。已发生业务的单一客户新加入集团时，审批通过后按每笔业务当前占用单一客户金额在集团层补占（占用集团授信与敞口金额，占用后集团层剩余额度可为负）；集团存在缺省分组时新成员批复确认自动加入，无缺省分组须先办理集团分组变更或集团授信变更后方可单一授信。

流程约束：集团授信在途仅允许一笔；集团关系变更审批（成员加入/退出/合并）期间不允许发起集团授信；集团发起授信期间成员不允许单独申报，变更方案随集团统一申报审批。同一集团内双占对象处于不同分组时的计算规则待进一步讨论确认。

SPV 与集群额度体系

SPV 额度：面向无法进行底层穿透的项目——资产支持证券（ABS）/资产支持票据（ABN）、资产管理计划、公募基金、结构化融资；可底层穿透的项目在中标后按底层资产主体进行额度占用。SPV 授信时录入对应类型业务基本信息及担保人/差额补足人/增信方信息（担保措施），中标后占用这些主体的"投资额度"（专项授信→投资类额度→金市投资额度），经【SPV 额度建立接口】建立。

集群额度：包括个人集群额度与普惠集群额度，普惠集群额度包含营销类额度与授信类额度；集群额度均为非授信额度、按审批结果生成、属双占额度。对公业务合同关联集群授信时，按该笔业务占用维度和金额关联占用集群额度；营销类集群默认额度 1 亿元，审批通过后由客户中心推送额度中心创建额度，对公集群类型按客户中心的营销集群、授信集群标识区分。个人业务在批复中明确占用集群额度，额度中心生成个人单笔业务额度信息时同步按批复金额占用集群额度。审批流程：普惠集群项目为全风会额度登记流程（全风会秘书、风险部总经理两步）；个人集群额度按授权审批。唯一性约束：个贷集群只能有一个个贷集群额度，对公集群只能有一个对公集群额度，通用集群可同时各有其一，建立时校验唯一性。

额度生命周期管理

额度形成（审批形成、业务反向汇总形成，统一进入额度视图）→ 生效/启用（五态推送 + 部分启用与增额冻结）→ 查询校验 → 占用 → 调整/冻结 → 释放/恢复 → 到期/失效/结清。批复下发 15 天客户经理未确认的当日日终自动批复确认（第 14 个工作日提醒）；批复确认日起六个月未启用的额度分项批量冻结；垫款额度在全部垫款借据结清后日终批量失效；变更、续作、年检承接新批复而不破坏存量业务关系；冻结不改变授信事实但限制新业务使用（可还款），解冻分级执行。

双占与多占管理

单笔业务可同时占用多个对象或层级额度：集团成员业务（自用 + 他用分治；个人一般贷款主体层不占用、仅占集团层）、供应链/合作方/集群业务（主体 + 关联核心企业/合作方项目/集群项目额度，如应收链融有追/无追暗保理双占贷款人与核心企业管理额度、经销易贷按风险共担与否分别双占综合授信或非授信核心企业额度）、票据与贸融业务（贴现双占贴现人额度 + 承兑人商票额度/银行与财务公司同业票据专项，福费廷双占授信客户 + 开证行/兑付行贸金专项 R1）、SPV 业务（SPV + 担保人/差额补足人/增信方投资额度）、同业合作方业务（同业主体 + 对公/同业专项授信下合作方项目额度，由 COMSTAR 指定）。占用方须明确各对象的客户编号、额度编号、授信金额与敞口金额；占用关系在单一客户授信申请或票据/贸金/COMSTAR 等系统指定节点明确；同一集团内的双占需按分组归属区分计算规则。

限额管理

限额包括单一客户限额、监管限额、组合限额：单一客户限额（个人、对公、集团客户限额）由额度系统管理；额度中心负责监管限额和组合限额的配置及计算能力。授信作业中心在授信申请或审批阶段、授信执行中心在放款阶段及相关外围业务系统按各自场景调用额度中心限额检查，按返回的检查结果和处理方式办理。

授信额度解决具体客户、集团、SPV 及业务场景可用多少信用资源；限额管理从监管、组合和集中度视角设置上层边界（集中度、国别、关联方、行业、机构、产品等）。单一客户或集团的信用资源上限原则上通过授信额度体系及授信政策管理；不同限额在申请、合同、放款或交易阶段参与校验，形成强制控制或风险提示。

配置与生效规则（V1.2）：监管限额配置保存为待发起申请、提交后进入审批中，仅待发起或退回的申请可修改、仅待发起可删除；同一限额大类、限额类别与业务环节不得重复配置非失效记录；审批通过后立即生效，定时生效配置到达生效日期经晚间批量生效，实际生效前不应用于业务限额检查。组合限额支持担保方式、产品、行业等维度管控方案，每个方案必须且仅允许一条维度方案，与已生效配置的限额大类、限额类别及维度值、管控对象均相同时不得重复；配置申请的保存、提交审批和生效分别管理。限额配置停用：待生效或已生效限额可发起停用申请，停用审批通过后限额失效、不再参与业务管控，失效日期为停用审批通过日期。

额度中心公共服务

• 处理结果与重复请求控制：个人和集团额度建立、个人限额同步及额度失效，对同一请求或同一业务标识重复调用只处理一次；校验失败返回具体原因并终止本次处理；冻结、解冻同一交易流水重复调用返回首次结果，处理异常时回滚本次涉及的全部额度节点更新，业务系统按实际结果继续或补正；
• 人工占用与释放：由具备权限人员办理——交易银行部管理员岗仅可选择已配置业务品种，总行管理员岗可另选其他业务品种；一笔申请仅允许一条占用记录，占用授信/敞口金额不得超过可用授信/敞口额度，审批通过后执行占用；人工释放必须选择原人工占用记录并沿用其业务、客户及额度信息，不得新增或删除释放额度记录，释放金额不得超过已用额度，审批通过后执行；
• 额度调账管理：针对占用或释放交互异常办理，可关联已有失败交易（仅调整本次占用或释放金额，不更改原客户及额度对象）或新登记业务编号、客户及额度项；占用授信、敞口金额分别不得超过对应可用额度；提交校验通过后更新额度并生成新的调账记录，原交易流水保留；
• 额度交易查询：按数据权限查询调用额度中心的占用、释放交易及处理状态，一笔交易涉及多个额度对象时分别展示各对象记录，保留原业务与交易的关联，供成功、失败及后续调账核查；
• 查询服务与统一视图：授信作业及用信系统按客户查询个人生效批复额度及个人总、信用、保证限额（用于变更、续作、超限判断及用信校验）；集团查询提供集团、有效成员及授信分组信息；额度分项查询按所属额度类别返回上层控制额度及子层（方案/项目）信息；未查到有效额度或有效限额时返回异常，不能按零金额或查询成功继续办理；有权人员按客户或集团查询统一额度视图（生效、部分冻结、已冻结及历史失效额度，集团视图可下钻成员额度），占用、释放明细按所选额度项查询，非最底层额度汇总展示该项及全部下级明细；查询受当前用户数据权限控制，失效记录保留供追溯；
• 额度结构配置：对公额度树叶子节点层级参差，仅允许在最底层新增或删除节点，其他层级仅维护名称与允许调整的属性；删除节点须已失效、无额度占用且不存在未失效子节点；维护生成新版本并提交审批，审批通过前旧版本保持有效，同一结构已有审批中维护申请时不得重复发起；新增产品类额度以产品编号作额度编号并通知授信执行/外围系统使用；产品中心变更产品名称时同步更新结构模板及全部存量额度实例名称（登记原/新名称，产品编号、额度编号、金额、状态、占用与冻结信息不变），产品风险等级变更时同步更新产品额度可串用属性；个人额度基于批复汇总视图、无需结构配置，同业可配置风险等级额度与产品额度，SPV、集群按项目管理并支持配置额度属性；
• 组合产品额度拆分：组合产品下基础产品同时存在综合授信一般产品与专项授信固定资产类时（如绿水清源贷），综合授信与专项授信不可混用——产品中心为组合产品基础产品增加"额度节点编号"与"额度名称"两个字段，将其拆分为"（专项额度）“与”（一般产品额度）“两组分别挂载对应额度节点；
• 额度批量任务：每日汇率更新（授信人民币用信外币的占用记录先释放前日占用、按最新汇率重算重占并保留汇率版本；汇率服务不可用或无数据时任务终止并告警、处理后可重跑，单条折算失败仅回滚该记录并输出失败明细）、当日出账已审批未放款额度释放、额度日终对账（COMSTAR、票据、供应链等外围系统提供当日交易流水，按交易或业务流水号逐笔核对占用、释放交易）、批复自动确认（15 天）、垫款额度失效、反向汇总额度处理（日终批量建立和释放，主体额度不存在时生成完整额度树，单条校验失败记录原因、其余继续，额度中心不主动反查）、批复六个月有效期处理（未启用额度分项触发冻结）。

附：业务架构视角结构图

以下为依据《业务架构说明书》第七部分绘制的业务架构视角结构图（批复 → 额度 → 用信主线，主体/专项结构与限额约束），与上方 V0.2 机制图互补——机制图讲"怎么管”，结构图讲"在业务链路中的位置"：

下载矢量版 SVG

1.1.5 - 客户管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第八部分。客户管理为信贷经营、授信、额度、担保、贷后及专业风险管理提供统一客户基础，核心是持续识别"客户是谁、客户之间是什么关系、由谁负责、在什么业务场景中以什么身份参与"，并在信息和关系变化时保持业务责任与上下游连续。

总体结构

客户管理按四个层次组织：

各层共同以客户为基础主体：客户参加集团、集群、供应链或具体合作业务时，基础身份保持稳定，通过群组、关系、标签或业务角色表达场景差异。

客户主体体系

• 统一客户主体：覆盖个人、对公、同业客户及 SPV 等特殊目的主体。不同类型有不同的信息结构、准入规则和处理方式，但均以可持续识别的身份参与后续业务，避免不同场景重新形成割裂的客户身份。
• 客户群组：集团、集群及其他基于营销、统一授信或风险管理形成的稳定客户集合。群组拥有独立身份和成员关系，成员客户继续保持自身独立身份——群组解决"哪些客户作为整体识别管理、各客户在其中是什么成员关系"。
• 客户业务角色：同一客户在不同业务中承担不同角色（借款人、担保人、合作方、核心企业、上下游企业、个人用款企业、集团成员、SPV 增信主体等），角色描述特定业务关系中的身份，不改变基础客户主体。
• 跨法人协同：对金租、理财子等机构已建立的客户，形成跨法人客户协同视图并与行内身份建立识别关系，支撑集团并表和统一风险识别。

客户信息统一管理

客户建档过程：客户识别 → 重复性检查 → 身份核验 → 客户创建/引入 → 信息完善 → 持续维护。已存在的客户直接引用现有身份；外部或行内系统已有客户在身份匹配后引入。统一识别的目标是同一客户在不同信贷场景下持续、准确识别，而非按业务品种、渠道或办理阶段重建客户记录。

信息体系为"统一客户身份 + 客户类型差异化信息"：个人客户维护身份证件、税收居民、联系、工作教育、关联人及企业、资产负债等；对公客户维护证照、经营规模、财务、企业关联、实际控制人/高管/股东/对外投资等；同业及专项客户按业务特性保留专业属性。

重要客户信息保留变更前后内容、来源和时间，保证持续可追溯；信息变化来源于人员维护、行内系统同步、外部数据更新和经营状态变化。

客户关系与群组管理

• 关联关系：股权投资、实际控制、任职、家庭亲属、担保、上下游经营等具有持续业务含义的关系，进一步形成客户关系网络，支撑集团识别、公私联动、关联授信和风险穿透。
• 集团客户管理：以已识别的客户关系为基础，将存在控制或集团关联的客户组织为统一群组，过程为"集团识别与认定 → 集团成员建立 → 信息维护 → 关系排查 → 成员调整 → 变更和持续监测"。集团形成时明确整体身份、核心成员、成员范围、成员关系和管理责任；成员可新增、退出、调整或集团合并，变化同步传递给集团授信和额度体系。客户管理确认集团及成员关系，授信和额度管理基于已确认的集团关系开展统一授信和信用资源管控。
• 集群客户管理：管理因共同经营特征、客户来源、营销方式或风险方式形成的客户集合，维护集群身份、类型、成员、主办责任和业务属性，服务于批量营销、批量授信、产业商圈经营和场景化风险控制；成员按自身身份办理业务，同时接受集群授信或额度约束。
• 供应链关系管理：围绕核心企业及上下游形成业务关系网络，除"哪些客户属于一个集合"外，还表达成员之间的上下游关系和供应链位置，支撑供应链客群营销、批量授信和相关额度管理。

管户责任与权限

客户权限分三层：

1. 客户主办/管户责任——明确谁对该客户承担主要经营和持续管理责任，同一客户原则上形成明确的主办或管户责任；
2. 客户信息使用权限——信息维护权和查看权，控制非主办人员在授权范围内维护或查看客户信息；
3. 特定业务办理权限——如对公客户的低风险业务权，支持非主办客户经理在授权范围内办理相应业务。

权限本身具有申请、审批、生效、调整和失效的持续管理过程。个人客户主要包括主办、维护和查看权限，对公客户进一步包含低风险业务权。

客户及业务移交

经营责任变化时通过移交管理保持连续，形成三种移交：客户责任移交（调整管户责任及权限）、客户项下业务移交（经营责任不变，仅调整特定授信、合同或存量业务的主办责任）、客户及业务整体移交。整体移交需识别客户项下的在途申请、批复、合同放款、押品及担保关系、贷后事项等存量业务。

管控原则：主办责任清晰、在途业务状态可识别、原责任与新责任连续衔接、客户和业务调整结果一致、移交结果和历史过程可追溯。

分类、标签与名单

• 客户分类与标签：经营分类、企业规模、行业属性、战略客户/科技企业等经营标签、监管类和专项业务标签，作为持续业务属性参与经营和风险判断，不改变客户主体身份。
• 企业划型：具有明确监管规则的重要机制，过程为"获取划型基础信息 → 按规则计算企业规模 → 业务确认/审批 → 形成有效划型结果 → 定期或变化时重新认定"，规模分为大型、中型、小型、微型、个体工商户等，结果在授信申请等业务中作为分类基础。
• 名单管理：按营销、准入、预授信和风险管理目的形成特定客户集合，生命周期为"名单类型定义 → 客户纳入 → 审核/确认 → 生效使用 → 状态调整 → 失效/退出 → 历史留痕"。名单是客户集合的表达，客户加入或退出不改变基础身份。

客户统一视图

以客户为统一索引，关联展示三类信息：客户自身信息（基础、分类标签、关系群组归属、历史变化）、信贷业务信息（授信申请与方案、批复、额度及使用、合同放款、还款存续）、风险及专业信息（评级、风险分类、预警、担保关系、押品和缓释、外部信用）。

统一视图采用**“客户集中展示、专业责任分别管理”**：额度、押品、评级、预警等业务结果在视图中被统一引用，专业主责继续由相应业务领域承担。

客户生命周期

客户识别 → 建立/引入 → 信息完善 → 分类与关系建立 → 经营及授信使用 → 信息与关系调整 → 管户及业务责任变更 → 持续监测与历史留痕。生命周期中持续管理三类变化：客户自身变化（信息、经营、分类标签）、客户关系变化（集团成员、股权控制、供应链、集群成员）、经营责任变化（主办责任、权限、移交）。

客户管理作为跨生命周期的专业对象管理领域，与业务准备、尽职调查、授信申请、审查审批、额度管理、押品管理、签约放款、贷后管理、评级及公共管理等领域的协作，将各业务阶段统一连接到稳定客户身份、关系和经营责任基础上。

1.1.6 - 押品管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第九部分。押品管理围绕信贷业务中的抵质押风险缓释资产持续管理，贯穿授信前、授信审批、签约放款和贷后全过程，核心是持续回答"哪些资产可以作为押品、当前价值多少、能提供多少风险缓释、与哪些业务形成担保关系、权利是否落实、存续期风险是否变化、何时解除退出"。

范围说明：本体系重点展开抵质押品及其缓释使用；保证等非押品型担保安排及担保协议的形成、变更、终止，由担保管理责任统一承接。

总体结构：五层组织

各层以具体押品为核心对象：押品在不同授信、合同或债项中被引用形成不同担保使用关系，但自身身份、基础信息、价值记录和权证记录保持统一管理。

押品目录与管理规则

统一押品目录定义银行可接受的抵质押资产类型，形成分类层级和业务含义，承担统一分类口径、明确担保方式、建立信息模板、为估值/权证/缓释分配/风险监控提供分类依据、支撑新增类型维护等作用。目录描述"可接受什么类型"，具体资产进入押品信息管理。

不同押品类型在目录下参数化管理：是否唯一性识别及识别要素、适用抵押或质押方式、最高抵质押率、估值方式和模型、重估频率及批量重估方式、权证类型及是否入库、是否保险、缓释合格认定参数等。

产品差异化抵质押率：押品管理维护类型层面的统一最高抵质押率及通用风险参数；产品管理可按具体产品和业务场景配置差异化抵质押率。业务使用押品时优先适用有效产品配置，未配置时适用类型统一标准。由此形成"押品类型统一规则 + 产品差异化风险条件 → 押品实际担保能力"。

押品信息与统一识别

押品建立过程：押品类型选择 → 唯一性识别 → 押品建立/引用 → 信息完善 → 价值评估 → 业务使用 → 持续维护。

• 唯一性识别：需要唯一识别的押品类型由目录预配核心识别要素（如房地产按房屋所有权证号、交易合同号、不动产单元号），创建时在已有押品范围内校验——无重复则新建，有则优先引用；批量导入和外围系统推送同样执行。目标是一项真实押品对应一个可持续识别的押品身份，多笔业务共享同一押品对象。
• 信息结构：“统一基础信息 + 类型差异化专项信息”。基础信息含编号、类型、担保方式、权属人及共有人、占有租赁顺位、实物与权利状态、来源系统、管户及机构、保险等；房地产类进一步管理产权、地址、登记、查封异动等，金融质押品按存单、保证金、票据、理财等维护账户和权利信息。
• 多来源协同：交易银行、票据等外围系统形成的押品统一纳入身份和唯一性识别规则并保留来源；金融质押品资产池已提出方向，池化结构待后续细化。
• 管户与留痕：押品建立即形成管户责任，随业务关系变化（重新引用、客户移交）调整；重要信息修改保留内容、原因及历史记录。

押品价值管理

• 估值方式：内部评估、线上外部评估、线下外部评估、直接评估（存单、保证金、部分票据及本行理财可基于账户或产品实时/定期价值直接评估），适用方式由类型规则确定。
• 初始估值与持续重估：初始估值形成首次业务使用前的我行认定价值；重估按类型频率、业务需要或风险变化开展，方式包括单笔人工、人工批量、系统定期批量，形成"首次价值认定 + 周期性重估 + 风险触发重估"。
• 我行认定价值：各类估值结果最终形成我行认定价值作为业务使用基础，具有认定日期、评估有效期、价值状态和历史评估记录，新认定形成后原价值转为历史。
• 可担保能力：押品有效担保价值 = 我行认定价值 × 适用最高抵质押率（抵质押率优先取产品差异化配置）；已存在业务占用时扣除已占用价值，形成剩余可担保空间。
• 价值变化管控：重估价值与存量业务认定价值偏离超过阈值时预警并通知管户或风险人员，评估是否调整担保可用空间；价值变化由押品管理识别，后续动作由相应领域承接。

担保关系与风险缓释使用

基本关系链：客户/债务人 → 授信或业务合同 → 担保合同 → 押品。押品与债项可形成一对一、一对多、多对一或多对多关系；担保合同生效后保留押品与担保合同、主合同及借据的有效关系，结清或解除后转为失效。

• 押品引用：优先从已有押品引用，条件为身份有效、存在有效认定价值、仍有可使用担保价值、无影响有效性的限制状态、满足来源系统使用规则；未建押品的资产可在业务办理中创建后补全信息、估值和权利落实。
• 缓释价值分配：统一分配机制支持两个视角——以业务为基准（识别每笔业务的担保覆盖程度和足值情况）、以押品为基准（识别每项押品已承担的担保负荷和实际抵质押率），形成"押品价值 → 担保关系 → 债项分配 → 风险缓释结果"。
• 占用与释放：生效的主要担保关系参与价值占用；一般担保按关联业务状态判断释放；最高额担保按综合授信层或业务方案层的担保范围判断是否全部满足解除条件；辅助担保单独标识，不参与常规占用分配。

权证与抵质押登记管理

权证分实物、电子式、虚拟权证，是否入库由类型规则确定，与押品、权属人、担保合同建立关联并形成独立状态和出入库历史。

• 权证生命周期：权证建立/获取 → 抵质押登记 → 入库保管 → 在库管理 → 临时借出/换证 → 归还入库 → 正式出库，状态包括未入库、入库中、在库、借出、出库中、出库。
• 入库核验：权证与押品及担保关系匹配、无重复入库记录、需登记的已形成他项权证、保险等前置条件满足、无查封冻结状态。
• 出库、借阅与置换：正式结清出库需确认担保关系解除且业务结清；临时借出用于诉讼、审计、信息变更等，归还入库并留痕；支持预转现等权证置换。
• 线上抵质押登记：对已接入不动产登记能力的房地产押品，衔接"登记前权利及限制核查 → 行内申请与审批 → 客户/银行签章 → 外部登记申请 → 进度跟踪 → 取得登记结果 → 权证建立及入库"，支持一般/最高额抵押、预告登记、变更、注销、预转现等场景；不同地区渠道不同但在押品管理中统一归入权利登记和权证管理。
• 跨机构移交：权证保管机构变化时通过出库和重新入库完成保管责任迁移。

持续监控与风险管理

• 状态监控：实物状态、查封冻结扣押、权属和顺位变化、保险、登记状态、权证保管、关联业务及担保状态；房地产通过不动产登记渠道定期获取限制状态，金融质押品通过核心或专业系统更新账户资产状态。
• 价值波动监控：最新认定价值与存量业务原认定价值显著变化时按阈值形成风险信号，传递至风险预警专业能力统一处理。
• 集中度分析：按押品类型和机构等维度统计数量分布、价值分布、对应债项余额及占比变化，识别结构过度集中。
• 压力测试：按类型、分支机构或指定范围选取押品，设置单一或组合压力情景，关注担保足值率变化、抵质押未覆盖金额与覆盖率，为风险管理措施提供依据。

押品生命周期与处置协作

全生命周期：押品准入 → 身份建立 → 信息完善 → 初始估值 → 业务引用与担保建立 → 权利登记与权证落实 → 存续期监控与重估 → 缓释价值调整 → 解押/处置 → 退出或再次使用。解押后资产本身仍有效的，保留统一押品身份供后续业务再次引用。

进入风险资产处置阶段时，资产保全负责专业处置（拍卖、司法处置、变卖、抵债等），押品管理负责持续记录和维护处置后的押品状态及关系，接收处置结果更新状态和台账，为权证出库、担保解除和退出提供依据。

与其他领域的协同

押品管理作为跨生命周期的专业对象管理领域，与客户管理（权属人/担保人身份、移交时协同调整管户）、产品管理（差异化抵质押率及使用条件）、尽职调查、授信申请（担保安排与担保能力判断）、审查审批（覆盖情况信用判断）、合同签约（建立担保合同关系）、放款管理（放款前核验担保条件落实）、额度管理（押品影响可用信用资源但额度对象仍由额度管理负责）、贷后管理、风险预警、资产保全、公共管理及外部登记平台协作，形成贯穿授信前、授信执行和贷后存续期的抵质押风险缓释管理基础。

1.1.7 - 产品管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第十部分。产品管理为信贷业务提供统一、稳定且可持续演进的产品基础，核心是持续回答"银行有哪些信贷产品、产品之间是什么层级关系、适用于哪些客户和业务场景、具体业务条件如何配置、产品如何发布和变更、什么时候允许继续开展业务、运营效果如何反馈到后续管理"。

两个术语区分：产品组件是产品配置中由若干产品要素形成的配置单元，与业务架构中表达稳定业务责任的"业务组件"不是同一概念；产品场景是产品差异化配置维度（主要用于个人信贷场景金融），与描述对公、个人及专项业务运行方式的"业务场景"不在同一层次。

总体结构：五层组织

各层围绕"产品"核心对象展开：产品条件承载准入、适用、定价及其他业务规则；组件、场景、流程、页面、模板等用于组织和应用这些条件，不改变产品的统一身份。

产品目录体系

统一产品目录组织信贷产品及其分类层级，目标是同一信贷产品具有稳定、唯一的产品身份，分类和层级变化通过统一目录管理，不因系统、渠道或业务阶段重新定义产品。

五级结构形成"基础产品沉淀共性 → 可售产品形成实际业务产品 → 组合产品组织多个可售产品形成综合服务方案"：

• 产品线：按稳定业务类别高阶归类（信贷、贸易融资等）；
• 产品组：按客户性质或业务特征细分（对公贷款、个人贷款等）；两级主要承担目录组织作用，不承载具体办理条件；
• 基础产品：沉淀相似服务功能和处理规则的产品模板，预置共性组件和要素、形成可复制条件基线，支撑可售产品快速建立，不直接面向客户销售；
• 可售产品：实际用于客户营销、申请和办理的形态，在基础产品共性规则上按客户细分、适用机构、区域、产品政策、场景、风险控制要求差异化配置；业务办理以当前有效的可售产品及其配置为规则输入；
• 组合产品：将多个可售产品组织为一揽子组合，管理组合身份、组成关系和有效状态，不改变被组合产品自身的身份和条件。

产品条件、要素与组件化

• 产品条件：描述产品适用于什么客户、遵循什么规则、如何形成交易条件，覆盖客户准入和适用、用途投向、金额期限、利率定价、费用、还款方式、担保及抵质押要求、业务控制项等，是"产品"与"产品条件"两个核心对象间的主要关系。
• 产品要素：结构化描述产品条件的基础单元，通过要素名称、类型、可选码值、数值范围、默认值、控制方式表达一项业务属性或控制规则，可被不同产品复用。
• 产品组件：归集具有紧密业务联系的一组产品要素，按业务使用阶段分为授信、合同、放款、贷后及通用组件，可被多产品复用，形成"产品要素 → 产品组件 → 产品配置"的配置链。
• 继承与差异化：产品新增可全新配置或复制已有配置；基础产品的共性组件和核心要素作为基线，可售产品在允许范围内调整参数并增加差异化组件要素，实现"共性规则继承 + 个性条件扩展"。

适用范围与场景化配置

• 适用客户：限定产品目标客户范围（个人、对公、同业、集团客户等），业务选择产品时参与匹配校验；
• 适用机构：配置允许经营的机构范围，上级适用可按规则覆盖下属机构；
• 区域限制：与适用机构共同形成"什么机构可以办理 + 什么地区可以开展"的经营边界；
• 产品场景：同一产品在不同业务场景需要不同条件时，基于产品通用配置复制形成场景配置并差异化调整，形成"产品通用配置 + 场景差异配置"两层模式；未形成差异化配置时继续使用通用配置；产品适用机构与场景适用机构冲突时，以产品适用机构为最终约束。场景不是新的产品层级——产品回答"卖什么和按什么规则办"，场景回答"特定业务环境下如何差异化适用"。

与业务执行资源的协同

产品配置还引用业务办理使用的公共资源：流程（产品管理维护"产品使用哪个流程"的关联，流程定义由流程管理负责）、页面（页面能力定义可复用页面，产品配置选择适用组合）、模板与影像（合同、业务、影像模板由公共能力维护，产品明确适用关系）、核算产品映射（信贷产品面向客户和业务规则，核算产品面向核心账务，二者保持独立定位，业务执行依据映射完成核算衔接）、个性化抵质押率（按"产品 + 场景 + 担保方式 + 押品类型"优先获取，未配置时使用押品类型统一标准，属于产品风险条件对押品通用规则的差异化约束）。

建立测试与发布

总体过程：产品登记/目录建立 → 产品配置 → 产品测试 → 提交审批 → 审批通过 → 产品版本生效 → 进入运营。

产品测试是配置进入正式发布前的质量门槛，包括三类：完整性检查（必须配置的组件要素是否遗漏）、逻辑一致性检查（存在勾稽关系的组件要素是否相互一致）、产品要素影响分析（识别要素调整可能影响的业务范围）。完整性和逻辑检查存在问题时不进入正式审批。

版本与变更管理

同一产品保持稳定身份，不同时间可有多个配置版本。版本用于固定某一时点的完整配置、区分当前有效与历史配置、支持变更追溯、版本差异比较以及基于历史版本重新形成新版本。

变更过程：“当前有效版本 → 发起变更 → 形成新版本 → 产品测试 → 审批 → 新版本生效 → 原版本转历史”，不改变产品身份和目录归属。恢复历史配置通过历史版本复制实现——以历史配置为基础生成新的产品版本而非恢复原编号，既恢复既有规则又保持演进历史连续。

四维状态与三档运营管控

产品管理区分四个相互独立的状态维度，避免将所有状态合并为一个产品状态：

业务运营层面设三档控制，强度递进：

• 停用：不允许发起新业务申请，在途业务可继续、符合后续条件的仍可放款——停止新增、保持存量连续；
• 暂停：不允许发起新业务，在途业务保留但不继续放款——同时控制新业务进入和在途业务形成新的风险暴露；
• 停牌：总行风险管理责任基于产品风险表现实施的独立风险管控，不允许新增，在途业务原则上不放款，特殊需要按特别申请规则处理；复牌后解除管控。

自动风险触发：产品不良率超过不良停牌阈值时自动触发产品停牌，形成"产品经营数据 → 风险指标 → 阈值判断 → 产品风险管控"的反馈链。产品管理执行产品层管控状态变化，底层信用风险识别和专业判断仍由风险管理能力协同承接。

生命周期与经营分析

产品全生命周期：产品登记 → 产品配置 → 产品测试 → 审批发布 → 运营使用 → 产品变更 → 新版本发布 → 运营控制/恢复 → 退出。退出后历史业务仍保留原产品身份和必要历史信息，用于存量业务管理及追溯。

产品分析从四个角度形成经营视图：业务表现（进件、授信人数与金额、余额、放款、审批通过率、放款记账率、逾期率、不良率等）、流程效率（各处理节点用时、瓶颈、产品与机构间效率差异）、版本分析（规则配置演进与经营表现结合）、经营与风险闭环（“经营数据 → 表现分析 → 问题识别 → 产品调整/运营控制 → 新版本或状态变化”）。分析结果通过正式产品变更和版本管理落地，不直接修改当前有效配置。

与其他领域及企业级产品体系的协同

产品管理作为跨生命周期的专业对象管理领域，与客户管理（客户类型分类参与适用性判断）、业务准备、尽职调查、授信申请、审查审批、额度管理（产品决定是否纳入统一授信及使用规则，额度结构仍由额度管理主责）、押品管理（差异化抵质押率，押品类型价值权证仍由押品管理主责）、合同签约、放款管理（停用/暂停/停牌影响业务执行）、贷后管理（状态变化不改变历史产品归属）、公共管理、风险管理专业能力及核心系统协作。

企业级协同上，全行产品谱系平台是企业级产品目录及产品生命周期主数据来源，智慧信贷产品中心承接统一产品身份和目录信息，并在此基础上维护信贷业务所需的产品条件和详细配置，形成"企业级产品目录/状态 → 智慧信贷产品身份 → 信贷产品条件与配置 → 授信及执行业务使用"的协同链，同时向其他业务模块和外围系统提供产品目录与配置信息服务。

1.1.8 - 业务架构成果汇报（V1.4）

依据《智慧信贷二期业务架构成果汇报（合稿 V1.4，0927）》分析总结。这份汇报呈现的是新一代业务架构基线：按客群/产品线/价值链维度划分 19 个业务领域、48 个业务对象、124 项业务能力（本期范围 66 项、一期已建 9 项、非本期 49 项）、23 个业务组件。与《业务架构说明书》的 11 领域/40 组件/68 能力/33 对象相比，这是口径演进的更新版本——领域按客群与产品线细分（客户管理拆分对公/对私、贸易融资三分、新增风险资产管理与信贷资产转让等），组件重新定义为跨领域共享的责任单元（每项能力与业务对象各有唯一负责组件，不再归属单一业务领域）。

方法论：TOGAF ADM 三阶段

项目整体沿 TOGAF 架构开发方法推进：A 阶段（架构愿景）——预研项目全范围、全维度、全流程开展，新三年战略解析、能力评估、范围定义与高阶架构要求；B 阶段（业务架构）——引入参考业务模型完成业务建模（流程/产品/实体三类模型）、制定目标业务架构、重点问题二次征集、AI 场景落地、关联影响分析并形成业务架构基线；C 阶段（信息系统架构）——应用架构设计与数据架构设计。

架构成果构成：四要素

• 业务领域：流程建模中紧密关联业务活动的集合，构建企业能力统一视图的"纵向"结构；按客群/产品线/价值链等维度划分，领域之间不重叠、不遗漏，相对稳定、不随组织调整频繁变化；
• 业务对象：数据模型中紧密关联实体的集合，按业务事实组织，共性对象与特色对象保留扩展关系；
• 业务能力：组织执行特定业务活动或达成特定业务成果的能力，回答"组织能做什么"，独立于流程、角色和技术实现，以稳定动词+业务对象命名；一个流程可由多个能力共同承接，渠道差异不直接形成独立能力；
• 业务组件：按稳定业务职责形成的责任单元，聚合相关能力和业务对象，通过边界明确的业务服务对外提供能力；组件跨领域共享，与系统中心、产品组件分别定义。

19 个业务领域按性质分四组：客户管理类（对公客户信息管理、对公客户管理、对私客户信息管理、对私客户管理）；信贷业务类（对公贷款、国内贸易融资、国际贸易融资、贴现、个人贷款、信贷资产转让）；风险管理类（风险资产管理、信用风险管理、风险政策与风险报告、外部协查与报送管理）；支撑类（市场营销、产品创新管理、同业合作管理、数据应用服务、信贷管理）。

23 个业务组件：政策与计划、产品管理、对公授信作业、个人授信作业、信用评级、风控规则、风险监测、监管报送、额度管理、押品管理、客户管理、营销管理、合同管理、担保管理、放款执行、贷后履约、贷后管理、贸易融资、贴现、信贷资产转让、风险资产处置、信审分析支持、业务资料与档案——每个组件均定义了业务接口（输入/输出对象与协作组件）与关联关系。

重构一：授信额度体系

建立 6 大层级额度管理体系，完成 270 款产品、152 类业务场景、289 类额度占用场景的额度适配和规则分析。十大要点：

1. 重塑以客户为纬度的统一授信：全量业务场景划分为综合授信额度、专项授信额度、非授信额度三类，不承担信用风险的场景从授信额度剥离；首次实现产品层集中额度管理（流贷、贸易融资、项目贷、营销产品全量涵盖，营销产品从标签管理升级为额度化管理）；
2. 双额度管理模式：集团额度、客户额度与具体业务额度分离——前者管控整体授信承受度和整体风险，后者以产品场景和具体用信期限为基础管理；
3. 按年授信：建立"年度授信"概念，客户授信与业务授信分离，客户授信管控统一授信额度上限和按年风险分析；
4. 组合产品额度：以组合产品+组合产品额度解决营销产品与基础产品共存，可快速装配可全面额度审批的创新产品；
5. 评授一体：评级流程与授信流程整合，大幅压缩同审批路径的处理效率；
6. 集团并表统一授信：理财子、金租额度纳入集团并表口径的客户纬度统一授信；
7. 低风险授用分离：“低风险额度年度授信 + 低风险单笔单批"结合，统一授信与快捷用信兼得；
8. 合同金额占用规则：额度占用从"以余额为基础"调整为"以合同为基础”，配套"合同+首笔提款"占用模式、合同部分失效/生效，防止恶意无效占用；
9. 代客衍生品额度调整：远期结售汇保证金纳入低风险额度管理，按户授信统一批额度；
10. 授信场景全覆盖：全风会审批的平台额度、集群额度等非授信额度纳入统一额度体系。

重构二：集团客户管理

• 并表客户信息共享：整合母行、理财子、金租全链条客户数据与风险数据，搭建集团统一实时更新的客户中心，基于"并表客户中心+量化算法"实现集团客户统一识别与管理，覆盖全业务全流程风险场景；
• 全集团全场景授信：将游离于集团授信外的个贷客户、个贷场景公司客户（担保公司等）、合作方、交易对手信用风险统一纳入，实现全量授信统一额度管理，与监管要求、集团并表管理对齐；
• 预留额度全场景支持：打通预留额度申请、审批、申请用信场景，实现真正的预留、分配使用；
• 被动触发的征集与探测：集团授信申报从用信机构主动上报改为集团授信申请自动触发全部子公司授信征集，配套额度征集规则实时监控、15 工作日有效期、年度集团授信；
• 差异化分组管理：分支行分组、板块分组和自由分组三种模式，解决同一集团内分支行额度抢占与使用效率问题。

重构三：授信作业体系

以客户统一授信为基础，实现集团、客户、产品、用信、贷后五维统一，首次打通"客户→授信审批→用信→贷后及预警"全链条。八个要点：一次授信申请同时申报审批"评级+综合/专项/非授信全部额度"；尽调报告从 53 个统一为普惠/一般法人/同业/集团/简易 5 类并按业务自动增减内容；银团采用"授信端轻数据+用信端重数据、审批二次确认"模式；建立全流程闭环的业务分析体系（补齐商票、供应链等他用额度的执行段缺位）；以具体用信场景为基础的额度启用规则（替代按批复整体启用）；担保变更纳入批复流程（减担保走变更、增担保简化）；建立全场景流程修改类流程、限制"特殊事项"减少改库；形成全量审批矩阵——按审批场景（业务活动/模式/类别/权限/产品分类五类）、审批模式（人工审批含总行任务池/分支行一站式，及系统审批）、审批权限（三类层级组合成总分支、总支支、总分分支、总行直达、分支行自审五类路径）三维梳理，超权限业务配套集体评议/大审会/董事会机制。

风控决策引擎升级

构建"贷前准入、贷中监测、贷后预警“全周期风控体系：贷前反欺诈、客户评级、准入规则拦截；贷中实时监测资金流向、客户行为、风险指标异动；贷后风险预警、分级处置、智能催收、风险台账追溯。六大中心：数据中心（风险集市统一指标口径、统一数据视图）、变量中心（变量全生命周期管理与指标资产化）、策略中心（可视化+版本管理、灰度发布、一键回退、效果分析）、预警中心（数据/模型/服务/系统全方位监控）、监测中心（数据质量与模型漂移实时监控、统一看板）、实验中心（仿真沙盒、历史数据批量回溯校验）。

风控模式转型：首次建立以制度规则为基础、风控规则为支撑的”制度规则化 + 规则机控 + 模型预警“三位一体风控体系，从"人控为主"转向"人机协同”，关键环节刚控与柔性控制规则固化入系统。首次将集团并表、个人全口径限额纳入统一额度与统一风险监测体系。

AI 与智能化

• 全场景 AI 原生赋能：首次采用原生 AI 嵌入与测试前置模式，将行内十余年信贷专家经验转化为 AI 风控规则，为"AI 数字专家"模式打基础；已落地审查人专属 AI 能力、批复登记专属 AI 能力；
• AI 提效：研发专属 AI 技能用于代码分析、财报规则分析、风控规则分析、需求质量分析——财报规则识别验证仅需 2 天（提炼闭环规则 1000 条），较人工缩短 1 个月以上。

业务建模成果

• 流程建模：对公信贷 16 个、个人信贷 13 个、信用风险 14 个流程模型（共 43 个），以活动任务图+PDS 文档定义执行逻辑、角色与流转规则，完成实体-流程对接矩阵与交叉映射；
• 产品建模：五级产品目录（产品线/产品组/基础产品/可售产品/组合产品）全量规整，产品条件 203 个、产品组件全量，完成 5 款可售产品装配打样（优易贷、短期流贷、房抵快贷、房地产开发贷、国内福费廷），明确与行内谱系平台的对接策略；
• 实体建模：对公信贷、个人信贷、信用风险、客户管理四领域实体清单、属性清单与 ER 图，实体属性与行内数据标准挂接并补充监管信息项。

调研与需求成果盘点

其他亮点：首次建立参数化组件化信贷产品中心（准入配置、存续期管控监测、停复牌全生命周期）；首次将理财子、金租客户纳入统一客户中心（“一户一画像”）；首次打通电脑、手机、PAD 全渠道的"移动+PC"接力作业；全品类押品库与全场景押品管理（评估、抵质押、风险查询、重评、解质押）。

承接转化

业务架构设计对预研成果实现"战略→预研→实施“全链路闭环映射，四大承接：流程承接（目标业务流程梳理设计，六类业务三维审批矩阵梳理）；产品承接（目录规整、星图协同、统一产品配置模板）；数据承接（对象/实体/属性清单、ER 图、数据标准挂接，解决口径不统一与关联缺失）；公共能力承接（授信作业模式、额度体系、客户管理、产品管理、押品管理、合同管理、风控支撑、AI 智能化八大专题，形成公共能力中心设计）。

架构图

新一代业务架构总览（19 领域 × 23 组件）：

全屏打开 ↗

授信额度体系重构（双额度 + 按年授信）：

全屏打开 ↗

1.2 - 应用架构

智慧信贷项目的应用架构文档。

• 应用架构设计：业务架构承接映射、五层应用结构、20 个微服务、依赖调用约束、数据库划分与定级治理

1.2.1 - 应用架构设计

下载矢量版 SVG

依据《新一代智慧信贷平台-技术架构设计》第一章（业务架构承接）与第二章（应用架构）提炼。技术架构设计严格以固化的业务架构基线为前置输入，向上对齐业务语义与责任边界，向下完成技术转化，实现业务组件服务化、业务能力功能化、业务对象数据化、业务场景流程化。

业务架构承接

技术架构以业务架构标准化的四大核心要素为主轴，各要素承接价值层层递进：

业务架构由此构建"领域分层、组件承载、能力落地、对象托底"的稳态结构，解决原有权责模糊、流程割裂、能力碎片化、数据口径不统一的问题；技术架构在此基线上完成精准映射，避免服务划分与业务责任错位。

新一代基线更新（0927 汇报）

依据业务架构成果汇报（V1.4），业务架构基线演进为19 个业务领域、48 个业务对象、124 项业务能力（本期 66 项、一期已建 9 项、非本期 49 项）、23 个跨领域业务组件。领域按客群/产品线/价值链细分（客户管理拆分对公/对私、贸易融资三分、新增风险资产管理与信贷资产转让等），组件重新定义为跨领域共享的责任单元。对应用架构的影响有两点：其一，AI 与智能化成为业务架构的正式组成部分（智能信审、专属 AI 能力、风控决策引擎），应用架构需承载 AI 子应用与 AI 能力；其二，一期已建能力（9 项）与评级、风控类组件进入本期组件清单，应用架构需体现对一期成果的复用与扩展（详见AI 与智能化应用与一期已建能力承接两节）。

应用架构总体结构：五层

应用架构自上而下分五层，核心是"敏态作业 + 稳态能力"的双层信贷架构——流程敏捷迭代、核心能力稳定复用：

• 渠道展示层：本次建设直接负责信贷门户（PC 端）与个人移动信贷（PAD 端）；行内小程序、手机银行、企业网银不参与前端建设，仅以接口方式提供服务。
• 接入层：系统对外统一入口，封装内部能力中心避免直接暴露。三大职能：安全管控（统一认证与鉴权）、联机交易调度（服务网关路由分发、负载均衡至后端微服务）、批量交易调度（批量调度平台完成任务编排、监控与负载均衡）。
• 作业层（敏态）：由信贷系统抽离的作业中心构成，覆盖贷前、贷中部分生命周期，统一管理与驱动流转阶段的状态迁移和业务形态转换。含对公授信作业中心、零售授信作业中心、授信执行中心和查询中心（为减少能力层互相调用而设的跨域聚合中心）。设计原则：跨多个中心的复合查询须上提作业层整合；仅涉及单个能力中心的交易直接调用，无需作业层编排。
• 能力层（稳态）：所有业务能力的聚合与抽象层，将公共核心能力（客户、押品、额度、授信批复、外部信用信息、影像档案等中心）封装标准化，向上提供统一调用服务。遵循高内聚低耦合；涉及多个能力中心的数据交互须经作业层调度协调，禁止能力层调用作业层。
• 支撑层：三类支撑——基础服务（系统管理、鉴权、门户、档案管理）、工具与平台（流程中心、规则引擎）、批量交互服务（批处理及与外围系统的批量数据交换）。

20 个微服务清单

服务划分原则

数据主责（按数据责任归属聚合分析）；稳态下沉（面客与内部审批分离、过程与结果分离、配置与运行分离，稳定功能沉淀为公共能力）；边界清晰（一个微服务只负责一块业务，功能不重叠）；去中心化（主线功能可拆分，不能只剥离周边工具类功能而残留中心节点）；基于性能（高性能压力模块独立，联机与批量分离、业务功能与统计分析分离）；规模可控（防止服务划分后形成新单体，公共领域层功能尤其防膨胀）。

服务依赖与调用约束

依赖原则：上层可依赖下层、下层不依赖上层；同层可单向依赖，不可交叉、循环依赖；原子服务不能依赖聚合服务；核心服务不直接依赖非核心服务，需通过防腐层访问；技术类服务不依赖业务功能服务。

调用约束（硬性）：一次同步交易的调用链上不可超过四个服务，异步调用（经队列）视为链条终断、链长重新计算；一次同步交易杜绝循环调用。以此防范长调用链与循环依赖带来的超时和雪崩风险，同时约束作业层编排复杂度。

服务划分过程

采用"流程分析 + 复用性分析"两段技术，自上而下拆解业务能力：

• 流程分析：对端到端流程的原始业务活动做拆解（按主业务对象、生命周期阶段、稳敏属性、执行模式拆分，不拆到技术步骤）与融合（同对象同目标强绑定活动、跨流程等价语义活动、对外表现为一个业务节点的多原子活动），输出标准化业务活动清单，并按"活动生命周期是否依附特定流程实例"初判归入业务处理域能力（敏态候选）或基础业务域能力（稳态候选）。
• 复用性分析：向上分析对原子活动做三重复用判定（全行适用、跨端到端流程、跨产品/产品系列，三者同时满足才为公共活动），区分公共业务活动（待下沉）与差异化活动（保留上层）；向下分析将公共活动拆解为单一原子服务、组合原子服务，并识别业务聚合服务候选。内部逻辑无差异但复用场景少仍判差异化不下沉——下沉以真实复用广度为准。
• 服务收敛：原子/原子组合服务归稳态能力层（按主业务对象归集），业务聚合服务归敏态作业层（按业务场景归并），原子与聚合服务不得混置同一微服务；批量、台账报表类按"基于性能"原则拆入批量微服务与查询中心；最后校验依赖约束并以对公授信全流程、放款流程反向走查。

数据库划分

三原则：业务域边界（每微服务对应独立限界上下文，业务主数据所有权唯一归属主责微服务）；就近高内聚（聚合根实体与从属子实体、明细流水统一置于主责服务库）；单一可信数据源（每份数据仅一份主库，下游只可维护只读副本且不可修改）。

落地为：三个作业库（对公授信作业库、零售授信作业库、授信执行库）、八个能力库（客户、产品、额度、押品、授信批复、外部信用信息、影像档案）及系统库、批量库；信贷网关与移动前置无库；查询中心、批量微服务为多数据源。

微服务定级

20 个业务与技术微服务按业务影响（高：影响外部客户与我行形象；中：影响行内业务人员；低：仅影响科技团队）与技术影响（高：故障导致大面积服务不可用；中：影响部分服务且恢复迫切；低：影响有限）两维评估，决策矩阵输出高/中/低三级。

高等级服务包括：信贷网关，对公/零售授信作业中心、授信执行中心，客户、产品、额度中心，流程中心、规则引擎，注册/配置中心与缓存服务。运维保障分级：高等级核心联机服务多副本跨可用区部署、数据库主从高可用、最高优先级告警；中等级双实例集群；低等级以故障隔离为首要目标。跨等级依赖管控：高等级服务禁止强同步依赖低等级服务，必须经防腐层调用，隔离低等级故障向核心链路传导。

微服务治理

治理以资损风险防控为首要目标，基于微服务运维管控平台执行与观测，覆盖服务生命周期、流量韧性、可观测性、安全、运维变更（配置）五大治理域。核心原则：

• 双层流量故障隔离：网关层治理经网关的 HTTP 流量（API 暴露管控、路由、限流熔断、IP 黑白名单、负载均衡），微服务服务侧治理全部入站流量（含行内 ESB 转发、网关转发、内部 RPC）；写交易接口两处均禁用重试，幂等、防重、事务校验等核心防护下沉业务代码实现。
• 可观测先行：日志采集与调用链埋点接入平台先于防护策略上线，重点关注 P99 长尾耗时，依观测数据迭代治理阈值；监控含服务/接口监控、链路跟踪、日志中心、服务拓扑。
• 配置可信可控：业务开关、限流阈值、参数统一配置中心托管，禁止硬编码；版本历史、灰度推送、一键回滚，敏感配置加密存储。
• 平台能力互补：运维管控平台承担注册实例运维、网关管控、服务侧流量治理、配置与全链路可观测；外部第三方调用鉴权由行内 ESB 统一承接；微服务内部 RPC 容错与业务校验由业务代码实现。

AI 与智能化应用

新一代业务架构将 AI 与智能化纳入正式架构范围，应用架构从前端集成、作业内嵌、引擎支撑三个层面承载：

• 微前端双子应用集成：信贷门户作为微前端基座统一管理用户、机构、角色与菜单，信贷系统与智能信审平台为两个平级的微前端子应用——智能信审的业务入口（悬浮按钮、页面跳转、iframe 嵌入）直接嵌入信贷作业页面，前端互操作发生在两个子应用之间；后端通过 ESB 与信贷各业务中心集成。智能信审承载授信全场景 AI 应用与支持体系（详见 AI 模块·智能信审业务架构）。
• 作业环节专属 AI 能力（已嵌入审查审批与执行作业链路）：①审查人专属 AI——基于资深审批人专业调教的审查意见与风险提示自动生成，支持意见溯源与内容扩写，内嵌修改记录持续优化；基于历史审批案例的相似案例分析与审批建议（本体层统一规范）；②批复登记专属 AI——按业务风险与合规要求生成批复前提条件和管理要求建议；③出账放款专属 AI——自动抓取批复前提条件与 235 项信贷制度要求，对出账放款的影像资料、借款合同、担保合同进行 AI 合规审核；④行内信贷领域专属知识库——AI 赋能信贷业务的核心数据底座（制度、风险案例、产品与系统操作指引、信贷政策、行业研究），支撑全场景对话式专业意见；⑤信贷全场景 AI 问答助手。
• 风控决策引擎升级（六中心）：作为风控支撑专项，构建"贷前准入、贷中监测、贷后预警"全周期体系——数据中心（风险集市统一指标口径与数据视图）、变量中心（指标资产化与全生命周期管理）、策略中心（可视化编排、版本管理、灰度发布、一键回退）、预警中心（全方位实时监控异常预警）、监测中心（数据质量与模型漂移监控看板）、实验中心（仿真沙盒与历史数据回溯校验）。配合"制度规则化 + 规则机控 + 模型预警"三位一体风控模式，实现从"人控为主"向"人机协同"转型。

应用侧落位：智能信审平台独立建设前后端（前端子应用 + 后端服务群，经 ESB 集成）；专属 AI 能力嵌入作业中心流程节点；风控决策引擎作为独立风控支撑平台，被作业与执行环节调用。

一期已建能力承接

业务能力 124 项中标注一期已建 9 项，主要集中于评级与风控领域；23 个组件中的信用评级、风控规则、风险监测等组件承接一期成果，本期以组件化方式整合复用并扩展：

• 信用评级组件（支撑信用风险管理领域）：整合对公客户评级、零售客户评级、债项评级、违约认定/重生四项能力，形成客户内部评级、债项评级与违约认定结果，为授信决策、风险监测和风险报告提供一致的信用评价信息。职责边界：负责等级与违约状态认定维护，授信作业据此作业务授信决定，风险监测结合评级形成分类与减值评价。
• 风控规则组件：将有效风险管理要求组织为适用范围和版本明确的风控规则，提供规则校验、命中及阻断结果，并按有效解除条件处理阻断解除（管理风控规则、解除风控规则阻断两项能力）。规则阻断解除不等同于业务审批或额度恢复。
• 风险监测组件：持续识别客户、业务、押品及国别信用风险，整合计量信用风险、压力测试、资产风险分类、减值估值计提、大户风险监测、预警监控与处置等 12 项能力，形成预警信号与风险监测评价结果。

应用侧落位：上述组件复用一期已建系统成果，按本期组件接口（输入/输出对象与协作组件）重新整合——评级结果、风险规则、预警信号作为专业输入被作业层与执行环节引用；与风控决策引擎六中心协同，规则机控与模型预警落在引擎侧，评级与监测事实落在组件侧。二期各中心在既有基础上升级：客户中心建立"权限先行、建档后置"机制、集团并表客户中心（打通金租、理财子）、集团线索探测量化评分、全行统一客户标签库与 360°全景视图；授信执行中心引入合同 AI 智能比对、法审流程一体化、全链条风险规则前置、合同电子化放款一站式；产品中心首创组合产品模式、产品风险监测闭环与产品工厂（配置-审核-快速上线）；押品中心实现政务生态直连（抵押登记全线上闭环、分钟级办理）、多模型智能估值矩阵与押品"数字身份证"全生命周期管控。

应用架构图

总体结构图（V1.1）——五层结构依据技术架构设计文档应用架构章节绘制，补充 AI 与智能化、一期已建能力：

下载矢量版 SVG

核心五层结构（20 微服务，交互版）：

全屏打开 ↗

扩展视图（AI 与一期已建承接）：

全屏打开 ↗

1.3 - 技术架构

智慧信贷项目的技术架构文档。

• 技术架构设计：前后端分离六层架构、开发平台四统一、流程/规则/调度/注册配置/管控/分布式事务平台组件

1.3.1 - 技术架构设计

依据《新一代智慧信贷平台-技术架构设计》第三章（技术架构）提炼。系统整体采用前后端分离架构，自上而下分为渠道层、展示层、网关层、服务层、持久层、支撑层六层。

总体分层

技术组件按四类开箱即用：安全类（授权权限、国密 SM2/SM4、AccessFilter、XSS 防御、数据脱敏、数据权限）、数据交互类（MybatisPlus、HikariCP）、服务通信（OpenFeign、RocketMQ、Redis 幂等、Loadbalancer）、运维工具（异常处理、Logback/Slf4j、文件上传下载、序列号、Session、Saga 分布式事务）。技术栈版本以行内安全规范为标准（详见原文组件版本表）。

开发平台：四个统一

• 统一的设计规范：用户体验、界面交互、组件设计、代码四类规范全流程标准化；
• 统一的开发模式：前后台分离、开发分离化/技能专业化/实施工艺化、全生命周期持续集成；
• 统一的开发工具：一体化开发平台、可视化拖拽与代码生成、多架构适配（单体/微服务）、自动化运维；
• 统一的技术平台：自主可控底座、统一技术栈标准、松耦合高复用架构、全渠道场景适配。

流程引擎 echain

宇信科技自主设计研发的一套基于数据库的工作流微服务组件，定位解决所有与工作流流程相关的线上活动，适用于信贷审批、自动审批类（半人工半自动/自动授信流程）、公文审批、人事财务等广泛场景。产品 2004 年诞生，历经四个大版本迭代：echain1.0（产品雏形）→ echain2.2（基于 WFMC 标准）→ echain3.X（无缝对接 YUSP 统一开发平台）→ echain V4.X（SpringCloud 分布式版本）。在智慧信贷中对应支撑层的流程中心微服务，承接"作业协同"业务能力（统一管理与驱动流转阶段的状态迁移，见应用架构）。

六大产品特色

• 可视化建模工具：Web 版流程图建模，托拽绘制、定义便捷；
• 图形化监控：可视化审批轨迹监控，直观监管流程办理全过程；
• 流程仿真：验证绘制完成的流程图能否成功运行、是否符合配置的路由规则，再上线；
• 智能路由：路由运行动态脚本控制流程走向，应对复杂审批场景；
• 丰富的审批动作：提交、打回、退回、转办、否决、作废、子流程、项目池、跳转、拿回等；
• 更强的扩展性：审批人员、提交条件、路由条件等均可自定义扩展。

功能模块与流程定义

四大功能模块：流程管理、流转引擎、我的工作台、流程监控。流程定义支持流程图增删查改、导入导出、复制，启停与流程图热部署，以及生成新版本的版本管理；流程图管理提供 Web 页面托拽绘图，属性栏支持配置多种审批动作与业务操作。

节点体系

• 必须节点：开始/结束——一个开始、多个结束；
• 人工节点：普通（支持审批后业务处理，可配置节点审批权限/审批按钮）；单选/条件单选（提交后续流程时必须从分支中选择一个，条件单选可在与后续节点连线上配置路由条件，结果为"真"的才能被选择）；多选/条件多选（可从后续多条连线中选择多个分支提交）；
• 自动节点：汇总（非人工节点，多选分支后必须进行汇总）；自动运行（引擎自动提交到后续节点，支持配置业务处理）。

高级属性配置

节点级丰富配置：处理人员（拥有审批权限的用户或对象）及计算方式、人员指定（提交到下一节点时的分配方式：人员列表选择、系统指定）、办理类型（节点内多用户的单人/多人办理模式）、待办通知方式、任务分配策略、节点标识、子流程配置、节点脚本；提交条件与启动条件（按配置判断，支持扩展）；业务处理（审批完成后由流转引擎调用，含业务通知接口与业务处理扩展接口）；智能路由（路由条件的 Java 脚本在线编辑，或经接口实现自定义规则校验——如扩展决策引擎）。

流转引擎：审批动作全集

• 基本动作：发起（构造流程参数发起流程数据）、提交（同意流转至下一节点）；
• 回退类：退回（前节点/发起节点/指定节点，可扩展、可连续退回）、打回（已办理节点，可连续打回并可自定义打回节点列表）、拿回（本人已办理且运行中的流程拿回本节点）、撤回（发起人从任何节点拿回初始节点）、否决（标识流程结束）、作废（被退回/打回后发起人作废流程）；
• 协同类：转办（转交他人办理）、协办（他人办理后流转回本人）、跳转（交由流程中其他节点，可扩展）、抄送、催办（特定方式催促办理人，可扩展）、挂起/唤醒（挂起后无法审批）；
• 子流程：流转到特定节点时发起子流程，支持手动/自动、同步/异步；
• 高级操作（管理员）：重置节点办理人、激活已办结流程（激活后回到发起节点）。

工作台与流程监控

我的工作台提供待办数据（当前审批人与节点、流程审批状态、多条件查询；详情含业务页面展示、丰富审批动作与审批历史路线查看）、项目池（关联岗位人员认领项目池任务后审批）、委托（将委托人业务委托给被委托人，可自定义业务范围与委托时间段）。流程监控从不同维度查询展示流程实例数据，帮助管理员分析统计流程运转情况，并提供超管操作（如废除实例）。

集成与扩展

部署依赖数据库，Redis、邮件服务器、MQ 为可选中间件。扩展开发采用流程属性扩展接口模式（如启动条件判断的 StudioBeforeStartInterface）：添加实现类继承指定属性的抽象类接口，定义扩展选项显示名称即可注入引擎。工作流相关表以 N_WF_ 为前缀（如 N_WF_FLOW 流程图记录表）。

规则引擎

将业务规则从程序代码剥离，业务人员可视化配置业务决策，运行时可修改。功能架构分两层：

• 上层核心规则层（规则全生命周期）：规则管理 10 项操作（新增、复制、修改、删除、查询、导入导出、启停、仿真——先仿真验证再启用，避免错误规则影响生产）；规则编辑（语法检查、6 种规则类型）；版本管理（新版本留痕、可追溯、可回滚，满足合规审计）。
• 下层基础资源层（三大支撑模块）：模型库（规则分组容器与权限隔离）、指标（“客户年龄"“逾期次数"等原子判断因子，统一定义避免口径不一）、数据集（数据源与 SQL 管理，SQL 可测算后上线）。

规则形态支持自由规则、评分卡、决策树。

调度平台 USE

宇信企业统一调度平台，支持断点续跑、失败重试、交易补偿，可与行内调度工具及 ETL 集成。逻辑上由管理端、调度引擎、执行节点三个组件构成；对信贷系统而言，执行节点就是信贷批量服务。系统架构自上而下分三层：

• 管控层（系统管理及监控平台）——面向运维/管理员的人机交互门户，五个功能模块：应用管理（数据源、日历、事件、作业流程、触发器、公共参数、执行集群、批量重跑方案等基础环境配置）；系统监控（任务监控、触发监控、作业清单、警示监控、资源监控、事件查看的全局运行看板）；警示管理（警示模板、警示对象、作业告警、资源告警的告警规则配置）；平台管理（应用系统注册、应用授权、作业类型维护，管控可调度任务的类型范围）；OCA 功能（机构、角色、用户、功能/数据授权、菜单、数据字典、日志审计的统一权限体系）。
• 调度引擎（核心调度层）——批量任务的中枢"大脑”，四个子模块：任务管理（任务初始化、后置处理、任务清理，负责调度实例创建、收尾与资源回收）；作业管理（作业前置校验、事件检查、调度分发、任务分片派发、后置处理与扩展）；执行节点管理（节点注册、上下线处理、启停指令下发、心跳探测）；底层支撑（主备切换、调度线程池、告警通知、资源管理，保障引擎自身高可用）。
• 执行节点（远端执行层）——内嵌在业务服务中，四个子模块：主控制器（与调度引擎的通信中枢：节点注册/下线申请、心跳上报、作业接收、状态控制、作业中断）；执行器（六种作业类型的实际运行载体：BEAN、SHELL、SQL、存储过程、SP、HTTP，可执行代码脚本、数据库、接口类批量任务）；状态汇报（作业运行结果与日志的回传通道）；健康检查（健康状态与 CPU、内存、存储、JVM 指标采集上报）。

调度操作层面提供调度首页（全局运行视图）与作业流管理（作业流定义、依赖编排与重跑）。

核心能力：定时/周期/事件触发多模式调度，可视化配置任务依赖（任务 A 完成触发任务 B）与优先级管理（高优先级抢占资源）；大批量任务分片拆分与并行执行（如百万级计息任务拆分多节点并行），日终批处理多机随机分配且不重复执行。容错与可靠性：断点续跑（异常中断后避免重复处理）、失败自动重试（全量或增量）、幂等与互斥（“运行中单任务不允许重复调用”、“约定时间段内禁止重复运行”）。集成与资源管控：与行内 Control-M 调度集成；数据抽取与 DataStage 集成，报文符合行内 ESB 标准；可视化作业并发数在线增减；时效约束为单个批量任务 ≤0.5 小时、总时长 ≤2 小时，超时自动告警。

全屏打开 ↗

注册/配置中心 Nacos

信贷门户微服务全部依赖 Nacos 做服务注册与配置统一管理。架构四层：客户端层（Provider 启动注册 IP/端口，Consumer 拉取实例列表寻址）、服务端核心（Naming Service 命名注册 + Config Service 配置中心）、一致性协议层（Distro AP 协议管服务实例——可用性优先；Raft CP 管配置数据——一致性优先）、持久化层（开发测试用内置 Derby，生产用 OceanBase-MySQL 租户）。

核心流程：服务注册（SDK 上报→心跳维持→异常剔除）、配置拉取与动态推送（控制台修改→长轮询实时推送各微服务，改配置不重启服务）。

管控平台

微服务全生命周期管控体系，从系统管理、服务部署、服务治理，到监控日志、配置中心、告警中心，形成覆盖服务从上线到运维的完整闭环（自动化发布结合 DevOps 平台实现），为微服务架构提供一站式、全链路的技术支撑与管控能力。

• 服务治理：外部请求先进 API 网关，治理管控向其推送服务注册发现、路由、限流熔断等策略完成流量入口统一管控；API 网关将请求转发至后端微服务后，治理管控再推送服务治理策略，实现运行阶段全链路治理。配置策略：运维管控台可视化配置 → 推送配置中心 → 实时同步微服务（主动监听最新配置），保障配置实时生效，运维台也可在线读取配置形成闭环。技术实现与 SpringCloud Gateway 结合的六个要点：网关作为统一流量入口（路由转发、负载均衡、协议转换）；通过 Nacos 实时监听路由/限流/熔断规则，配置变更动态刷新无需重启；接入注册中心按服务名动态路由，支持上下线自动感知；运维平台统一配置路由、限流、熔断、权限、超时等策略经配置中心推送执行；网关完成鉴权、流量控制、日志与链路追踪，统一处理跨域、重试、降级；请求闭环为"外部请求 → SpringCloud Gateway → 治理规则校验 → 动态路由转发 → 后端微服务 → 结果返回”。
• 部署发布：部署中心四项功能——主机管理（部署主机管理）、应用管理（微服务登记）、制品管理（zip/tar/tar.gz 制品上传）、应用部署（先选制品，再选部署应用与主机执行部署；前提是系统接入注册中心且主机安装 agent）。
• 监控告警：面向分布式系统的统一微服务监控平台，覆盖业务监控、应用层监控、中间件监控、链路监控、主机监控五大监控域，遵循行内监控体系规范实现全栈可观测。支持多技术栈应用、数据库、Redis、MQ 等基础组件一站式集中监控；针对接口服务持续采集访问量、响应延时、调用成功率等核心指标；内置异常检测能力，快速梳理异常关联范围，定位涉及的接口与主机，区分单机故障与集群共性问题；针对 Java 应用采集 GC、内存、线程等 JVM 指标。技术实现基于 Prometheus + AlertManager + Grafana：Prometheus 集群负责采集应用、主机、中间件、数据库等目标指标；Grafana 实现监控大盘与告警看板统一展示；Prometheus 的告警规则统一推送 AlertManager 集群，完成告警的去重、分组、路由与通知分发。

全屏打开 ↗

分布式事务 Saga

采用 Saga 模式并做三方面改进：去除协调中心 server 端（无需独立部署，事务状态存业务数据库）；框架以 SDK 嵌入（状态机引擎与事务管理下沉）；业务补偿由框架触发（无需硬编码）。核心组件：事务协调器 SDK（状态机引擎 + 补偿管理器）、事务状态存储（基于业务数据库）。

三条强制原则：业务幂等性（正向与补偿操作都必须幂等）、事务边界约束（Saga 不跨服务传播，只能在发起服务内编排，下游用本地事务保证一致性）、补偿可达性（补偿必须能执行成功，下游必须提供补偿接口）。失败处理：补偿失败自动重试（定时补偿器，3 次）；人工处理支持手工重试补偿与强制标记补偿结束。

技术架构图

全屏打开 ↗

1.4 - 集成架构

栏目建设中，将收录系统间接口清单、上下游依赖与集成数据流。

1.5 - 部署架构

智慧信贷项目的部署架构文档。

• 部署架构设计：同城双活方案、五类接入通道、中间件跨中心部署与高可用架构

1.5.1 - 部署架构设计

依据《新一代智慧信贷平台-技术架构设计》第四章（部署架构）提炼。整体采用同城双活方案：双中心两个虚拟机集群（业务集群 1/2），网络互通，通过负载控制向两个业务集群分发请求。

接入通道

中间件部署

• Nacos 跨中心部署：以 clusterName 区分（生产中心 A_ZONE / 灾备中心 B_ZONE），依赖 spring-cloud-starter-loadbalancer。正常情况各中心服务优先使用本中心 Nacos，两中心间同步复制；某一中心 Nacos 异常时服务访问另一中心。
• Redis 跨中心部署：虚拟机部署集群，一主三从五哨兵。跨中心的原因：登录 token 需全局共享（请求随机分发到两中心，若各自部署 Redis 会鉴权失败）；数据字典、风险拦截信息等缓存需保持两中心一致。
• RocketMQ 中心级部署：每个中心各部署一套集群，各中心独立生产和消费。
• 管控平台：整体部署一套，组件跨中心部署，统一管理两个集群，实现跨中心数据整合与监控。

高可用方案

两个中心为"生产中心"和"灾备中心"，每个中心部署完整的业务集群，任一中心完全不可用时另一中心可继续支持业务全流程执行。

注册中心双中心：Nacos 跨中心 3 节点集群（生产 3 + 灾备 2 布点）共用一套集群、共享数据库；服务启动注册并同步各节点，消费者本地缓存服务列表；默认中心内路由，中心内无服务才跨中心访问；通过域名就近解析。

全屏打开 ↗

缓存双中心：哨兵模式——生产中心 Master + Slave-1 + Sentinel 1/2/3，灾备中心 Sentinel 4/5 + Slave-2/3。容灾语义分三级：中心内 Master 宕机，Sentinel 自动故障转移（Slave-1 升主，业务短时波动）；生产中心整体宕机，剩余 2 哨兵无法自动选主，需人工执行 SENTINEL FAILOVER mymaster 将灾备 Slave 提升为主；生产中心恢复时先启 3 个哨兵节点、组网正常后再启 Redis（严禁先启 Redis 后启哨兵），数据同步完成后业务低峰期手动回切（replica-priority 控制）。

全屏打开 ↗

消息队列双中心：每中心 7 台服务器——3 NameServer（内嵌 Controller）+ Broker 2 主 2 从（2M2S），主从同步双写保障消息不丢，基于 Controller 模式（5.x Raft）自动故障切换；任一中心主节点宕机，消息不丢失、服务自动切换。双 Master 多队列负载均衡：队列数 ≥ 消费者实例数，生产者均衡发送、消费者平均分配队列。宇信分布式消息组件提供消息持久化、异步发送与补偿、消费幂等。

全屏打开 ↗

应用双中心：两中心部署完全一样的集群，注册到统一 Nacos（集群标志识别数据中心），每中心可独立完成信贷全流程；中心内就近路由负载均衡。每个应用至少 2 节点避免单点，压力大的服务（授信作业中心、授信执行中心）按压测适当加节点。服务间 Feign 调用 + loadbalancer 负载；网关经负载设备对外；行内系统经 ESB 边车负载转发两中心网关。

全屏打开 ↗

批量双中心：USE 调度两中心部署一套集群——管理端两中心集群部署（token 不共享，需会话保持或灾备侧设为备节点）；调度端主从模式（基于数据库选主，主派发任务，主故障从自动切换）；执行节点即批处理服务多实例负载均衡。分布：每中心 1 管理端 + 1 调度引擎 + 6 个批量服务。

全屏打开 ↗

运维管理双中心：信贷运维管控平台整体一套、组件跨中心。主中心（A 机房）：管控前后端、Grafana、Prometheus+Proxy、2 AlertManager；同城中心（B 机房）：管控前后端、Grafana、Prometheus+Proxy、1 AlertManager。Grafana 跨中心共享数据库配置加负载均衡，AlertManager 集群处理 Prometheus 告警。业务微服务集成链路跟踪 agent 与 FileBeat 日志收集对接行内平台；监控分工——行内监控告警平台负责主机/中间件/数据库，信贷管控平台负责业务微服务。

环境清单

环境清单维护于《智慧信贷二期应用开发实施项目架构设计说明书 V0.3.xlsx》，待应用架构与部署架构确定后同步修订。

部署架构图

官方部署架构总览（复刻版）：

下载矢量版 SVG

提炼版交互图（拓扑关系可缩放追踪）：

全屏打开 ↗

1.6 - 非功能需求

栏目建设中，将收录性能、安全、可用性与合规等质量属性要求。

2 - 投资代销

栏目建设中，用于存放投资代销业务的架构与设计文档。

3 - 金融市场

金融市场板块的架构与设计文档：

• 新一代资金交易管理系统架构总览：业务、应用、技术、部署、集成、数据六大架构全景与交互式架构图集
• 新一代资金交易管理系统数据移植方案：Opics 与同业系统存量数据的模板迁移范围、流程与核对机制
• 配合系统建设架构方案：配合系统改造范围、接口与数据集成、系统集成原则与标准
• 新资金交易管理系统适配改造方案：按 2026 年 9 月 9 日架构会评审意见，以"两类适配"主线整合数据移植与配合系统方案的统一框架

3.1 - 新一代资金交易管理系统架构总览

新一代资金交易管理系统是全行金融市场板块的核心业务平台，用于替代存量资金交易系统（OPICS 2.1）、非标资产同业业务管理系统和银行间增值服务系统（ComStar）三套系统，实现全品类本外币资金业务的前中后台一体化管理，并完成全栈信创适配。

建设背景与目标

存量系统的核心痛点：OPICS 软件许可将于 2027 年 5 月到期且供应商已无维护版本，运行环境（Windows 7 / Oracle 11g）老化、生产单机运行；风险管理的限额、授信、计量、压力测试能力不足；监管数据字段覆盖与全生命周期治理机制欠缺。

项目按四大目标推进：

建设节奏：第一批次（2027 年 5 月投产）完成分布式平台搭建与存量资金交易系统、银行间增值服务系统未到期业务迁移，下线两大存量系统；第二批次（2027 年 11 月投产）完成非标资产同业业务管理系统未到期业务迁移。

业务架构

全屏打开 ↗

业务架构覆盖市场数据接入、交易业务处理、风险管控、报表查询、事后核算全业务链路，分为前中台与后台两大部分。

资金系统前中台（四大基础数据板块 + 三大业务模块）：

• 基础数据板块：统一汇集行情数据（外汇、债券、货币、衍生品四大市场）、市场数据（债券基本资料、合约资料、估值、交易对手）、指标数据（本外币收益率曲线、基准指标、指数）与其他数据（市场日历、市场参与者），作为全系统业务运算的底层数据源。
• 资金交易管理：金融市场业务与同业业务全流程交易管理，含新一代审批流、报价管理、交易信息查询维护、投资组合维护，实现报价、录入、审批到投组管理全线上管控。
• 风险管理：市场风险对接 RISK 检核项，信用风险对接 RMS 统一授信平台，操作风险依托新一代审批流配置管控，流动性风险支持库存管理与当日库存明细监控。
• 报表查询：损益分析、交易日仓位查询、现金流管理、敞口与损益分析、结存交易管理，满足交易台账与头寸监控需求。

新一代资金交易系统后台（事后作业三大功能模块）：

• 业务审核：应收应付审核、实际收付确认，配套交易日审批与实收付审批流程，把控资金收付业务准入。
• 资产作业：资产计提、摊销、年终结转三大核心会计作业。
• 后台核算及日常管理：盘前准备、日间实时出账、日终核算、手工调账、分录与科目余额查询，以及资产查询、交割汇总、Swift 报文管理、结构性产品全生命周期管理。

关键业务方案：

1. 对公及同业客户：新客户统一由前中台创建，授信客户在审批发起试算保存时创建、非授信客户在交易完成后判断创建；按金融市场专题数据质量规范梳理必填字段，创建失败前置拦截提示补录，解决原 OPICS 客户必填校验缺失、数据质量差的问题。
2. 账务核算：遵循新核心核算引擎接入规范，日间账务经 MQ 实时发送、日终账务与余额经 FTP 传输；标准现券、资产、基金由本系统结合中债登、估值定价导入与 Choice 计量核算，衍生品与非标由风险系统估值计量出账。
3. 资金清算：交易审批、清算复核、影像附件全流程线上贯通，成交后自动生成汇款流程与清算报文；支持清算审批回退、异常清算退回重提；本币柜面核对与外币 Swift 前置核对统一收敛至后台系统，前后台岗位分离、全流程留痕。
4. 额度管控：交易审批时可发起额度试算，占额公式运算后经接口实时查询信管系统额度明细；审批单录入后按约定报文完成实时占额与释放，未来配合智慧信贷按产品大类、业务细类、产品编码多维上送。
5. 头寸管理：头寸勾兑改由本系统向头寸系统推送交易数据完成；头寸预报遵循新核心二批次模式，经人民币汇款系统统一推送头寸管理系统。

新承接功能：上清所二代债券直联（后台直接进行结算指令确认与状态查询）、本外币影像平台对接（前台逐笔上传成交确认单等附件，后台按影像 ID 调阅复核）。

应用架构

全屏打开 ↗

应用架构采用前中台云托管 + 后台本地化部署的混合模式：前中台借助云托管获得弹性与可扩展性、降低基础设施投资；后台核心组件与数据存储部署于行内数据中心，满足敏感数据管控要求。

CBS 后台应用自外向内分层：

1. 外部接口层：中债、上清、交易后接口与经 CIIS 获取的前台交易和市场数据。
2. 网关层：Nginx 反向代理作为统一入口，负责负载均衡、路由转发与安全控制。
3. 引擎层（cbs-server）：六大引擎支撑后台业务流程配置——工作流引擎（日间经办复核流程）、清算引擎（本方及对手方清算信息）、核算引擎（会计事件与分录科目整合）、现金流引擎（当期及未来计息现金流分析统计）、报文引擎（外汇交易与 Swift 报文转换）、批次框架（计提、摊销、估值的时间频次配置）。
4. 业务处理层：综合管理、交易管理、清算管理、账务管理与定制化接口（CAP）。
5. 技术组件层：ZooKeeper（集群管理与选主）、Redis（分布式缓存与锁）、RocketMQ（消息队列）、Dubbo（分布式服务框架）。

**定制化接口（CAP）**承载行内个性化需求，功能涵盖账务处理、人民币支付、外币 Swift 报文、授信管理、头寸管理、代客即期上行、拆借交易上行、客户管理、影像处理、南北向通处理等模块。它与 CBS 产品部署在同一服务器、增加独立服务进程，嵌入 CBS 使用其中间件与分布式框架，共用同一数据库并以 schema 区分数据归属；对行内三方系统主要经 ESB 交互，账务经 FTP 和 MQ 与核心核算引擎交互，影像文件经 jar 包调用对接影像系统。

日终批量调度：检查收盘 → 请求日终汇率与贵金属价格 → 计提 / 摊销 / 估值请求与计算 → 日终核算 → 切日；支持对接 Control-M 作业调度平台，通过「CBS 批量日终状态表」判定当日批量成功。

技术架构

全屏打开 ↗

系统由原单中心单体架构升级为分布式多活微服务架构，按业务领域完成服务解耦，各业务单元支持独立部署迭代与弹性扩缩。

七个微服务：

高可用设计：

• 无状态服务（cbs-server、cbs-ciis、cbs-external、cap-server、view-server）多实例部署、全部注册 Dubbo，负载均衡随机 / 轮询调用，实例宕机自动摘除、流量无感切换。
• 有状态服务（cbs-worker、cap-worker）：定时与批量任务绝不允许重复执行（否则清算核算重复记账），多实例通过 ZooKeeper 临时节点选主，同一时刻仅 Leader 执行任务、其余热备监听。
• ZooKeeper：三节点选主，心跳超时自动重选（过半投票 + ZXID 优先），单节点故障不影响集群、双节点故障主动停服保一致；与业务选主是两层机制——ZK 集群先保协调服务可用，worker 再抢业务 Leader。
• Redis：1 主 2 从异步复制 + 3 哨兵过半决策，主观下线 → 客观下线（quorum≥2）→ 提升数据最全从库为新主，秒级完成、客户端自动重连。
• RocketMQ：NameServer 仅做路由注册发现、节点互不通信无 Leader，Broker 定时上报路由，客户端连任意存活节点即可。

质量管控：全部定制化开发纳入 DevOps 流水线闭环，适配全行质量门禁自动化管控体系，围绕代码安全、流程合规、分支完整性、代码质量四大维度落地 9 项强制检查点。

部署架构

全屏打开 ↗

网络区划与服务器资源：

• DMZ 区：至少 2 台用于服务路由与负载均衡。
• 应用服务区：CBSFCS01、CBSFCS02 两台应用服务器，每台部署 7 个微服务，多活部署，支持容器云部署或横向扩展服务器。
• 中间件区：CBSFCS03、CBSFCS04、CBSEMS05 三台中间件服务器组成中间件集群。
• 数据区：数据库部署方案按行内标准要求执行。
• 专线接入：前中台 CIIS 云托管经专线接入行内；中债登、上清所等外部机构经专线直连。

运行保障体系：7×24 不间断服务，构建「监控、告警、巡检」三位一体的运行保障体系，全面适配行内统一监控告警平台——基础设施与微服务进程探活、中间件连通性监控、统一日志链路追踪；分级告警推送短信邮件渠道；自动化巡检脚本核查端口 / 进程 / 配置一致性，日终批量专项巡检按「CBS 批量日终状态表」判定是否按预期抵达切日且状态 SUCCESS，并生成周期性健康报告支撑运维复盘与容量规划。

集成架构

全屏打开 ↗

集成架构覆盖外部直连、行内联机、数据下游三个层面。对原资金交易系统和非标系统的功能不做平移，全部按新一代模式重建。

外部市场机构：新增中债直连、上清所二代债券直连接口，实现与中央结算公司、上海清算所综合业务系统的直通式实时交互——业务人员在 CBS 后台即可完成各类业务指令确认、及时获取结算状态，将原需在上清所系统手工确认的操作自动化。

行内联机接口（经新一代 ESB 与专线）：

• 原 OPICS / 非标 / ComStar 发布的 6 个接口中，4 个平迁由新一代资金系统发布（TFC 贸金系统检查同业客户、代付交易信息接收、代付归还修改通知、CIP 报文接收 cips135/136/601）。
• 原调用的行内系统接口共 32 个由新系统承接，主要包括：信管系统额度查询（200051）与占用释放冻结（200052）；新一代人民币汇款系统跨行转账与支付交易信息查询；外币汇款系统 MT300/305/320/360/540/542/543、PACS009 等报文签发与查询；新一代核心系统对公客户信息维护、SPV 客户建立、客户关系维护、客户信息查询；微信银行消息提醒；CIP 出报（cips136）等。

数据类集成：

• 下游系统取数报表共 277 张，经确认停用 44 张、在用 233 张，其中涉及改造 185 张——下游需修改取数数据源与取数逻辑并保持原有功能，覆盖 EAST 5.0（6 张）、一表通（27 张）、统一上报平台（67 张）、人行金数与广义信贷（17 张）、预期信用损失计量（17 张）、资金转移定价（11 张）、市场风险管理（9 张）、新审计厅（4 张）、全面税务（4 张）等 19 个报送系统。
• 企业知识平台承接 CBS 标准视图进入 STG 贴源层，GDM 通用模型直接从贴源层取数，规划新增资金域 19 张表，覆盖 AG 协议域（4 张）、EV 事件域（2 张）、AS 资产域（3 张）、FD 财务域（4 张）、PT 当事人域（2 张）、BH 机构域（1 张）、PD 产品域（2 张）、CM 公共参数域（1 张）八大主题域。
• 指标管理平台围绕自营投资、货币交易、外汇及衍生交易等业务板块完成 1200 余项指标梳理重构，统一数据口径并沉淀指标数据资产。
• 历史数据：原 OPICS 与非标系统已到期存量历史数据全部保存于企业知识平台 STG 贴源层，按行内数据提取流程审批后查询；原 ComStar 本外币存量业务迁移范围依据 CBS V2.4 版本评估后确定。

数据架构

全屏打开 ↗

数据模型按职能严格分隔为八类，各子功能只维护自身数据分类、经接口与 MQ 跨系统流转：

其中 ①② 构成共享底座，③ 为业务驱动核心，④—⑧ 为由交易事件驱动生成的后台衍生数据。

核心数据流转：外部数据源 → 前台市场数据模块写入主库 → 实时同步后台，供交易引用、风控参考与计量估值；交易员录入交易后同步调用中台风控，通过后状态确认并经 MQ 异步推送后台，驱动清算、账务、资产、计量后续流程。关键约束：成交推送保证消息不丢失（MQ 持久化 + 消费确认 + 幂等去重）；额度校验同步调用保证确认时已实际占用；资产明细表 Append-Only、余额 = 前日余额 + 当日明细变动；分录按「交易类型 + 方向」匹配会计模板生成，已过账凭证不可修改、错账红字冲销；日终完成总账发生额与资产余额、明细分录核对，异常挂账告警。

标准视图与命名规范：ComStar 提供约 400 张标准视图，设计理念为原表一致性、口径多样性、逻辑深加工（封装跨四五张表的关联与状态判断）、数据全面性与可持续升级，避免行内取数系统理解底层表结构。数据表以 FMS_ 前缀命名（如 FMS_DEAL_BASE_MASTER 成交表），历史表以 _H 后缀标识；字段命名由表名单词首字母构成三字符前缀、后缀标识业务数据类型（_DATE、_AMNT、_RATE、_CRNCY_CODE 等）。

数据迁移概要

存量迁移覆盖原 ComStar 后台（TBS / FBS）、OPICS 与同业系统三大来源：TBS / FBS 科目和资产由脚本迁移（债券借贷、利率互换、标债远期、标准利率互换、信用联结票据）；OPICS 与同业系统在新系统上线后，前台交易经【ComStar 交易导入】模板初始化，后台经【资产余额导入表】【科目余额导入表】在 CBS 客户端导入；新核心对存量科目余额直接入账建立期初余额，当日批量按约定格式将全量科目余额发送新核心，T 日迁移完成后经科目余额表逐级核对，确保存量数据准确、完整、无差异迁入，不影响日终批量与账务连续性。

3.2 - 新一代资金交易管理系统数据移植方案

本方案依据《CBS 和 OPICS 迁移方案 v1.0》与新一代资金交易管理系统架构总览编制，明确存量系统向新一代资金交易管理系统（下称"新系统"）的数据移植范围、模板体系、实施流程与核对机制。

一、背景与总体原则

原金融市场业务由三套系统承载、三家供应商建设：

新系统将三套系统合并为一，供应商为原 ComStar 供应商，可理解为原 ComStar 的升级产品。因此：

1. ComStar 存量数据随系统升级完成迁移：由供应商专门的迁移工具（标准化自动化脚本）执行 TBS / FBS 的科目、资产、存量交易迁移，不占用本方案主线。
2. 本方案聚焦 Opics 与同业系统的数据移植，覆盖交易数据、资产数据、科目余额数据三类。
3. 大原则：不涉及数据库层面的导出与导入。由新系统提供标准化 Excel 数据模板，源系统（Opics、同业系统）按模板整理并提供数据，经新系统前中台与后台客户端的导入功能初始化入库，导入前完成字段级校验，失败自动拦截并输出错误清单。

二、迁移范围

同步衔接：存量科目余额时点数据同步至新核心系统建立期初余额，T 日日终全量科目余额按约定接口格式推送新核心，保障日终批量与账务连续。

三、模板体系

模板分前台交易导入、后台资产导入、后台科目导入三类共 29 个 Excel 模板。源系统按模板整理数据：模板内以颜色区分「必要输入栏位」「关联栏位（输入其一，可计算其他栏位）」「非必要输入栏位」，并内置填写规则说明（日期格式 yyyy-MM-dd、数值位数上限、枚举取值等）。

3.1 前台交易导入模板（17 个）

导入入口为新系统前中台【ComStar 前台交易导入】。基础数据模板先行（资产品种维护、自定义债券），再执行交易导入，最后导入持仓表。

基础数据类（3 个）：

交易类（11 个）：均含交易品种、投资组合、交易类型、成交编号、交易方向、对手方、交易日 / 交易时间等公共栏位。

外币专用（2 个，承接 Opics 外币业务）：表头风格独立（绿色为必输项），支持多币种清算路径字段。

持仓类（1 个）：

3.2 后台资产导入模板（11 个）

导入入口为 CBS 后台客户端【资产余额导入表】。按业务品种提供 Init 模板，公共栏位为部门 ID、系统交易编号（前台导入后自动生成）、余额日期、交易费用、利息成本 / 收益、备选值；余额方向规则内置（如拆入贷方为负、拆出为正；正回购为负、逆回购为正；同业存放为负、存放同业为正）。

3.3 后台科目导入模板（1 个）

四、实施流程与时序

全屏打开 ↗

T-1 日（数据准备）：Opics 与同业系统停办存量业务、数据冻结；导出 T-1 日余额文件；业务人员按第三章模板整理各品种交易、资产与科目余额数据，完成模板内自检（必填项、枚举值、金额精度、余额方向）。

T-N 日～T 日（迁移窗口），按依赖顺序执行（基础数据、交易与持仓导入在 T-N 日～T 日执行，后台资产、科目导入在 T 日执行）：

1. 基础数据导入（前中台）：1.1 资产维护、2.1 / 2.2 自定义债券模板——先建资产与债券档案，交易导入的资产代码 / 债券代码校验依赖于此。
2. 前台交易导入（前中台【ComStar 前台交易导入】）：按品种执行 3-12 号模板及即期、拆借模板，导入后系统生成系统交易编号。
3. 持仓表导入：1.3 持仓表模板初始化非标底层持仓。
4. 后台资产余额导入（CBS 后台客户端【资产余额导入表】）：按品种 Init / Tn 模板导入资产存量余额，系统交易编号与前台联动。
5. 后台科目余额导入（【科目余额导入表】）：上线时点科目余额初始化。
6. ComStar 数据迁移（并行）：供应商脚本自动完成 TBS / FBS 科目、资产、存量交易迁移；原 TBS / FBS 需冲账科目在 CBS 完成冲账、不向新核心发送冲账指令，大总账以 T-1 日科目余额文件红冲归零后重新入账。
7. 新核心入账：新核心对新一代资金交易存量科目余额直接入账，建立期初余额；日终批量将全量科目余额按约定接口格式推送新核心。
8. T 日核对：科目迁移完成后，按「源系统汇总余额 → 新一代资金后台资产余额 → 新一代资金后台科目余额 → 新核心科目余额」四段链核对。

T+1 日（验证收口）：核对资产余额、验证资产与科目余额一致性；核对外部登记托管机构（中债登 / 上清所）债券余额与系统内持仓。

五、校验与核对机制

导入校验（事前）：模板导入前完成字段级校验——必填栏位、枚举取值、日期格式与先后关系（结算日晚于交易日等）、数值精度上限、互推栏位（净价 / 全价 / 收益率 / 结算金额四选一）、余额方向（借 / 贷符号规则）；导入失败自动拦截并输出错误清单，修复后重导。

一致性核对（事后），四段核对链逐级比对：

1. 科目余额：借贷平衡、汇总一致、逐科目匹配；
2. 资产数据：数量、面值、市值、利息、摊销、估值及损益相关数据一致；
3. 交易笔数：迁移笔数与源系统有效存量笔数一致；
4. 差异处理：零容忍，差异不解决不进入日终批量。

六、风险控制与保障

七、与架构总览的衔接

• 前中台模板导入功能对应业务架构中的前台交易管理与基础数据板块；
• CBS 后台客户端资产 / 科目导入对应后台核算及日常管理模块；
• 新核心期初入账与日终全量推送对应应用架构中 CAP 定制化接口经 MQ / FTP 与核心核算引擎的对接；
• 迁移完成后的标准视图与 GDM 供数承接数据架构中的下游报送体系，保障监管报送口径统一。

3.3 - 配合系统建设架构方案

本文档总结自《新一代资金交易管理系统项目配合系统建设架构方案》（提出部门：金融市场部；所属部室：中台产品开发室；项目经理：郭园 / 邱帅；需求经理：邱帅；架构方案负责人：李彬；需求输出时间：2026 年 6 月），并与架构总览及数据移植方案互相引用。

因新一代资金交易管理系统后续将替换资金交易系统（Opics）、非标资产同业业务管理系统与 ComStar 系统，为保证现有存量业务及下游上报功能的业务连续性、适配行内新核心核算模式、提升本外币衍生品估值风险管控并优化业务流程，需对各配合系统实施改造。

一、建设目标与范围

配合系统建设按五条主线展开：

项目建设定性：属于新建系统（A）、存量系统架构升级（C）、信创改造（D，替代 + 架构升级 + 业务价值提升）、合规 / 监管类改造（E）与系统整合 / 迁移（F）的复合型项目。架构方案围绕该定性展开，避免平替类过度设计，也避免提升类仅按替代适配评审。

二、现状与痛点

1. 业务操作断点多：金融市场业务清算、记账、对账等环节存在人工串预多、系统断点多、风险隐患多的痛点，经梳理共有 35 个业务品种涉及线下操作。金融市场部需操作 Opics、ComStar、智慧办公系统；运营管理部需操作客户服务系统、贸金系统（SWIFT 前置）。
2. 账务对接模式落后：原资金交易系统通过财务文件传输的账务对接模式，未实现与新核心核算引擎统一对接，总账系统只有科目级会计凭证流水，无法满足日益细致的财务数据需求与监管报送要求。

三、系统间交互关系

全屏打开 ↗

3.1 联机类接口

平迁发布 4 个接口（原发布方 → 新发布方均为新一代资金系统）：

另有 2 个原发布接口（FBS 头寸上行文件通知 400300、非标系统客服广播通知 220000）不再迁移。

承接调用 32 个接口，按系统分组：

• 信贷管理系统（LOS）：200051 查询客户额度信息、200052 客户额度占用释放冻结解冻交易（额度试算与实时占额）。
• 新一代人民币汇款系统：跨行转账（3004010001）普通汇兑；支付交易信息查询（3004030001）流水 / 明细 / 来报待处理 / 汇兑明细；支付交易状态查询（3004030005）系统状态与同步查询；参与者查询（3004030003）。
• 外币汇款系统：外币支付报文管理（3004020008）PACS009 预览签发（记账）、MT300 / MT305 / MT320 / MT360 / MT540 / MT542 / MT543 / MT210 预览签发、CIPS136 报文签发；支付交易信息查询（3004030001）入报列表 / 明细 / 最终状态 / 已处理通知。
• 新一代分布式核心业务系统：客户信息查询（2001030001）对公详细信息与多笔基本信息；客户信息管理（2001020001）对公客户信息维护、SPV 客户信息建立；客户关系管理（2001020003）客户关系维护。
• 其他：微信银行（MMB）301101 普通消息提醒；CIP 出报（cips136，212722）。

3.2 关键业务方案（涉及配合系统部分）

1. 对公及同业客户：新客户由新系统前中台统一创建——授信客户在审批发起试算保存时创建，非授信客户在交易完成后判断创建；创建失败的必填校验由接口前置拦截，交易员补录后手工发送创建报文至新核心。依赖新核心客户信息查询 / 管理 / 客户关系共 5 个接口。
2. 账务核算：对接新核心核算引擎——日间分录明细经 MQ 定时抓取发送，日终账务与余额生成文件经 FTP 传输；标准现券 / 资产 / 基金由新系统结合中债登、估值定价导入与 Choice 计量核算，衍生品与非标由风险系统估值计量出账。
3. 额度管控：ComStar-RMS 占额公式运算后经接口实时查询信管系统额度明细，审批单录入后按 200052 报文完成实时占用与释放。
4. 资金清算：交易审批、清算复核、影像附件全流程线上贯通；本币柜面核对与外币 Swift 前置核对统一收敛至新系统后台；支持清算审批回退与人工导出审批流。涉及人民币 / 外币汇款系统全部报文接口。
5. 头寸管理：头寸勾兑由原"头寸系统直连 Opics / ComStar 数据库定时查询"改为新系统经接口向头寸系统推送交易数据；头寸预报遵循新核心二批次模式，经人民币汇款系统大额接口（fpms03）统一推送。

3.3 数据类集成

• 通用数据模型：企业知识平台 STG 贴源层承接 CBS 标准视图，GDM 通用模型层直接取数，资金域计划新增 19 张表——AG 协议域 4 张（本币 / 外币交易协议、同存合约、IRS 合约）、EV 事件域 2 张（解约冲销、交易后确认）、AS 资产域 3 张（持仓余额、资产变动、估值计量）、FD 财务域 4 张（现金流、清算路径、账务分录、还本付息）、PT 当事人域 2 张（交易对手、投组账户）、BH 机构域 1 张、PD 产品域 2 张、CM 公共参数域 1 张。
• 下游报送改造：EAST 5.0（6 张）、一表通（27 张）、统一上报平台（66 张）、人行金数与广义信贷（17 张）、预期信用损失计量（17 张）、资金转移定价（11 张）、市场风险管理（9 张）、新审计厅（4 张）、全面税务（4 张）、集中申报（1 张）、审计署（1 张）、操作风险与内控合规（1 张）、RWA（1 张）、资产负债管理（3 张）、表单一体化（2 张）、管理会计（2 张）、新一代审计（3 张）等，合计改造 181 张。
• 增量抽数：数据量级超 100 万条的表按增量抽数规范执行增量抽取与供数，降低整体 ETL 时长与资源消耗；敏感数据按数据安全规范脱敏。

四、系统间交互原则与标准（补充）

原方案散见各节的集成约定在此汇总为体系化原则，作为配合系统改造与联调验收的统一标准。

4.1 接口接入原则

1. 统一接入通道：行内联机接口统一经新一代 ESB 网关模式接入，不新建点对点直连；账务类高吞吐数据按约定走 MQ / FTP 专用通道（新核心核算引擎日间 MQ、日终 FTP）。
2. 平迁保功能：接口平迁（发布 4 个、承接调用 32 个）严格保持原接口号、报文格式与服务语义不变，调用方仅做联调切换，不做功能改造——避免范围漂移。
3. 接口唯一标识：接口号全局唯一且沿用行内编号体系（如 200051、3004010001、194008）；新增接口须经架构评审并在接口清单登记后方可投产。
4. 发布与调用对称确认：每个平迁接口由发布方、调用方双向确认测试报告，未确认的接口不纳入投产窗口。

4.2 报文与数据标准

1. 标准报文格式：账务明细下传新核心严格按双方约定的标准报文格式，保障完整性、时效性与规范性。
2. 数据源统一切换：下游取数一律切换至企业知识平台标准视图（620 张原视图 → 438 张标准视图），禁止下游直连资金业务库；取数逻辑改造保持报表原有功能与口径。
3. 增量抽数规范：超过 100 万条的表采用增量抽取供数；抽数作业纳入数据中台统一调度与监控。
4. 敏感数据管控：基于数据安全规范对涉密敏感数据脱敏后供数，屏蔽下游用数风险。

4.3 时序与切换原则

1. 接口切换与迁移对齐：配合系统接口联调完成时点必须早于数据迁移 T 日；T 日切换后原系统接口同步停用，避免双跑期数据口径不一致。
2. 两批次投产节奏：跟随主系统第一批次（2027 年 5 月，资金交易 + ComStar 替换）与第二批次（2027 年 11 月，非标替换）分批联调、分批切换；非标相关下游（理财、特定目的载体投资类报表）在第二批次改造。
3. 回退对等：每次切换保留原接口回退开关，主系统回切时配合系统同步回退。

4.4 安全与合规标准

1. 传输安全：与外部机构（中债登、上清所、CFETS 等）经专线交互；跨网络数据交换按行内规范使用 TLS 等加密协议。
2. 身份认证：新资金交易系统前中台与后台均使用新系统自有（ComStar）账号体系，不纳入行内统一身份认证平台。
3. 规范遵循（引用行内现行规范）：《新建业务系统 IT 基础架构评审实施细则》《金融互联网 IPv6 网络规划 v1.3》《应用系统字符集规范 V1.0》《新核心设计标准》《RD0501- ESB 工作规范细则 V1.1》《影像及内容管理平台接入规范 V1.0》《自主研发开发管理平台接入指引》。

五、应用与技术架构要点（配合视角）

配合系统不涉及新增物理资源；主系统侧架构（六层：外部市场接口层 → 网关 → 核心业务五板块 → 业务组件 → 技术组件 → 基础软件；后台 7 微服务 + ZooKeeper / Redis / RocketMQ / Dubbo 中间件集群及高可用设计）详见架构总览。

外部市场接口连接 CFETS（本币行情 Cfets-cti、总接口）、上交所（Sse-cti）、交易后平台、二代清算接口与基础资料接口（getbond）；网关层（Nginx 反向代理）提供负载均衡、路由转发、鉴权限流。

六、信创与合规要求

• 服务端信创基线（必须信创项）：芯片（海光 / 鲲鹏）、虚拟化、麒麟 V10、宝兰德中间件、OceanBase 数据库、信创浏览器。
• 客户端适配：麒麟 Kylin V10 SP1、WPS Office、奇安信 / 360 安全浏览器；柜内清、柜外清、高拍仪、验印灯、指纹仪、扫描仪、票据打印机、社保卡读写设备、COM 转接头等外设驱动更换为信创版本；移动展业 PAD 与背夹适配。
• 其他合规：ESB 采用新一代网关模式接入；IPv6、密评与商用密码改造、批量调度平台（UDP）接入经排查本项目不涉及；数据安全遵循《银行保险机构数据安全管理办法》《中国人民银行业务领域数据安全管理办法》；AI 嵌入评估本期不涉及。

七、架构资产沉淀

本项目的可复用资产：资金 GDM 通用模型 19 张表（其他用数系统可直接引用）、CBS 标准视图 438 张及视图文档、全栈信创适配清单（芯片 / OS / 中间件 / 数据库 / 终端 / 外设）与兼容性验证结果、数据迁移模板与投产切换脚本、接口平迁的双向确认流程基线。

3.4 - 新资金交易管理系统适配改造方案

本方案依据 2026 年 9 月 9 日架构会对《新一代资金交易管理系统项目配合系统建设架构方案》与《新一代资金交易管理系统数据移植方案》的评审意见编制，将两份方案按统一框架整合梳理，作为后续正式评审的报审版本。模板字段明细、接口清单等展开内容仍见数据移植方案与配合系统建设架构方案，本方案聚焦适配主线、改造边界与差异分析。

一、适配改造总体框架（两类适配核心主线）

配套系统建设统一遵循"两类适配"核心主线，按适配方向一分为二——行内既有体系不动、由新系统去适配；新系统落定后、由外部系统来适配：

两类适配核心主线（配套系统建设统一遵循的架构标准）
├── 行内标准适配（新系统适配行内现有体系）
│   ├── 功能类适配：适配核心业务系统标准、支付清算体系标准
│   └── 工具类适配：复用行内现有标准工具服务、单独列明新增定制化改造需求
└── 外部系统适配（外部系统适配新系统要求）
    ├── 接口适配：调整原有接口逻辑适配新系统
    └── 数据适配：对齐新旧系统数据差异完成调整

测试与开发团队按此掌握改造边界，避免架构逻辑混乱导致后续工作走偏。

跨界示例：头寸管理勾兑功能——头寸系统由直连取数改为接口推送，属外部系统适配·接口适配范畴（3.1），改造内容作为新增定制化需求在 2.3 单独列明。

二、行内标准适配（新系统适配行内现有体系）

2.1 功能类适配（适配核心业务系统标准、支付清算体系标准）

分类估值核算规则（适配行内核算体系）：标准现券、资产、基金类业务由新系统结合中债登、估值定价导入与 Choice 进行估值计量和账务核算；衍生品与非标准化业务由风险系统估值计量出账。

2.2 工具类适配（复用行内现有标准工具服务）

2.3 新增定制化改造需求（单独列明，不与标准服务混淆）

以下内容为承接新系统业务而新增的定制化改造，行内无既有标准服务可直接适配，单独列明管理：

1. 头寸勾兑推送模式改造：头寸系统原直连 Opics / ComStar 数据库定时查询取数，改为由新系统经定制化接口（cap-server 承载）向头寸系统推送交易数据完成勾兑；原 FBS 头寸上行文件通知接口（400300）随之停用。
2. 清算流程一体化：交易审批、清算复核、影像附件全流程线上贯通——交易达成自动生成汇款流程并组装清算报文，清算完成自动生成账务；从 OA 线下流转转为系统内闭环，覆盖原 35 个线下操作品种的主体部分。
3. 交易凭证与审批留痕：交易界面增设清算信息对话框（对手方账号、行号、汇款账号等）+ 附件功能，清算全流程要素与资料集中留存可追溯；支持清算审批回退（回退至前中台维护后再推送）与人工导出审批流。
4. 业务统计报表自动化：业务数据自动生成报表，支持后台查询下载，新增 6 张报表，替代手工填报。
5. 后台定制化接口服务体系：cap-server（头寸、影像、支付、核心账务等定制化接口的主业务编排）、cap-worker（定制化定时任务调度与重试）、view-server（基于 MQ 的 CBS 主服务与接口服务间异步桥接）——非标准化产品部分，为行内个性化需求的承载层。

三、外部系统适配（外部系统适配新系统要求）

全屏打开 ↗

3.1 接口适配（调整原有接口逻辑适配新系统）

接口接入统一遵循：ESB 网关模式统一接入、平迁保功能（接口号 / 报文 / 语义三不变）、接口号全局唯一并沿用行内编号体系、发布方与调用方双向确认测试报告后纳入投产窗口。

3.2 数据适配（对齐新旧系统数据差异完成调整）

新旧体系数据流对比如下图——上半区为旧体系：三系统 620 张分散取数视图贴源落地，下游在企业知识平台 STG 贴源层直取（虚线）；下半区为新体系：CBS 标准视图 438 张贴源后经 GDM 通用模型统一加工，下游取数点从 STG 上移至 GDM（实线）。STG 贴源层为两条路径共用的枢纽，适配的核心动作即供数视图标准化（620 → 438）与下游取数点上移：

全屏打开 ↗

对比要点：

• 旧体系 · STG 直取：三系统各自建库、分散供数，620 张取数视图口径不一；下游在 STG 贴源层直取，报表 273 张、指标 1254 个绑定老口径；总账仅科目级流水，财务数据颗粒度不足。
• 新体系 · GDM 统一供数：新资金交易管理系统统一出口（三系统合一），CBS 标准视图 438 张；STG 承接标准视图，GDM 资金域 19 张表统一加工、字典统一；下游一律从 GDM 取数，禁止直连资金业务库。
• 适配过程 · 平滑切换：报表 181 张改造取数源与取数逻辑，保持原有功能与口径；指标 1254 个约 50% 由通用模型屏蔽改造影响、50% 二次开发；超 100 万条的表增量抽数，敏感数据按数据安全规范脱敏。

四、数据移植方案（全流程逻辑）

全屏打开 ↗

4.1 迁出侧：范围与存量分级

三系统迁出范围与存量分级（按评审意见调整）：

迁出前置动作：T-1 日 Opics 与同业系统停办存量业务、数据冻结，导出 T-1 日余额文件，业务人员按模板完成自检。

4.2 迁入侧：模板导入链路

大原则不变：不涉及数据库层面的导出与导入，由新系统提供标准化 Excel 模板（前台交易 17、后台资产 11、后台科目 1，共 29 个），源系统按模板整理供数，经前中台【ComStar 前台交易导入】与后台客户端导入初始化，导入前字段级校验、失败自动拦截输出错误清单。字段明细见数据移植方案第三章。

4.3 迁出迁入差异分析（对上下游系统的影响）

字段映射规则（覆盖全业务表，便于下游报表适配性改造）：

实施步骤：数据摸底（三系统存量表 / 字段清单与差异梳理）→ 映射梳理（输出映射对照表）→ 规则开发（转换脚本 + 数据中台通用模型开发）→ 测试迁移（测试环境全量迁移、比对、整改）→ 正式迁移（分批次全量 + 增量同步）→ 数据校验 → 双轨比对（新旧系统并行比对）。

对上下游的影响面：新核心（期初余额建立、日终全量推送）、大总账（红冲归零后重新入账）、监管报表与指标（181 张报表、1254 个指标口径切换）、下游取数系统（视图 620 → 438、改从 GDM 取数）。

4.4 历史数据归档与查询（已结清存量）

按评审要求，已结清的存量交易数据不迁入新系统，按以下规则归档管理：

1. 归档规则：以 T-1 日为切点，状态为已结清（含已交割、已到期兑付、已提前解约）的交易保留在源系统侧归档库 / 归档文件，冻结只读；归档范围与迁入范围互斥且并集等于源系统全量，确保无遗漏、无重复。
2. 可查询、可恢复：归档数据保留完整交易要素与科目关联信息，支持按品种、对手方、日期等维度检索；恢复用于审计取证、监管问询、历史纠纷核验等场景。
3. 历史交易查询平台对接：归档数据接入行内历史交易查询平台统一对外提供查询服务，避免用户直接访问归档库；查询口径与新系统存续交易查询界面保持体验一致。

归档细则（归档库技术形态、留存期限、平台对接接口）为评审待办，由韩朝丽、李彬牵头按本章框架细化后补充。

4.5 校验与核对

• 导入校验（事前）：必填栏位、枚举取值、日期格式与先后关系、数值精度、互推栏位（净价 / 全价 / 收益率 / 结算金额四选一）、余额方向；失败自动拦截输出错误清单。
• 四段核对链（事后）：源系统汇总余额 → 新一代资金后台资产余额 → 新一代资金后台科目余额 → 新核心科目余额，逐级比对；差异零容忍，不解决不进入日终批量。
• 多维交叉验证：新老系统检核（总量 + 逐笔明细，输出差异清单逐条整改）、数据中台检核（GDM 模型层总量 / 口径 / 模型适配校验）、下游报表验证（新系统数据生成报表与旧系统历史报表对标）。

4.6 实施时序

T-1 日：停办存量业务、数据冻结、余额文件导出、模板自检 → T-N 日～T 日：基础数据导入、前台交易导入（生成系统交易编号）、持仓表导入 → T 日：后台资产余额导入、后台科目余额导入、ComStar 并行迁移与红冲、新核心期初入账、四段链核对 → T+1～T+7 日：资产余额核对、资产与科目一致性验证、外部登记托管机构（中债登 / 上清所）余额核对、双轨比对收口。

五、迁移伴随的业务优化提升点

针对现有业务痛点，本次适配改造同步落地的实际提升（数据要素与核算规则两个维度为主）：

4 - 资产托管

资产托管板块的架构与设计文档：

• 资产托管运营驾驶舱业务架构说明书：依据《资产托管运营驾驶舱需求说明书 V1.6-7》编制，含总体业务架构、指标数据流、异常处置流程与状态生命周期四张交互式架构图

4.1 - 资产托管运营驾驶舱业务架构说明书

资产托管运营驾驶舱是资产托管部的运营监控与质控平台，将项目管理、指令支付、估值核算、投资监督、信息披露及异常差错等分散信息集中呈现，形成"经营总览 → 过程监控 → 异常处置"的统一工作入口，服务管理人员、团队主管与清算、估值核算、综合管理三类业务岗位。

总体业务架构总览——五层自上而下：角色化访问的展示层（五类页面）、统一的业务服务层、公共管理能力构成的管控层、承载数据与留痕的数据层，以及七类外围系统的集成层：

高清 PNG 版本 · 交互式总体业务架构图

1. 文档说明

1.1 编写目的

本文档从业务视角对资产托管运营驾驶舱进行架构性描述，明确系统的业务定位、总体分层、指标体系、数据流转、异常处置闭环、页面功能与关键约束，作为后续需求细化、技术方案设计、研发实施与测试验收的业务侧依据。

1.2 适用范围

• 资产托管部、科技研发部门、测试与运维部门的需求澄清与方案评审；
• 同业能力建设、立项与工作量评估的参考；
• 不替代需求说明书本身，指标字段级、界面级细则以源需求文档与最新指标清单为准。

1.3 术语定义

1.4 依据与冲突裁决

本版需求以五份指标清单（大屏 20260901、团队主管/估值核算/综合管理 20260924、清算 20260904）确定指标范围与业务口径，以六份 HTML 原型确定页面结构与交互。冲突时：指标清单的明确删除或迁移备注优先，指标清单确定业务口径，最新原型确定页面布局与交互；原型演示数值不作为生产默认值或验收预期值。

2. 背景与建设目标

2.1 现状与问题

托管运营数据当前分散在项目管理、指令支付、估值、投资监督、智能文件处理等系统中：管理人员需要跨系统获取信息，一线岗位依赖人工关注关键时点和待办，指标口径、异常等级和处理留痕缺少统一承载，难以形成全局、实时、可追溯的运营管控视图。

2.2 建设目标

1. 建成运营监控大屏、团队主管监控工作台、清算运营质控工作台、估值核算运营质控工作台、综合管理工作台五类页面，分别提供管理总览、团队统计和岗位质控视图；
2. 纳入 194 项有效指标（105/17/28/38/6），覆盖当日任务、关键时点、首次交易、对账、数据准备、异常和定期报告事项；
3. 建立阈值管理、产品主数据同步和指标运行管理能力，统一指标口径、启停、忽略、重试、明细下钻和审计机制；
4. 建立异常发现 → 人工确认 → 复核审批 → 有效期管理闭环，避免同类已确认事项重复告警；
5. 通过角色化首页提升管理人员与一线人员的使用效率。

2.3 业务价值

3. 总体业务架构

全屏打开 ↗

整体采用"数据接入 → 指标计算 → 状态判定 → 页面展示 → 明细处置 → 审计追溯“的闭环设计，自上而下分为五层：

3.1 角色与访问矩阵

页面按当前用户组织与数据权限加载指标，无权限模块不展示，汇总值不得包含无权数据；数据权限按组织、岗位、产品或项目范围控制，服务端必须再次校验。

4. 指标体系与数据架构

4.1 指标分布

每项指标定义监控口径、展示要求、下钻字段、查询条件、执行频率五要素；同一指标必须使用统一口径、单位、精度、权威数据源和去重主键（BR02）。

4.2 指标运行与数据流

全屏打开 ↗

数据链路分五个阶段：

1. 数据接入：项管、指令支付、估值、投监、智能文件处理五类外围系统提供业务事实数据（图中按数据性质归并为两组；产品主数据源单列）；
2. 数据准备：产品主数据以权威源为准，经 F07 同步服务全量初始化、增量识别后按稳定业务键幂等写入；业务日历统一业务日、法定工作日、交易所工作日基准（BR01）；
3. 指标计算：调度引擎按业务日历与时间窗驱动——5 分钟轮询、定点执行、按估值频率检查；194 项指标按统一口径汇总；
4. 状态判定：仅生效阈值规则参与预警判断，规则启停与指标启停相互独立（BR08）；判定输出指标状态、数据时间与异常记录（分级：一般/重要/紧急）；
5. 展示与处置：状态使用最近一次成功数据，失败保留最近成功值并标记数据时间（BR06）；页面汇总值与同条件下钻明细强一致（BR05）；下钻、导出、干预全程审计留痕。

4.3 数据来源与集成要求

执行频率形态：大屏 300 秒自动刷新；待办类法定工作日 9:00–17:20 每 5 分钟轮询；时点类定点执行（8:00 / 14:30 / 15:00 / 16:00 / 16:30 / 16:40 / 17:00 / 17:10 / 17:30 / 20:00 等）；估值类按产品估值频率每 30 分钟检查；存单盘库类按月执行。

5. 异常处置与人工干预

5.1 处置流程

全屏打开 ↗

流程要点：

• 确认方式：单笔与批量确认面向明细记录；条件确认按指标业务字段设置起止日期，支持调整结束日期、提前失效与删除，变更保留审计记录；
• 系统校验：提交时校验指标可干预性、申请人权限、业务主键完整性与记录当前状态，校验不通过阻止提交；
• 审批生效：需复核的申请进入"异常_审批中”，通过后置为"干预通过"，驳回恢复"异常"；记录申请人、审批人、时间、意见与关联业务主键；
• 有效期抑制：有效期内已干预通过的业务主键，定时重算不重复生成异常；
• 边界规则：人工干预不修改原业务数据，只改变质控结果状态并保留依据（BR10）。

5.2 状态生命周期

全屏打开 ↗

失败韧性：执行失败保留最近成功值并标注数据时间（BR06）；支持自动重试与有权限的手工重试，重试按业务主键幂等；时点类异常按 5 分钟轮询直至异常消失。指标忽略须记录原因与起止时间，忽略期间对计算、页面展示和预警结果的影响待确认（Q11）。

6. 页面功能架构

6.1 功能清单

6.2 关键交互约定

• 分页：清算、估值核算、综合管理工作台默认每页 10 条；团队主管工作台默认 20 条并提供 10/20/50/100 选项；全部服务端分页；
• 一致性：页面汇总值、进度分子分母与同条件下钻明细必须一致（BR05）；团队主管区间值按业务事件汇总、包含起止日期，不得用存量快照相减（BR04）；
• 降级：模块级独立加载，单个模块接口失败保留最近成功值、数据时间和失败状态，不阻断整屏（BR07）；
• 状态表达：正常、预警、异常分别使用蓝、橙、红；无数据、加载中、失败、无权限和未到执行时间提供可区分提示；
• 边界：本期不建设拖拽布局、个人布局保存与快捷入口配置。

7. 业务规则

8. 非功能性要求

9. 风险与约束

9.1 关键依赖

1. 产品主数据权威源未定（Q10）——所有指标权限过滤与维度统一的地基，建议最优先关闭；
2. 外围接口就绪度未盘点（Q12）——需形成接口就绪清单、联调计划和降级展示方案；
3. 自动付费模块尚未上线（Q08）——“当日自动付费未完成预警"先做页面占位，模块上线并接口验收后启用；
4. 前一日估值与核心头寸核对接口能力待确认——确认后启用对应指标。

9.2 口径与文档质量提示

以下问题建议在开发前形成评审结论（详见需求说明书 8.2 待确认事项 Q01–Q13）：

• 大屏"运作中-当月/当年"“清算中-当月/当年"口径无日期条件，当月与当年值必然相等；
• “当日资金清算"模块中 7 项处理时长指标实际统计上一交易日数据，模块命名与统计期不一致；
• “18:00 当日未锁账预警"名称与实际执行时点 17:30 不一致；
• 团队主管 4 项项目类区间指标的事件类型、日期字段、去重主键三要素未落地（Q03）；
• 指令累计总量依赖权威历史数据起点（Q04）。

10. 附录：验收要点

5 - 风险防控

风险管理与防控体系相关的业务需求、架构与设计文档。

• 受害人精准拦截业务需求
• 受害人精准拦截技术实现方案

5.1 - 受害人精准拦截业务需求

依据《金融反诈一体化平台关于受害人精准拦截功能的需求分析文档》（V0.1，2026-07-07）提炼。平台接入受害人预警精准拦截功能：接收公安机关推送的潜在受害人账户与嫌疑人账户名单，对本行账户向嫌疑人账户转账时开展交易风险提醒与事中干预，并向平台反馈拦截信息，由公安机关引导受害人报案，全方位保护人民群众财产安全。

需求背景与业务目标

为全力压降电信网络诈骗犯罪、减少人民群众财产损失，根据国家反诈中心和中国人民银行相关工作要求，通过金融反诈一体化平台（以下简称"平台"）接入受害人预警精准拦截功能。总体业务分为两大环节：

1. 疑似涉诈账户名单接收及布控——平台将名单及布控规则传输至我行（账户等名单要素以 SM3 摘要提供，单向不可逆），按公安布控策略完成账号实时布控，并在 10 分钟内反馈布控结果；
2. 触发阻断规则后的交易管控与处置——本行付款账户向疑似涉诈账户转账时，对超过名单对应风控策略阈值金额的交易采取阻断措施并实时上报；同时对付款账户采取 48 小时（默认，随布控报文配置）保护性限额控制，管控期内失败交易逐笔上报，到期自动解除。

端到端业务流程

全流程分五个阶段：名单接收与布控 → 事中拦截与阻断上报 → 保护性限额管控 → 管控期上报与解控 → 网点人工解限。

全屏打开 ↗

参与系统与职责

功能需求详述

名单接收与布控

• 公安机关通过平台使用 105 报文下发疑似涉诈账户名单（对私、对公）及布控规则，账户等名单要素以 SM3 摘要提供——SM3 为单向不可逆算法，我行无法还原明文；有权机关查控管理平台完成验签与报文解析后以 106、304 报文应答。验签、解析流程异常时 106 反馈公安管控失败。
• 名单命中不依赖解密：事中交易监控系统对相应场景交易的收款账户等要素执行同样的 SM3 加密，与名单摘要比对，摘要一致即命中疑似涉诈名单，全程不还原明文。
• 名单带状态管理：生效（布控/修改布控）、失效（撤销布控）；数据用途类型 01 布控、02 修改、03 撤销、04 解除，其中 04 为事中控制措施解除请求，01/02/03 向事中推送。
• 有权调用事中名单推送接口，单次上送 50 条，事中返回 50 条结果，整批次处理完成后反馈公安并入库。
• 事中布控失败（超时、冲突等）须在 10 分钟内回报失败结果及原因；事中接口超时按现有反诈业务重连 3 次，仍失败则向公安反馈失败。106 反馈接口失败按 108 反馈规则重返 3 次、登记异常、支持人工重发。

事中拦截规则

• 疑似涉诈名单校验顺序位于司法冻结、涉案账户名单之后、其他校验规则之前，该规则不涉及白名单；仅监测收款账户是否命中名单。
• 名单比对采用摘要比对：交易侧对收款账户等要素做 SM3 加密后与名单摘要比对，命中判定不经过任何明文还原。
• 监测渠道范围：个人手机银行、个人网银、网联前置、银联、互联网支付平台、自助设备、智慧网点。布控规则严格按平台下发规则执行，非固化、可灵活调整。

阻断上报与事后处置

• 事中识别到触发阻断规则的交易后，立即将当笔阻断交易明细推送有权机关查控管理平台，由其按 103 报文上报公安平台；上报后 5 分钟内未收到 104 响应需重发，连续 3 次仍无响应则短信通知业务联系人电话联系平台处理；异常修复后提供操作页面支持手工上送。
• 阻断交易必须反馈：批次编号（原预警布控下发报文的原发起方批次号）、出账卡号 / 出账账号（明文及加密）、布控卡号、默认管控时间、风险标签；有权连同批次号登记入库，供后续上送与解除管控时取用。
• 事中将阻断明细生成核查单发送鹰眼系统事后处置，支持全量疑似涉诈阻断信息查询检索。
• 渠道接口差异：事中受害人阻断交易接口单条推送；网银渠道批量接口单次限 50 条，均需额外推送上述关键字段。

保护性限额管控

拦截触发后，有权机关查控管理平台对识别出的本行付款账户（受害人）执行保护性限额措施（币种人民币）：

1. 查询：调核心非柜面限额查询接口（1400061037），按出账卡号、币种、非柜面日累计限额码值查询现行额度；
2. 下调：调非柜面限额调整接口（1200061072）——从配置读取总限额（初始 3000 元），若现行限额大于 3000 则调整为 3000；小于等于 3000 额度不调但仍调用接口，备注上送风险标签。核心记录"公安受害人拦截"备注及操作员号，与其他限额调整场景区分；
3. 限制：调限制名单接口（12000103）加入指定管控期内非柜面日累计限额调整限制。默认 48 小时（参数），由布控报文"保护小时数"实时调整；保护小时数 = 0 时不做限制、不向核心发送管控。核心以收到请求时间为管控开始，结束时间 = 开始时间 + 保护小时数，到期自动失效；
4. 确认：建立二次查询重发机制——发送下调指令后查询核心执行结果，未成功立即重发，二次重发仍失败以短信通知业务人员；提供手工重发页面支持批量勾选；
5. 通知：管控成功后向出账卡号对应客户预留手机号发送提示短信（按卡号查客户号、再查客户号查手机号）。

管控期交易管控（渠道侧）

• 手机银行：进入转账页（账号、手机号转账）先经非柜面限额调整限制接口查询是否管控期内；管控期内输入超限金额时正常展示超限提示（优化文案、“下一步"可点击），点击后弹窗防诈提示并同步上报 103 接口；客户确认关闭弹窗后返回转账页，“下一步"置灰。
• 个人网银：本行/跨行转账、批量转账点击"确定"时增加管控期校验；在管控期且转账金额大于等于非柜面日累计限额时弹窗提示并同步上报 103 接口；不在管控期按现有逻辑执行。
• 限额控制期间，付款账户失败交易明细逐笔发送至平台（手机银行、个人网银渠道场景，103 接口）。

非柜面限额修改拦截（渠道侧）

• 前置校验：用户维护"非柜面支出总限额"时先调核心限制校验接口；受限且原因为"公安受害人拦截"时，页面红色提示、“编辑"与"确认修改"按钮置灰。
• 提交拦截：前置校验未拦但核心修改接口执行失败且失败原因为"公安受害人拦截”（核心新增专属错误码）时，结果页提示修改失败并展示一致的红色提示文案。
• 客户服务系统 1004 限额维护交易同步增加管控校验（红字提示 + 禁止维护）；1013 限制名单查询及管理交易支持该限制的查询与单笔删除，删除需集中授权。

解控与布控规则修改

• 解控及规则修改结果向公安报送失败时均按报文规则建立异常重报机制（暂定 3 次，参数化配置），仍失败增加手工发送/处置功能。

网点人工解限与柜面限额维护

48 小时管控期内，客户可至智慧网点/柜面申请解除限额限制并调整限额，与公安 04 解控指令并行互补；限制到期后自动失效，无需人工办理。流程见时序图阶段五。

• 智慧网点（我的账户）：非柜面支出总限额维护按是否在限制名单区别校验——在名单内时限额区域展示”！“标识，点击修改弹窗提示并提供【取消】/【好的】按钮；账户受限维护页面展示"账户受限"标识，限制名单仅支持删除（不支持新增与修改），维护规则同生产抑制代码（双人审核）。
• 智慧网点（外出审核/行员端）：维护限额时展示后台返回的操作员号与备注；在限制名单内时限额区域红字提示"公安受害人拦截，请审慎办理”（行员端为"保护性限额管控账户，请审慎办理”），展示限制名单维护信息及《非柜面支出限额审批表》影像节点，双人审核通过后分别发核心删除限制、修改限额；营销中心、360 查询的【账户受限】标签同步展示新增限制信息、操作员号与备注；子流水新增操作员号与备注（修改前后对照展示），电子凭证不展示。
• 智慧网点（手机银行签约类交易）：签约、维护、加挂、解挂增加限制名单校验，在名单内则提示跳转"我的账户"解除限制并维护限额。
• 客户服务系统（柜面）：1004 限额维护交易进入时查询核心判断管控，存在管控则红字提示"公安受害人拦截"、展示统一提示语且不允许维护非柜面支出限额；1013 限制名单查询及管理交易支持新增限制的查询与单笔删除，删除需集中授权。
• 核心系统：删除该类限制时联动删除非柜面限额最新一条维护记录的"备注"，并记录操作员、操作时间、原因；允许手工解除的渠道可配置（如柜面）。

批量转账场景风控（新增）

新增个人网银渠道批量转账场景：新增实时批量风控服务接口对接行内 ESB，接收手机银行、个人网银批量转账数据；渠道端将批量转账拆分为单笔不超过 100 个对手账户。系统将拆分后数据按单条流水逐一调用决策引擎，保存批量批次号与各笔流水关联关系；事件上报时决策引擎依据批次号查询该批次全部流水并结合上报状态逐笔更新处理结果。

核心系统改造

• 新建**“反诈一体化 48 小时禁止调整非柜面限额"账户级限制**：控制账户在时限内不允许调整非柜面限额，到期自动失效；时限为参数由有权接口上送；如需手动解除由渠道发起解限交易，可配置允许手工解除的渠道（如柜面）。
• 解除该类限制时做特殊处理：联动删除非柜面限额最新一条维护记录的"备注"内容，并记录操作员、操作时间、原因。

渠道改造要点

关键参数与规则汇总

统一客户提示语

阻断、管控及限额修改拦截场景向客户展示统一文案（红色或醒目方式）：

尊敬的客户，为保障您的资金安全，您暂时无法通过电子渠道办理该笔业务，建议您携带有效身份证件、银行卡等相关资料至我行网点办理。温馨提示：请不要向陌生人转账，谨防电信网络诈骗，保护个人财产安全。

非柜面限额修改拦截场景中"办理该笔业务"表述为"修改非柜面限额”，其余一致。

事后预警联动

事中交易监控平台触发黑名单管控和交易拦截管控预警后，将"触发时间、账号、触发规则名称（公安事中下调限额（个人））“三个关键数据实时推送鹰眼平台，其余案例数据由鹰眼自行加工；鹰眼新增规则 FM0244030 公安事中下调限额（个人），原"M244 事中管控模型（对公）“更名为"M244 事中管控模型”。模型策略仍部署在事中交易监控平台，鹰眼侧仅展示与开关操作。

5.2 - 受害人精准拦截技术实现方案

依据受害人精准拦截业务需求（源自《金融反诈一体化平台关于受害人精准拦截功能的需求分析文档》V0.1）编制，回答三个问题：各系统要实现什么功能、系统间如何交互、交互异常如何处理。

方案概述

总体采用**“一个报文枢纽 + 两个执行核心 + 多渠道接入 + 事后闭环”**的架构：

• 有权机关查控管理平台作为唯一对接公安反诈平台的报文枢纽，负责验签解析、名单转发、明细报送与限额调度；
• 事中交易监控系统负责布控落地与交易实时拦截；核心系统负责非柜面限额与限制的账户级管理；
• 交易渠道（手机银行、个人网银、互联网支付、自助设备、网联前置、银联）统一经 400226 上送风控校验；
• 智慧网点/柜面提供人工复核与授权解限；鹰眼系统承接事后核查处置。

全屏打开 ↗

端到端消息流（五阶段 31 条消息，含网点人工解限）详见业务流程时序图。

各系统功能实现

有权机关查控管理平台（报文枢纽）

事中交易监控系统（实时拦截）

• 名单布控：接收名单摘要落库"公安管控黑名单"，按生效/失效完成布控与撤销；布控规则随报文灵活调整、非固化。
• 拦截规则引擎：校验顺序置于司法冻结、涉案账户名单之后、其他规则之前，不涉白名单；仅校验收款账户——对交易收款账户等要素执行 SM3 加密后与名单摘要比对（摘要一致即命中，全程不还原明文），命中且单笔金额超布控阈值即阻断，未超阈值继续其他规则。
• 阻断反馈：命中后立即向渠道返回风险评分 90 与"公安受害人拦截"标签；当笔明细（含批次编号、出账卡号明文/加密、默认管控时间、风险标签）实时推送有权。
• 核查单生成：阻断明细生成核查单发鹰眼系统，支持全量检索。
• 批量转账风控（新增）：对接行内 ESB 的实时批量风控服务接口，接收渠道拆分后（单笔 ≤100 个对手账户）的批量数据，逐笔调用决策引擎，维护批量批次号与流水关联；事件上报按批次号逐笔更新流水状态。
• 拦截信息推送（命中即报）：命中受害人精准拦截规则即直接向有权机关查控平台推送拦截信息，不等待各电子渠道的交易成败通知；存量 DSG→Kafka 终态通知通道保持原逻辑不变（见拦截信息推送与终态通知的关系）。
• 监测渠道：个人手机银行、个人网银、网联前置、银联、互联网支付平台、自助设备、智慧网点。

核心系统（限额与限制管理）

• 限额查询/调整：1400061037 非柜面限额查询；1200061072 限额调整，记录"公安受害人拦截"备注与操作员号以区别其他场景。
• 账户级限制（新增）：新建"反诈一体化 48 小时禁止调整非柜面限额"限制——时限为参数（由有权上送保护小时数），到期自动失效；可配置允许手工解除的渠道。
• 限制维护：12000103 限制名单接口，管控开始时间为请求接收时间，结束 = 开始 + 保护小时数。
• 解除联动：解除该类限制时联动删除非柜面限额最新一条维护记录的备注，并记录操作员、时间、原因。
• 配套接口（新增）：非柜面限额修改可行性校验接口、限额查询"备注"字段、“公安受害人拦截—有权下调"专属错误码。

电子渠道（手机银行、个人网银）

• 字段规范：账号/手机号/快捷/常用收款人/重复/预约付款（手机银行），账号/常用收款人转账（网银）等场景调用 400226 时统一上送字段格式。
• 标签识别与阻断：收到"公安受害人拦截"标签（评分 90）立即判定交易失败，红色醒目展示统一提示语。
• 限额修改拦截：前置调核心校验接口，受限则提示并置灰"编辑/确认修改"按钮；提交后失败（专属错误码）在结果页提示。
• 管控期校验（手机银行）：进转账页先查管控状态；超限输入时提示优化、“下一步"可点，弹窗提示并同步上报 103，确认后返回且按钮置灰。
• 管控期校验（个人网银）：本行/跨行/批量转账点"确定"时校验，超非柜面日累计限额即弹窗并上报 103。
• 失败交易上报：管控期内失败交易逐笔上送有权 103 接口。

其他监测渠道

互联网支付平台（支付）、自助设备（转账）、网联前置（支付）、银联（转账、刷卡消费）：按各自场景规范 400226 上送字段，获取不到的字段传 -；互联网支付平台同步改造限额查询备注字段与可行性校验接口；网联、银联无客户提示功能。

智慧网点/柜面

• 我的账户：非柜面限额维护按限制名单区别校验（"！“标识、弹窗）；限制名单仅支持删除、双人审核；红字"公安受害人拦截，请审慎办理"提示与《非柜面支出限额审批表》影像节点；审核通过后发核心删除限制、修改限额。
• 行员端：审核页展示操作员号与备注；营销中心、360 查询展示新增限制名单信息。
• 客户服务系统（柜面）：1004 限额维护存在管控时禁止维护并提示；1013 支持限制查询与集中授权删除。

鹰眼系统与事后交易监控

接收核查单后处置；事中推送"触发时间、账号、触发规则名称"三个关键数据，其余案例字段鹰眼自行加工；新增规则 FM0244030"公安事中下调限额（个人）"，原 M244 模型更名"事中管控模型”；模型策略仍部署事中，鹰眼仅展示与开关。

配套系统

企业知识平台、事后监督系统、集中作业（远程银行）：同步子流水/中台流水新增字段（操作员号、备注）、影像节点与凭证映射，支持抽数展示。

系统间交互设计

公安平台 ↔ 有权机关查控平台

有权 ↔ 事中交易监控

有权 ↔ 核心系统

渠道 ↔ 事中 / 核心 / 有权

拦截信息推送与终态通知的关系

背景（现有逻辑）：各电子渠道交易经事中风控判断后，渠道通过 DSG（商用 CDC 工具）采集 → 事中 Kafka 的模式向事中回传交易成败通知，事中消费后补齐交易终态。

业务决策：经业务确认，事中交易监控系统命中受害人精准拦截规则即产生确定的拦截结果，无需等待各电子渠道的交易成败通知，直接向有权机关查控平台推送拦截信息；存量 DSG→Kafka 终态通知通道保持原逻辑不变。

决策理由：

1. 拦截即终态：命中拦截规则时交易当笔被阻断（结果确定为失败），不依赖渠道事后终态确认；
2. 满足监管时效：拦截明细要求实时上报（103 上报后 5 分钟 104 回执窗口），命中即报不引入 CDC 采集、投递、消费的累计时延；
3. 零额外改造：不新增渠道↔事中结果回传接口，DSG→Kafka 通道与各渠道无需为本场景调整。

批量转账场景按需求保留既有事件上报设计（携带批次号更新该批次全部流水状态），与拦截信息推送互不影响。

数据流总览

以数据资产为主视角的流转全景：名单数据自公安单向下发并落库摘要、交易数据自渠道上送比对命中、管控数据在有权与核心间闭环、处置数据流向鹰眼与后督配套。

全屏打开 ↗

异常处理设计

处理原则

1. 登记留痕：所有失败交互登记入库（含批次号、原因），支撑追溯与人工处置；
2. 有限重试：按环节配置重试次数（默认 3 次，参数化），避免无限重试放大故障；
3. 告警升级：重试耗尽后短信通知业务联系人，由人工电话联系/页面处置；
4. 人工兜底：关键环节提供操作页面（明细补送、指令重发、反馈重报）；
5. 状态闭环：名单/限制均有状态机（生效/失效、限制/解除），到期或指令驱动收敛，杜绝中间态悬挂。

异常场景与处理矩阵

重试策略汇总

一致性与幂等

• 批次号贯穿：原发起方批次号自 105 下发起贯穿布控、阻断、上报、解控全链路，作为幂等键与关联键；
• 双轨卡号：出账卡号/账号行内留存明文（供解限取用与上送），上送公安时同时提供明文字段值与 SM3 加密字段值，供公安侧校验；
• 状态机驱动：名单（生效/失效）、限制（限制中/到期/已解除）均以状态机管理，48 小时限制由核心按时间参数自动失效，不依赖额外触发；
• 整批原子：名单 50 条/批整批处理整批反馈，避免批次部分成功造成状态不一致；
• 拦截推送幂等：拦截信息以原 400226 流水号为幂等键，重推不产生重复明细；批量转账事件上报按批次号+流水号幂等，更新该批次全部流水状态（存量设计）。

关键技术要点

1. 摘要比对命中：105 报文名单要素以 SM3 摘要下发，单向不可逆、不可解析；事中对相应场景交易的收款账户等要素执行同算法 SM3 加密后与名单摘要比对命中，全程不还原明文，报文异常不影响其余名单处理；
2. 规则顺序：疑似涉诈名单校验置于司法冻结、涉案账户名单之后，避免与既有司法管控冲突；
3. 限额区分：核心限额调整以"公安受害人拦截"备注+操作员号标识，解限时联动清理，与其他限额场景隔离；
4. 错误码扩展：核心"修改非柜面限额"错误码体系新增专属码值，支撑渠道精准识别与交互控制；
5. 批量拆分：渠道端将批量转账拆分为 ≤100 个对手账户的单笔流水，决策引擎逐笔处理，批次号支撑事件上报批量更新；
6. 命中即报：拦截场景不依赖渠道终态通知——命中受害人精准拦截规则即向有权推送拦截信息；全量交易成败通知维持 DSG→Kafka 原有模式，零通道改造。

涉及系统改造清单

6 - 市场风险

市场风险管理系统相关的方案分析与实施文档：

• 数据接口 ESB 化实施方案：交易数据与估值结果由 DSG 改为 ESB 的目标架构、接口清单、交互设计、工作量分工、分批实施路径与风险应对

6.1 - 数据接口 ESB 化实施方案

本方案依据《市场风险管理系统数据接口调整方案分析》（2026 年 8 月 18 日，v1.0）的评审结论编制：市场风险管理系统的交易数据与估值结果接口由 DSG 数据同步改为 ESB 企业服务总线，市场数据保留 DSG / 企业知识平台。本文为实施版本，覆盖目标架构、接口改造明细、估值交互设计、工作量分工、分批实施路径与风险应对。

一、背景与方案概述

1.1 业务背景：准实时估值

市场风险管理系统建设准实时估值能力，主要基于以下诉求：

• 满足监管要求：准实时估值是响应监管机构对市场风险管理时效性要求的重要举措；
• 及时的风险监控与预警：风险管理部通过准实时估值及时掌握业务开展情况与限额执行情况（准实时限额依赖于准实时估值），当出现异常或超限情形时，系统通过邮件、站内信等方式自动推送预警通知；
• 为业务系统提供估值服务：将估值结果输出至业务系统，便于其在业务流程中直接使用，项目第一阶段按每小时频率向外汇交易系统反馈估值结果。

1.2 方案概述

交易数据（5 个接口）与估值结果（2 个接口）共 7 个接口改走 ESB，市场数据（18 张表）保留现有通道，CLN 与 CDS / CRMA / CRMW 维持手工导入：

ESB 同时承载交易数据接入与估值结果输出，实现交易-估值链路的标准化——服务契约、消息确认与重试补偿、全链路监控与审计；市场数据为批量同步场景，按投入产出比保留现状，优先将 ESB 资源集中于收益最高的交易与估值链路。

二、方案总体设计

2.1 目标架构

全屏打开 ↗

交易数据（5 个接口）与估值结果（2 个接口）改走 ESB：ESB 同时承载交易数据接入与估值结果输出。市场数据保留现状：外数 8 张小时级表与外汇牌价秒级表继续走 DSG 同步，9 张 T日 表继续走企业知识平台。CLN 与 CDS / CRMA / CRMW 为手工导入 CSV，无系统接口，不受本次改造影响。

2.2 设计原则：数据特征与集成方式匹配

三类数据与两种通道的匹配逻辑：

• 交易数据——事件驱动，适合 ESB：交易数据随交易发生而生成，量级可控（5 个接口）。走 ESB 带来实时性（交易发生后及时进入系统，支撑准实时风险计量）、可靠性（消息确认、重试与补偿，避免数据丢失）与可追溯性（全链路监控审计，满足风险数据治理要求）；
• 估值结果——双模式输出，ESB 是唯一可行路径：批量推送与单笔查询两种目标模式均为已确认需求，DSG 无法主动推送至外部系统，也无法提供请求-响应式查询；
• 市场数据——批量同步，保留现状投入产出比最优：三类市场数据均为批量数据同步，不需要 ESB 的请求-响应与服务契约能力（详见 3.3 节）。

2.3 改造范围总览

三、接口改造明细

3.1 交易数据导入接口（共 7 个，改造 5 个）

不同产品的交易数据结构不同，接口需按产品分别提供，无法合并为统一接口——改走 ESB 后接口数与现状一致。

3.2 估值结果输出接口（2 个）

3.3 市场数据（18 张表，保留现状）

保留现状并非技术约束（50tps 足够），而是投入产出比的最优选择：优先将 ESB 资源用于收益最高的交易数据与估值结果链路。完整表清单见 8.1 节。

四、估值结果交互设计

4.1 交互时序

全屏打开 ↗

4.2 调用模式与通道能力对照

当前估值交互为异步模式：外汇系统先输入交易、另行查询估值，两次独立交互。目标改为批量推送与单笔查询双模式并存，覆盖完整性与实时性两类诉求。两种模式是已确认的目标模式，ESB 是满足该需求的唯一可行路径。

4.3 ESB 可靠性机制

• 监控：ESB 平台提供消息全链路追踪与可视化看板，可按消息 ID 实时查询投递状态；
• 重试：失败消息自动重试达设定次数后进入死信队列（DLQ），支持补偿重发，避免数据丢失；
• 审计：消息收发日志持久化存储，满足风险数据治理的合规审计要求。

4.4 大数据量兜底：文件传输 + ESB 通知

若批量推送的估值结果数据量过大（如持仓数量众多），直接通过 ESB 消息体传输可能导致消息体积超限。此时采用文件传输方案：市场风险系统将估值结果生成文件，通过影像平台传送至对方系统，同时通过 ESB 发送「文件已准备就绪」的轻量通知，对方系统收到通知后前往影像平台拉取文件。大数据量的实际传输由影像平台完成，ESB 仅承担通知角色。

五、工作量与分工

5.1 主系统侧（约 1.5 人月）

5.2 外围系统影响

六、实施路径

6.1 分批实施

全屏打开 ↗

实施分三个阶段推进：

1. 估值先行（第 1–2 周）：优先完成估值 ESB 服务开发（契约定义、批量推送 + 单笔查询）与外汇系统估值消费侧适配，估值链路 1 周内完成开发与自测，不依赖外围系统改造；
2. 交易并行改造（第 2–3 周）：主系统 5 个接口读取逻辑返工，与票据 / 贸金 / 外汇发送侧开发并行推进；DSG 保持运行，ESB 灰度双轨验证数据一致性；
3. 联调提测与分批上线：估值 + 交易链路统一汇入联调窗口；估值接口随版本正常上线，交易数据视联调情况上线，未就绪时延至下一版本，不阻塞整体进度。

6.2 工期影响与缓解

当前项目计划提测时间尚余约 3 周：

七、风险与应对

整体风险等级：中，通过分批实施与双轨验证可控。

八、附录

8.1 市场数据表清单（18 张，保留现状）

8.2 未来演进：市场数据 ESB 化

外数 8 张小时级表与外汇秒级 1 张表当前保留 DSG；若未来行内统一集成架构有硬性要求，可将其迁移 ESB（需外数系统团队开发发送侧逻辑），建议先迁移小时级表、再评估秒级表；9 张 T日 表无论何时均保持企业知识平台不变。

本文基于《市场风险管理系统数据接口调整方案分析》的评审结论编制，工作量与风险等级为估算值，实际需结合各系统数据量、ESB 平台容量与排期进一步细化。

7 - AI

AI 相关的应用设计、架构方案与实验记录：

• 综合智慧信贷：综合智慧信贷项目的 AI 架构方案、智能信审平台业务架构与九章需求文档，含十五张交互式图表
• 星辰智能：结算类凭证要素核验需求规格与平台架构解读，以及智能文档识别平台规划方案，含交互式图表

7.1 - 综合智慧信贷

综合智慧信贷项目（智慧信贷二期 AI 能力建设）相关文档：

• 综合智慧信贷 AI 架构方案：业务、应用、技术、集成、部署、数据六个视图的架构总结，含九张交互式架构图（知识库、财务分析、制度解析与场景规则集技术架构）
• 智能信审平台业务架构：五大智能应用、四类底层能力、评价闭环与外部协同的业务架构全景
• 智能信审平台需求文档：依据 911 版软需与对外交互方案编制的九章需求文档及 0924 版财务风险分析补充章，含业务功能架构、两条业务主线、放款智能审核时序与目录版本生命周期等六张交互式图表
• 财务风险分析系统详细设计与实施方案：多智能体财务分析 PoC 的详细设计——总体架构、分析流水线与重算回路、数据层、规则库与判定引擎、议题聚合评分、图表体系、四类 LLM Agent 协作、前端页面与里程碑验收，含三张交互式图表

7.1.1 - 智能信审平台业务架构

依据《信贷项目-智能信审平台-911》需求规格说明书与《智能信审系统对外交互方案-911》整理，政策文件解析部分同步《政策文件解析需求规格说明书（0908）》。智能信审系统是智慧信贷二期 AI 能力建设的载体：门户以微前端形式集成信贷系统与智能信审两个平级子应用，前端互操作（悬浮按钮、页面跳转、页面嵌入）发生在两个子应用之间；后端与信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台协同工作。

定位与设计原则

平台以 “科技赋能业务、辅助不替代、增强不决策” 为核心原则：所有 AI 输出仅供人工确认与复核，不直接改变信贷业务流程数据。系统整体由 “底层能力 + 应用功能 + 评价闭环” 三层构成，并承载四项业务目标：

• 效率提升：审查报告由"从零撰写"转为"审核修改"；知识获取由翻阅文档转为即问即答。
• 风险管控：审查阶段前置识别调查报告专项风险与制度合规冲突；放款环节闭环校验批复条件与材料完整性。
• 知识沉淀：以"制度 + 案例 + 知识"一体化底座，将分散经验转化为可检索、可复用的结构化资产。
• 可控迭代：悬浮按钮统一入口、评价闭环与效果评价分析，保障 AI 能力可落地、可控制、可迭代。

业务架构总览图

全屏打开 ↗

术语与角色

核心术语：智能信审系统（AI 能力载体，与既有信贷系统接口集成）；小查（全面风险分析助手：制度合规检查、调查报告专项分析、财务分析）；小审（历史案例检索，即类案对比）；小核（智能审核助手：放款、出账、贷前落实条件、借款合同、贸易合同审核及制度合规检查）；小问（智能知识问答）；悬浮按钮（FAB，统一入口）；制度拆解（制度 → 结构化合规规则）。智能体分为任务式（小查、小审、小核，批量分析任务产出结构化结果）与对话式（小问，多轮对话逐条评价）两类。

主要角色：客户经理（业务发起、资料上传）、审查审批人员（小查查看/补充发起、审查意见确认、类案对比）、放款审核岗与出账审核岗（审核结果复核）、政策解析管理员与标准词库管理员（制度解析配置）、评价分析管理员与系统管理员（评价治理、悬浮按钮与运行管理配置）。

端到端业务流程

按对外交互方案，业务主线分三个环节、十二个场景：

业务发起与审查环节（场景 1–5）

1. 业务发起与调查报告获取：客户经理在调查报告系统完成尽调报告，正式版自动以 PDF 存入影像平台并登记文件索引；授信作业中心在授信申请提交成功后调用**“小查与审查意见生成统一发起接口”**——智能信审系统按业务流水号查询文件索引、拉取 PDF 本地暂存（不进知识库），统一执行一次财务分析与制度分析（财务要素、企查查、行业均值、政策法规等数据支撑只发生一次），结果复用后分别创建小查与审查意见生成任务。
2. 审查岗查看全面风险分析：审查审批人员进入业务详情后前端缓存点亮"小查"；因小查已随提交自动执行，此时点击属重复发起，按运行管理配置处理（允许重复时覆盖原任务、执行中任务自动终止）。
3. 审查岗出具审查意见：审查意见初稿已自动生成，审查人员经"查看/编辑"按钮以 URL 跳转（mode 参数区分只读/可编辑）；系统经客户关系查询接口自行生成集团关系图谱；授信作业中心跳转前完成权限校验，本系统在查看与下载时二次校验。
4. 审查岗类案对比：按业务特征检索相似历史案例，结合三套材料向量化内容与五级分类数据执行数据抽取与对比分析；贷款完整业务信息以页面嵌入方式由授信作业中心承接。
5. 终审与业务资料入库：终审通过——审查意见、批复入库（三套材料）；终审拒绝——仅审查意见入库（两套材料，无批复）；终审再议——流程废弃、不通知不入库。统一打标字段编码进文件名传递。

出账与放款环节（场景 6–9）

6. 出账申请资料上传 / 8. 放款申请资料上传：由智能信审系统承接（页面跳转唯一入口），支持目录同步与版本回滚、逐条不可删除标记、复用历史材料（物理复制两份）、目录影像映射回传（含失效状态）；上传任务提交不触发审核。
7. 出账审核 / 9. 放款审核：以授信执行中心的出账申请（paymentManage）/放款申请（loanReleaseApply）提交事件为唯一发起点，自动调用"放款智能审核接口"——同时执行材料智能审核与制度风险分析，返回双结果与取高后的合并风险等级；个贷放款审核另经 EDS 核对交易对手经营范围与贷款用途。出账审核与放款审核相互独立、不得互相覆盖。

评价与门户环节（场景 10–12）

10. 未评价结果门户提醒：每日批量生成未评价提醒文件上传影像平台，门户定时轮询获取并处理为门户提醒。
11. 门户主数据同步：机构、用户、角色及两类关系经 ESB 实时通知 + 企业知识平台表级同步（菜单不同步）。
12. 知识库门户接入：知识库功能提前上线，以门户菜单直接集成（对话框问答 + 资料管理），不经悬浮按钮。

入口与触发机制

悬浮按钮（FAB） 以 npm 包 + 微前端形式常驻信贷作业页面右侧：折叠态圆形主按钮，悬停展开查 / 审 / 核 / 问单项入口；按管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文与任务状态动态展示，控制顺序为"管理员禁用 → 整体隐藏 → 用户始终隐藏 → 用户始终启用 → 自动显示"。存在未读已完成任务时圆点显示红点，启用风险提醒的功能显示风险等级角标（高/中/低/疑，放款/出账审核取材料与制度风险的更高者，高风险时字符交替闪烁）。

触发方式矩阵：

门户侧同时提供菜单直达与页面集成形态；统一身份认证、业务上下文透传（前端缓存 sessionStorage 写入业务流水号、合同号、客户号、批复编号）与免登录保障多入口体验一致。

应用功能层：五大智能应用

类案对比的运行机制：经 ESB 查询业务基本信息与对比业务关键要素快照，按业务特征检索相似历史案例；通过影像平台拉取三套材料 PDF 向量化入库，从企业知识平台实时获取贷后五级分类数据。对比分析采用固定公式 + 可配置业务参数口径（相似度权重、行业分值、置信度阈值由管理员维护，公式由系统固定执行、后端独立校验），大模型分析分两阶段执行——先逐案例生成摘要，再基于全部摘要生成综合建议（含建议敞口额度、期限与风控措施）。分析材料还包括行业/产品映射与抽取字段配置（项目贷款/非项目贷款由固定资产贷款产品名单自动判定）。

智能审核的规则体系：按目录节点配置审核规则，支持五种判断模式（图片直接大模型判断 / 提取要素后规则判断 / 提取要素后大模型复核 / 已有解析结果大模型判断 / 规则初判 + 大模型处理例外）；预审按输入指纹（材料内容哈希、目录绑定、规则版本）沿用上次有效结果，避免重复调用大模型。放款/出账审核同时执行制度风险分析——检查范围按智能制度检查配置的节点制度映射确定（loanReleaseApply 与 paymentManage 各自映射制度集合，个人条线复用同名映射），制度审核维度复用小查结果面板样式，风险条目提供制度条文与业务证据双重溯源。

业务材料上传（出账/放款申请）：影像目录树由信贷系统统一配置（影像树与产品相关），目录维护采用"联动差异确认"与"候选版本逐条确认 + 回滚"并列两种方式；业务打回后退回材料按逐条不可删除标记控制；支持复用历史材料（信贷系统物理复制两份实体文件，不做链接引用）；文件上传/删除/失效后经"业务目录影像映射回传接口"回传授信执行中心，任务提交时全量核对；文件实体存影像平台，本系统仅保存元数据与"目录节点 ↔ 影像文件"对应关系。

审查报告生成：融合业务基本信息、财务要素、客户关系（自行生成集团关系图谱图片）、行业均值与政策法规等多源数据，按模板生成报告初稿与结构化批复条件；查看/编辑双模式经 URL 参数区分，报告下载在审查意见页面内完成；ESB 调用失败时对应数据区域降级展示，不影响其他部分。

底层能力层

• 制度拆解与检查：将制度文件拆解为结构化合规规则，支撑小查制度合规检查，并为小核制度风险分析、审查报告生成提供合规规则依据；属需求分析性功能，不部署于生产环境。依据《政策文件解析需求（0908）》：以"标准对象库 + 三层同义词库（标准词/别称/上下位）“为双重语义基石；制度条目解析分为规则、说明、材料审核、流程审核四类（规则类生成规则表达式与审核要点，说明/材料审核/流程审核类不拆解）；支持生成新版本、历史版本、制度补充与修订（补充/更新两类，关联对象库与标准词库）、一致性检查（版本间规则表达式差异逐条确认）与审核场景配置/场景规则集（按适用产品×审核阶段裁剪规则并版本化推送，供小查/小核按场景执行）。
• RAG 知识底座：制度、操作手册、流程等知识的向量化底座，支撑小问问答与类案对比。业务资料按终审结论入库：通过业务入库调查报告、审查意见、批复三套材料（审批结论=通过），拒绝业务入库调查报告与审查意见两套（无批复），再议业务流程废弃不入库；统一打标字段由授信作业中心编码进文件名传递（含业务流水号、企业性质、企业规模、经营年限、所属行业、贷款用途、产品、主担保类型、所属分行、审批通过时间、审批结论），打标自文件名解析；同一材料类型更新时覆盖旧有效版本。场景 1 拉取的调查报告仅本地暂存，不进知识库。
• 历史案例库：标准化历史审批案例，以业务摘要 + 统一打标组织，支撑类案对比的语义检索（业务摘要）与精确条件检索（统一打标）。
• 财务分析：911 版需求中小查财务分析子模块标注"建设中占位”，《财务风险分析系统需求文档（0924）》已给出完整设计——作为信贷审批流程的"财务分析"环节（评审经带参跳转进入），按 969 条规则逐条核查年报：四层筛选（适用对象/数据可得性/业务前置/规则类型）与五类阈值形态、议题聚合（44 个事实域）与三轴评分（重大问题数/问题密度/加权分取中位）、八条一票否决重点关注事项、38 条程序生成图表、大模型仅承担判读与结论文案（五条硬约束：只用给定事实、人工判定优先、档位一致、触发否决必须不建议准入、固定 JSON 输出）。数据侧：三表科目取自行内已审批尽调报告，附注经影像平台 OCR + 人工补录，企查查经 EDS 获取，行业均值由企业知识平台同步。与 911 版"建设中"口径的关系（独立系统还是小查子模块的落地形态）建议在需求侧对齐，见需求文档第 10 章。

运行管理与任务模型

• 任务状态机：运行中 → 部分完成（仅小查，按子模块汇总）→ 已完成（成功/失败）；小核不产生部分完成状态。
• 唯一轮询器：有运行中任务默认每 10 秒、无任务每 60 秒拉取任务汇总；已完成未读数增加时弹出汇总通知。
• 运行管理配置：任务类型、模式、唯一性标识、是否可重复发起、失败重试次数与运行时间限制；允许重复发起时覆盖原任务（原任务仍在执行则自动终止），禁止重复时按入口语义拒绝或回退手工。
• 风险提醒：小查、小核启用风险提醒后，未读已完成任务驱动悬浮按钮风险角标（高/中/低/疑），风险等级文案经统一字典加载，颜色可按级自定义。

评价管理闭环

评价管理覆盖任务式智能体（小查、小审、小核）与对话式智能体（小问）：评价查询沉淀逐条评价明细（评分、评价等级、反馈原因、补充说明、截图）；效果评价分析对智能体服务效果做周期性量化分析，反哺模型与功能优化；评价提醒配置与未评价提醒——智能信审系统每日批量生成未评价提醒文件上传影像平台约定目录，门户定时轮询获取并处理为门户提醒（仅提醒最大提醒天数内、默认 7 天的未评价任务；对话式 AI 任一回答未评价即视为任务未评价）。

外部协同与交互模式

系统间交互抽象为六种模式：

关键接口（发起方 → 本系统）：小查与审查意见生成统一发起接口、放款智能审核接口、审查意见/批复入库通知接口、门户主数据变更通知；（本系统 → 外部）：调查报告文件索引查询、财务要素查询、企查查数据查询（EDS）、五级分类数据查询（企业知识平台）、放款/出账要素与合同信息查询、业务目录影像映射回传、客户关系查询。

边界与安全约束：审阅结果由智能信审前端承载展示，授信执行中心经状态/结果查询接口获取结论，不回写信贷业务表；授信作业中心在页面跳转前完成权限校验，本系统在查看与下载时二次校验授权上下文，未授权访问、拼接 URL 与越权下载被拒绝并记录审计日志；影像目录维护、任务发起等管理动作按角色权限隔离。

需求依据

• 《信贷项目-智能信审平台-911》需求规格说明书（业务功能、悬浮按钮、五大应用、评价管理）
• 《信贷项目-智能信审系统对外交互方案-911》（12 个交互场景、六种交互模式、接口清单）
• 《信贷项目-智能信审平台-软需-政策文件解析0908》（对象库与三层同义词库、四类解析、制度补充修订、一致性检查、场景规则集）

7.1.2 - 综合智慧信贷 AI 架构方案

依据《综合智慧信贷 AI 架构方案》整理。方案覆盖 AI 能力从业务场景到基础设施的完整链路，按 应用逻辑 → 系统技术 → AI 能力专项 → 数据 → 集成 → 部署 → 非功能设计 七个部分组织，本页按六个架构视图归纳其核心内容，各章节嵌入对应的交互式架构图。

一、业务架构

自上而下四层：场景层 → 智能应用层 → 能力支撑层 → 评价管理（闭环），核心原则是"辅助不替代、增强不决策"，所有 AI 输出均需人工确认。

• 场景层（用户入口，五个智能助手场景）：智能审查助手、审查报告 AI 智能生成、智能化批复助手、放款审核助手、智能知识库。
• 智能应用层（五个 AI 智能应用，内部可协同、复用输出）：小审·历史案例检索、小查·全面风险分析、审查意见生成、小核·放款审核、小问·智能知识问答。
• 能力支撑层（四大能力）：案例库、制度拆解与检查、财务分析、知识库。
• 评价管理：评价查询、效果评价分析、评价提醒配置与未评价提醒、评价设置，形成"使用 → 评价 → 分析 → 优化"闭环。

场景与应用的映射关系：智能审查助手先类案检索、后风险分析；审查报告 AI 生成可复用小审、小查输出；智能化批复助手聚焦制度合规冲突生成批复建议；放款审核助手校验批复条件与材料完整性；智能知识库即问即答并返回引用来源。

全屏打开 ↗

二、应用架构

服务层内部划分为上下两个子区域：

• 核心业务与智能服务：信审业务服务（信贷审批核心业务逻辑）、知识库服务（知识存储与检索，支撑智能问答）、智能助手服务（面向用户的 AI 交互入口）、智能体运行服务（承载智能体运行时环境，支撑多智能体协同与执行）。
• 支撑与基础服务：任务规划服务（异步任务管理与调度）、文档解析服务（信贷文档解析与结构化）、组织权限管理服务、认证授权服务、模型网关服务（统一模型调用与路由）、智能体追踪评价服务（智能体行为追踪与效果评价）。

调用关系：上半部分服务可调用下半部分支撑服务，并可通过智能体运行服务调度多个智能体协同完成任务；所有服务经 Nacos 注册与发现，实现动态调用。数据读写走 OceanBase/Redis，异步通信走 RabbitMQ，检索走 Elasticsearch，文件存储走 MinIO，观测数据统一存入 ClickHouse（详见下方调用链路）。

全屏打开 ↗

三、技术架构

自上而下四层：接入层 → 服务层 → 平台支撑层 → 基础设施与模型服务层，核心原则为四层解耦、服务化拆分、统一接入管控、平台化支撑、算力与业务分离。

• 接入层：反向代理 Nginx（负载均衡、静态资源、请求转发）+ API 网关（统一鉴权、限流、熔断、路由）。

• 服务层：内部按"核心业务与智能服务 / 支撑与基础服务"上下分区。

  核心业务与智能服务：

  服务	职责
  信审业务服务	信贷审批核心业务逻辑，承载各应用的业务规则与配置管理
  知识库服务	知识存储与检索，支撑智能问答与内容溯源
  智能助手服务	面向用户的 AI 交互入口（Chat 交互）
  智能体运行服务	承载智能体运行时环境，支撑多智能体协同与执行

  支撑与基础服务：

  服务	职责
  任务规划服务	智能体任务编排、异步任务管理与调度
  文档解析服务	信贷文档解析与结构化（MinerU 双引擎）
  模型网关服务	Higress 统一模型调用、限流、路由与协议适配
  智能体追踪评价服务	智能体行为追踪与效果评价
  认证授权服务	用户认证与授权（对接门户 SSO 与主数据同步）
  组织权限管理服务	组织架构与权限管理

• 平台支撑层：

  中间件	职责
  OceanBase	关系存储（主从/集群、双活 RPO≈0），独立部署
  Redis	缓存与分布式协调（任务队列、分布式锁、解析缓存），独立部署
  RabbitMQ	异步消息与削峰填谷（镜像队列）
  Elasticsearch	全文检索与 2560 维向量相似度计算（向量库），独立部署
  ClickHouse	MPP 数据库，观测数据存储，独立部署
  MinIO	对象存储与溯源审计（多副本/纠删码）
  Nacos	服务注册发现与配置管理（多实例）

  中间件（OceanBase、Redis、Elasticsearch、ClickHouse 等）均为智能信审系统独立部署，不与其他系统共用。

• 基础设施与模型服务层：物理机/虚拟机提供部署环境，算力服务器（GPU，5 台，海光 M890P / 鲲鹏 910C 二选一）支撑模型推理与训练；模型网关 Higress 部署于行方现有服务器。

调用链路：

1. 请求入口：外部请求 → Nginx → API 网关（限流/熔断/鉴权）→ 路由至服务层对应服务；
2. 服务协同：核心服务调用支撑服务（任务规划、文档解析、模型网关等），并经智能体运行服务调度多智能体协同完成任务；
3. 模型调用：模型调用统一经模型网关（Higress）转发至算力服务器，业务服务不直连算力；
4. 数据与中间件：OceanBase/Redis 读写、RabbitMQ 异步通信、Elasticsearch 检索、MinIO 文件存储、ClickHouse 观测落库；
5. 观测：OpenTelemetry 全链路采集 Trace/Metrics/Logs 统一存入 ClickHouse（MPP 架构），轻量自研查询与告警；
6. 服务治理与部署：所有服务经 Nacos 注册发现，全部组件部署于物理机/虚拟机之上。

AI 能力专项技术架构采用三个层次：

1. 开发与执行层：LangGraph（高码流程编排，图/状态机建模、条件分支、循环、并行、人机协同）+ DeepAgents（高级 Harness，任务规划、工具调用、多智能体协同、记忆管理与上下文压缩）；
2. 模型接入网关层：Higress 统一大模型服务入口，多模型调度、负载均衡、故障转移、限流配额与密钥安全；
3. 质量保障层：OpenTelemetry 标准技术栈（全链路 Trace/Metrics/Logs 采集与轻量自研查询）+ DeepEval（覆盖 LLM、Prompt、RAG、Agent 的评测与 CI/CD 质量门禁）。

关键能力方案：知识库采用父/子/孙三级切片、多路混合召回（向量 + BM25 + 结构 + 表格）、Query Rewrite、Rerank 精排与 PCR 上下文完整召回，输出带文档名/页码/章节的引用溯源；文档解析采用 MinerU + 本地解析器双引擎、大 PDF 拆分并发、跨页表合并、表格分类与表头识别、单元格像素级溯源与财报结构化。

全屏打开 ↗

知识库技术架构

知识库由入库与检索两条链路构成：

• 入库链路：原始文档经 MinerU 双引擎解析归一化为扁平 items，按"父/子/孙"三级切片组织——父/子切片存对象存储、孙切片入向量库；表格按行拆分保留表头，政策类文档按"章节—条款"语义切片；孙切片向量化后索引落库至 Elasticsearch，原文与切片快照持久化至 MinIO。
• 检索链路：检索请求经查询理解（意图识别、查询扩展、错别字纠正）后进入多路混合召回——向量检索（Elasticsearch）与 BM25 全文检索并行，融合结构召回（摘要树）、表格专项检索与图片摘要匹配；候选经 Rerank 模型精排，融合向量分、BM25 分与精排分输出归一化置信度，PCR（Parent-Child Retrieval）保证上下文完整；结果返回文档名、页码、章节及匹配高亮，支持快速定位原文。
• 可配置检索：top_k、阈值等参数按知识库粒度配置，支持多 Embedding/Rerank 模型切换。

全屏打开 ↗

财务分析报告技术架构

财务分析报告以财报解析结构化为主线：

• 双引擎解析：MinerU 外部服务处理复杂 PDF/图片，本地解析器（openpyxl/python-docx/PyMuPDF 等）处理结构化文件，统一输出扁平 items 元素列表；非 PDF 文件经 LibreOffice 转 PDF，大 PDF 拆分并发解析后拼接。
• 结构化处理：items 后处理（排序、合并、注入 ID）与标题分级后，基于版面信息构建跨页链自动合并续页表格；表格分类与表头识别采用"规则粗判 + LLM 精分 + 页面聚类纠偏"，LLM 结构化输出表头行信息。
• 单元格溯源：调用外部 OCR 线框检测获取单元格物理坐标，支持旋转图片逆变换，实现像素级定位。
• 财报结构化与分析：元数据提取、三大报表识别、标准科目匹配后持久化至 MinIO，支撑指标计算、风险分析与财务分析报告生成。
• 规则判定与评分下游（依据《财务风险分析系统需求文档 0924》）：结构化产物进入判定引擎——969 条规则、17 字段、四层筛选（适用对象/数据可得性/业务前置/规则类型），阈值引擎采用受限表达式语言（仅白名单函数），恒等式 1% 容差、近似勾稽用偏离度与跳变双阈值；判定结果按 44 个事实域聚合为议题，三轴（重大问题数/问题密度/加权分）取中位数评级，八条一票否决事项触发即覆盖结论为"不建议准入"；38 条图表定义程序生成、阈值带可视化。大模型职责严格受限：档位与评级由系统计算，模型只生成判读三段（归因/定性/处置）与结论文案，受五条硬约束（只用给定事实、人工判定优先、文案不得与档位相反、触发否决必须不建议准入、固定 JSON 输出）——与"辅助不替代"原则及 7.5 节幻觉控制措施一致。集成侧经新窗口带参跳转 + SSO 进入，结论摘要回写审批单。

全屏打开 ↗

制度解析与场景规则集技术架构

依据《政策文件解析需求规格说明书（0908）》，制度解析以"标准对象库 + 同义词库“为双重语义基石，形成"解析—匹配—校验—反馈"闭环：

• 解析类型（四类）：制度条目分为规则、说明、材料审核、流程审核四类——规则类拆解为规则表达式与审核要点，分别供规则引擎确定性校验与大语言模型语义推理使用；说明/材料审核/流程审核类不做表达式与审核要点拆解。
• 双重语义基石：标准对象库（实体、属性、参考值，映射业务系统数据字典）+ 三层同义词库（标准词库、别称同义词、上下位同义词），条目解析时按语义相似度与对象库对齐，未命中返回原因供管理员迭代对象库。
• 版本与一致性管理：支持生成新版本、历史版本回溯、制度补充与修订（修订类型分制度补充/制度更新，关联对象库与标准词库后触发重新解析）；一致性检查对比版本间规则表达式差异，冲突条目逐条确认后触发规则集更新。
• 场景规则集：按适用产品 × 审核阶段联合唯一配置场景，从制度按阶段筛选规则条款加入规则集，版本化管理并通过一致性检查后推送生效——为小查制度合规检查与小核制度风险分析提供按场景裁剪的规则依据。

全屏打开 ↗

四、集成架构

智能信审系统作为独立系统接入门户，与信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心）、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台交互，共 12 个交互场景（场景 1–5 业务发起与审查、场景 6–9 出账与放款、场景 10–12 评价与门户），统一抽象为六种交互模式：

1. 后端部署与通信：智能信审系统与信贷系统后端独立部署、运行态隔离；系统间经 ESB 标准化通信（协议转换、消息路由、流量控制），信贷系统通过 ESB 传递业务上下文并发起任务调用。

2. 数据库（共库 · 双用户）：共库部署避免数据冗余与跨库同步，独立数据库用户遵循最小权限——智能信审用户仅被授予对信贷系统数据的只读查询权限；结构化数据由数据库查询工具按业务上下文经受控白名单 SQL 只读获取。

3. 前端集成与悬浮按钮：依托信贷门户微前端基座，以菜单直达、页面集成、悬浮入口（npm 包 + 微前端，查/审/核/问）三种形态对外赋能；门户统一身份认证、业务上下文透传与免登录。悬浮按钮按管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文与任务状态动态展示，唯一轮询器按"有任务 10s / 无任务 60s"拉取任务汇总；任务完成后经事件总线广播完成事件，订阅该事件的信贷业务功能完成页面回显或数据刷新，形成"AI 结果回流业务"闭环。

4. 触发方式与触发节点：

5. 场景与关键接口映射：

6. 数据获取通道：结构化数据经数据库查询工具从信贷库只读获取；非结构化数据经影像系统/文件传输平台接口获取文件流；外部系统数据经 ESB 实时接口交互；行业均值与政策法规经企业知识平台 ETL 同步后本地引用。

7. 结果输出边界与安全：审阅结果由智能信审前端承载展示，结果经事件通知与接口查询方式供给信贷侧，不写入信贷业务表；授信作业中心在页面跳转前完成权限校验，本系统在查看与下载时二次校验授权上下文，未授权访问、拼接 URL 与越权下载被拒绝并记录审计日志；业务打回后退回材料按不可删除标记控制；出账审核与放款审核任务相互独立、不得互相覆盖。

全屏打开 ↗

五、部署架构

私有化部署，智能信审系统与信贷系统后端独立部署实现运行态隔离；数据库共库部署、双用户权限隔离；应用服务双活站点多副本，全部服务经 Nacos 注册发现，支持灰度发布与流量治理。

• 业务服务域（双节点）：智能审查后端、知识库、问答助手、智能体运行。
• 基础服务域（双节点）：文档解析、异步任务、智能体评测、UAA 认证授权、OCA 权限管理；模型网关 Higress 部署于行方现有服务器，统一转发模型调用。
• 数据存储服务器：OceanBase 主从/集群 + 双活数据同步（RPO≈0）、Redis 主从+哨兵、RabbitMQ 镜像队列、Elasticsearch 检索与向量库、MinIO 多副本/纠删码、Nacos 多实例、ClickHouse（MPP 观测数据）；中间件均独立部署、不与其他系统共用。
• 算力服务器（5 台）：大模型推理独立部署、算力与业务分离；硬件二选一——阿里云 APC PPU1.5（海光 7490×2 · 8×M890P · 1152GB HBM）或华为鲲鹏 910C（Kunpeng 920×4 · 8×910C · 1024GB）；单点 GPU 故障由模型网关故障转移 + 多卡集群冗余承接。

全屏打开 ↗

六、数据架构

系统定位为面向信贷智能审查的 AI 数据中台，不承担业务主数据管理职责——贷款申请、客户、担保、额度等以「业务上下文」metadata 由上游传入，仅用于过滤检索与租户/业务隔离。

数据按主题域划分为七个领域：D0 业务上下文域（横切）、D1 文档文件域（入口/载体）、D2 财务报告域、D3 政策制度域（含内部与外部政策、政策条目、规则表达式、场景规则集、检查任务、风险明细）、D4 知识内容域（含历史案例库）、D5 对象术语域（含标准词库与三层同义词库）、D6 配置模型域；D1 为共同入口，D2/D3 为业务结果，D4/D5 为能力底座，D0/D6 横切全链路。

数据流转由四条主线构成：

1. 财报分析链路：财报 PDF → 解析 → 财报元数据与三大表 → 标准科目对齐 → 结构化输出；
2. 政策检查链路：内部政策与外部政策信息（自政策平台同步）→ 解析成条目 → 制度规则检查 → 风险结论；
3. 知识召回链路：原始文档 → 解析 → 父/子/孙三级切片 → 向量化索引 → 检索命中与问答；
4. 支撑链路：对象术语域与配置模型域贯穿三条业务链路，提供标准化与调度能力。

存储落位：OceanBase 存放元数据、状态、配置、政策/检查与问答历史；Elasticsearch 存放孙切片文本与 2560 维向量；MinIO 存放原文、解析产物、父/子切片与快照；Redis 承担任务队列、分布式锁与解析缓存；ClickHouse（MPP）存放观测数据。Elasticsearch、Redis、ClickHouse 等均独立部署。关键设计决策：领域优于模块、业务上下文外置、溯源贯穿（元素/页码/文件标识）、异步与幂等（任务队列 + 幂等键防重）。

全屏打开 ↗

七、关键非功能设计

7.1 性能与容量

性能保障措施（已定）：

• 长耗时任务（文档解析、财报提取、制度检查、报告生成）一律入队异步执行，前端以轮询（有任务 10s / 无任务 60s）感知状态，避免同步阻塞；
• 缓存分层：Redis 承担任务队列、分布式锁、解析缓存、上传记录，检索命中与热点向量结果可缓存；
• 检索加速：向量检索（ES）+ BM25 并行召回 + Rerank 精排，父/子/孙三级切片控制单条向量维度与检索规模，top_k 与阈值按知识库粒度可配；
• 网关限流与熔断：API 网关对请求限流/熔断；模型网关（Higress）对模型调用限流、配额、负载均衡与故障转移；
• 解析并发：大 PDF 拆分并发解析后拼接，MinerU 与本地解析器双引擎按类型分流。

容量测算模型【待测算】：

7.2 可用性与容灾

高可用措施（已定）：应用服务多副本部署经 Nacos 注册发现与故障剔除；算力与业务分离，GPU 故障由模型网关故障转移 + 多卡集群冗余承接；中间件高可用——OceanBase 主从/集群 + 双活数据同步（RPO≈0）、Redis 主从+哨兵、ES 集群多副本、RabbitMQ 镜像队列、MinIO 多副本/纠删码；Nginx/API 网关/Nacos/模型网关多实例消除单点。

可用性指标【待定版】：

备份与数据留存：

• OceanBase 定期备份与恢复演练【周期待定版】；MinIO 对象版本化保留历史版本；
• 知识库可重建性：向量索引与切片可从 MinIO 原始文件全量重建——原始文件在则 RAG 底座可恢复，此为知识库最重要的容灾特性；
• 数据留存周期【待定版】：任务日志 / 对话记录 / 评价记录 / 审计日志分别明确留存时长。

7.3 降级矩阵

按依赖逐项明确"不可用时系统行为"，将需求中的分散降级描述（ESB 失败分区降级、预审失败保留已完成结果、影像拉取失败可重试）统一为矩阵：

7.4 数据安全与脱敏

已定措施：复用信贷门户 SSO；全链路审计留痕（登录、数据访问、AI 调用、模型调用、结果输出、评价记录）；模型网关密钥集中托管加密存储；模型输入统一管控防提示注入与越权数据外发；私有化算力不出内网。

待补充项：

• 数据分级与进 prompt/向量库的边界【待定版】：明确哪些客户字段可进入 prompt 上下文、哪些进入向量库，形成数据分级清单；
• 双向敏感信息过滤：输入侧（用户提问中的敏感数据）与输出侧（模型生成内容进前端前）内容安全过滤策略【过滤规则与词库待定版】；
• 向量数据删除机制：客户行使删除权或业务作废（再议）时，切片与向量的级联删除规则【待定版】；
• 界面脱敏承接：上传人员"张**“式脱敏显示（需求已有）由前端统一组件承接。

7.5 AI 质量与模型风险管理

• 质量指标目标【待定版】：

• 幻觉控制：答案强制携带溯源（文档名/页码/高亮，已具备）；无依据拒答策略【待定版】；数值类输出必须引用计算层结构化结果，禁止模型自行计算财务指标；
• 模型变更管控：模型与 Prompt 版本变更需通过 DeepEval 评测门禁后灰度发布；线上 badcase 定期回流评测集，评测集随版本累积；
• 双环质量保障：线上用户评价（评价闭环）+ 离线评测集（DeepEval）互为验证，周期性对齐。

7.6 审计与合规

• 审计日志防篡改与保存期限【待定版，等保要求 ≥ 6 个月，行内口径从其规定】；
• 人工确认留痕：谁在何时对 AI 结论执行了确认/修改/忽略（含忽略原因），作为责任界定依据——与"历史执行日志保留用于审计"的需求对齐；
• 生成内容合规：输出内容审核策略与拦截记录留存【待定版】；
• 模型调用记录（Higress 请求日志）含 prompt 摘要、token 数、耗时、模型版本，留存期限【待定版】。

7.7 成本与配额管理

• 启用 Higress 配额与成本追踪：按应用（小查/小核/小问/报告生成）设置 token 预算与超限行为（限流/告警）【阈值待定版】；
• 关注多层 Agent 的 token 放大效应（主+子 Agent 可达普通调用的数倍），子 Agent 数量与单任务轮次上限【待定版】；
• 月度成本核算口径：按应用、按机构维度的 token 成本报表【口径待定版】。

7.8 可观测性 SLO

• Trace 采样策略：正常请求采样 10%~20%，错误与慢调用（阈值【待定版】）全量保留；
• LLM 专项监控：模型调用延迟 P95、tokens/s、成功率、每任务 token 消耗，经 OTel GenAI/OpenInference 语义约定采集；
• 告警分级与响应时限【待定版】：P0（服务不可用）/ P1（队列积压超阈值）/ P2（指标劣化）对应的响应 SLA；
• 看板：任务运行看板（队列深度、成功率、时长分布）+ 模型服务看板（GPU 水位、推理延迟）+ 质量看板（误报率趋势、评价分布）。

7.9 发布与配置运维

• 灰度发布：按机构/角色灰度（承接需求"试用"机制——按用户/角色/机构灰度开放、收集反馈后正式上线）；
• Prompt 资产管理：承接需求的三级提示词配置（模板/节点/全局）、占位符校验、发起时快照机制；Prompt 版本库支持回放与回滚；
• 配置回滚：目录版本回滚（需求已有）、审核规则配置即时生效与停用、场景规则集版本化推送（一致性检查通过后生效）统一纳入配置管理策略；
• 发布流程：应用发布与知识库/规则集更新解耦，互不影响线上任务。

八、方案小结

方案以"场景层 → 智能应用层 → 能力支撑层 → 评价闭环"承接业务，以四层技术栈与 LangGraph/DeepAgents/Higress/OTel/DeepEval 的 AI 专项栈支撑实现，以主题域化数据架构与"ESB + 微前端 + 共库只读"的集成模式约束边界，最终形成可观测、可评测、可迭代的信贷智能审查 AI 能力体系；部署上算力与业务分离、关键组件多实例，非功能设计按九节展开（性能与容量、可用性与容灾、降级矩阵、数据安全与脱敏、AI 质量与模型风险、审计与合规、成本与配额、可观测性 SLO、发布与配置运维），其中【待定版】/【待测算】条目随评审逐块定版。

7.1.3 - 智能信审平台需求文档

依据《信贷项目-智能信审平台-911》需求规格说明书与《信贷项目-智能信审系统对外交互方案-911》编制（第 10 章依据《财务风险分析系统需求文档 1028》补充），与智能信审平台业务架构概览页互补：概览页讲"是什么"，本分册按模块讲"要做成什么样"。

• 01 总体概述：项目背景、建设原则与业务目标、术语定义、系统边界与功能清单总览
• 02 业务架构与端到端流程：三层功能架构、授信审查与放款出账两条主线、统一任务模型与公共机制
• 03 悬浮按钮与任务管理：FAB 统一入口、点击触发规则、风险提醒、悬浮按钮配置、运行列表与运行管理配置
• 04 风险检查（小查）：触发方式、三个子模块、风险结果页与风险分析配置
• 05 类案对比（小审）：相似案例检索与对比分析、业务资料自动入库与三组配置
• 06 审查报告：自动生成流程、模板与批复条件配置、智能报告详情工作台
• 07 智能审核（小核）：目录同步与确认、分类与审核规则配置、材料上传与审查、小核配置
• 08 评价分析：评价查询、效果评价分析、未评价提醒与评价设置
• 09 对外交互方案：六种交互模式、十二个场景、38 项接口清单与放款智能审核接口契约
• 10 财务风险分析：财报风险分析系统（1028）——独立上传与对接信贷两种使用方式、财报上传与解析、972 条规则体系与四层筛选、十个风险域、议题聚合与三轴评分、八条一票否决、大模型判读与结论文案、统一发起接口与信贷系统集成

7.1.3.1 - 总体概述

1. 项目背景与系统定位

智能信审系统（即智能审查系统，下称"智能信审平台"或"本系统"）是智慧信贷二期项目 AI 能力建设的载体。门户以微前端形式集成信贷系统与智能信审平台两个平级子应用：智能信审的业务入口（悬浮按钮、页面跳转、iframe 嵌入）直接嵌入信贷系统作业页面，前端交互发生在两个微前端子应用之间；后端通过 ESB 与信贷系统各业务中心集成。信贷系统承载授信、审查、放款等业务流程。

外围交互系统包括：信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、门户、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台。详见 09 对外交互方案。

2. 建设原则与业务目标

本期建设以"科技赋能业务、辅助不替代、增强不决策“为核心原则：将 AI 能力嵌入审查、审批、放款与知识查询等高频信贷作业环节，在保留人工确认与复核的前提下实现风险识别与合规校验关口前移、文书撰写提效、知识即问即答。

3. 术语定义

4. 系统边界

• 会计核算：不适用，本需求与核算无关。
• 上报要求（金融监督管理总局/人民银行/其他）：本平台仅提供操作建议与预警，不适用。
• 经营分析/报表需求：不适用。
• 业务材料上传边界：本系统仅承接"放款申请资料上传"“出账申请资料上传"两个场景，授信执行中心不自建上传功能；其他业务资料上传不属于本系统范围。
• 审查报告查看权限：由授信作业中心统一判定，暂定仅总行审查人员、总行审批人员可查看。

5. 功能清单总览（二级功能 → 三级功能）

内部工具说明：运行数据测试控制台、审查报告调用为本项目内部模拟/联调页面，不向业务用户开放，不参与对外交互。

6. 本章关联文档

• 业务功能架构与端到端流程：02 业务架构与端到端流程
• 图表：业务功能架构（全屏 ↗）、系统交互全景（全屏 ↗）

7.1.3.2 - 业务架构与端到端流程

1. 业务功能架构

本系统由"底层能力 + 应用功能 + 评价闭环“三层构成，各模块以"制度 + 案例 + 知识"底座为支撑，覆盖审查、审批、放款与知识查询全流程。

全屏打开 ↗

业务操作本身较少，流程的核心是各能力模块之间的支撑关系：风险检查由信贷系统在授信申请提交后自动发起并可经悬浮按钮补充发起；类案对比与智能问答经悬浮按钮触达；智能审核（小核）在非放款审核场景可按配置发起，放款/出账审核场景仅重新检查和查看已有任务；审查意见生成与放款/出账审核由信贷系统在客户经理提交业务后自动发起；各功能产生的用户评价汇入效果评价分析，形成闭环。

2. 端到端业务主线

2.1 授信审查主线（业务发起 → 材料入库）

全屏打开 ↗

1. 业务提交：客户经理在授信作业中心提交授信申请成功后，授信作业中心调用”小查与审查意见生成统一发起接口"（同时保留小查自动发起、审查意见生成自动发起两个兼容接口），传入业务流水号、提交批次/版本、客户及流程上下文。
2. 统一受理：智能信审系统按业务流水号查询调查报告系统文件索引，从影像平台拉取该业务最新正式版调查报告 PDF 本地暂存（暂不向量化）；先统一执行一次财务分析与制度分析（财务要素、企查查、行业均值、政策法规等数据支撑只发生一次），再分别创建小查风险检查与审查意见生成任务，两任务复用同一次分析结果。
3. 智能分析：小查输出结构化风险检查结果；审查报告按模板章节、运行批次异步生成，经 SSE 流式推送。
4. 审查审批：审查人员在信贷系统审查审批页面经悬浮按钮或页面跳转进入，查看/编辑报告、核对风险事实、使用溯源与 AI 改写。
5. 终审与入库：终审结论区分处理——通过：批复生成后，审查意见 + 批复 PDF 存影像平台，统一打标编码写入文件名，调用入库通知接口；拒绝：仅审查意见入库（无批复），打标标记审批结论=拒绝；再议：流程废弃，不通知、不入库。智能信审系统拉取材料后，将调查报告、审查意见、批复三套材料统一向量化、生成业务级摘要与统一打标，写入 RAG 知识底座，供类案对比与小问使用。
6. 打回重提：业务被打回后重新提交时，授信作业中心再次调用统一发起接口，系统重新拉取最新调查报告、重新统一分析并再次执行；新结果覆盖当前有效结果，历史执行日志保留用于审计。

2.2 出账与放款主线（资料上传 → 智能审核）

全屏打开 ↗

1. 上传入口：客户经理在授信执行中心放款/出账业务页面点击"资料上传"（唯一入口，不提供悬浮按钮入口），经页面跳转进入本系统材料上传页面，URL 携带业务流水号、客户信息、上传场景编码与不可删除标记列表。
2. 上传任务：系统按"业务流水号 + 上传场景"创建或加载资料上传任务，快照当前生效目录版本；客户经理按目录上传材料（非末级目录自动分类，无法确认进"未分类"），可复用历史材料（信贷系统物理复制）、对停用材料执行"失效"。
3. 一键预审：异步执行审核规则（规则 + 大模型），前端轮询进度；材料变化会使预审结果失效；未变化的规则沿用上次有效结果。
4. 提交上传任务：校验目录版本、处理中/解析失败/未分类材料、必传材料与风险项，通过后冻结当前目录版本。上传任务提交不触发审核。
5. 业务提交：客户经理返回授信执行中心正式提交放款申请（loanReleaseApply）或出账申请（paymentManage）后，授信执行中心自动调用"放款智能审核接口“发起对应场景审核。
6. 智能审核：智能信审系统按"业务流水号 + 审核场景"幂等执行材料智能审核与制度风险分析（制度检查范围按功能编码映射的制度集合确定），返回材料风险、制度风险与合并风险等级（取高）；打回重提重新发起并覆盖本场景当前有效结果；放款审核与出账审核相互独立。
7. 审查岗复核：放款/出账审查岗在"业务材料审查"工作台以"问题审查（问题队列 + 证据原文 + 问题详情）/全部材料"两种视图复核，任务支持"材料审核 N / 制度审核 M"分段切换。

全屏打开 ↗

2.3 主数据与门户

前端层面，门户统一承载信贷系统与智能信审两个微前端子应用，两个子应用之间直接完成缓存读写、页面跳转与页面嵌入（不走 ESB）；门户与智能信审之间仅保留系统级对接（主数据同步、知识库菜单集成）。机构、用户、角色及关系数据以门户为准：门户经 ESB 实时发送"门户主数据变更通知”（五大项：机构、用户、角色、机构-用户关系、用户-角色关系；菜单不再同步），企业知识平台做表级批量同步兜底。知识库功能通过门户菜单直接集成（场景 12）。

3. 统一任务模型

各智能体任务（小查/小审/小核/审查报告）共用一套任务运行机制：

3.1 触发模式与唯一性

• 每个任务类型维护任务唯一性标识（无/客户号/批复编号/业务流水号）与是否可重复发起：允许重复且有唯一标识的任务，重复发起将覆盖原任务（原任务执行中则自动终止并重新执行）；禁止重复时按入口语义拒绝或回退手工入口。
• 放款审核、出账审核不允许经悬浮按钮创建或重复发起，仅接收信贷系统回调创建的任务；小查信贷模式任务由授信作业中心调用统一发起接口创建，不经悬浮按钮提交接口。

3.2 任务状态与轮询

• 任务状态在**运行中 → 部分完成 → 已完成（成功/失败）**间流转；小核只允许运行中、已完成两种状态，不产生部分完成。
• 状态非实时推送：悬浮按钮使用唯一轮询器（有运行中任务默认 10 秒、空闲默认 60 秒，均可配置；失败指数退避，标签页恢复可见立即补拉），已完成未读数增加时弹出一次汇总通知。
• 首次拉取仅建立未读基线不弹窗；3 秒时间窗内多个任务完成只弹一次汇总通知。

3.3 评价机制

• 任务式功能按任务（小查按可评价子模块分项）评价；对话式功能（小问）按 AI 回答逐条评价——会话中存在任一未评价回答即视为整任务未评价。
• 评价要素：评分（0–100）、评价等级（按分数自动命中）、反馈原因（多选）、补充说明（≤200 字符）、截图。详见 08 评价分析。

4. 公共机制约定

• 统一字典机制：业务页面下拉选项（类型、检索方式、企业性质、行业三级、贷款用途、产品、担保方式、风险等级 FAB_RISK_LEVEL、评价等级等）均通过统一字典加载，禁止写死静态字典数组。
• 数据权限：任务数据按业务权限与用户可见范围隔离，用户仅可见本人经办、审查或授权范围内的任务；信贷模式任务发起方记录为授信作业中心/授信执行中心。
• 软删除与引用保护：各类配置记录删除均为逻辑删除；被规则、任务、流程引用的对象禁止删除。
• 版本快照：任务启动时冻结配置快照（模板、批复条件、目录版本、提示词等），后续配置变化仅影响新任务；业务重新提交时覆盖"当前有效结果"、保留历史执行日志。
• 上传人员脱敏：列表中上传人员脱敏显示（如张**）。

5. 本章关联文档

• 上一章：01 总体概述
• 入口与任务管理细节：03 悬浮按钮与任务管理
• 对外交互：09 对外交互方案

7.1.3.3 - 悬浮按钮与任务管理

1. 悬浮按钮（FAB）

1.1 功能概述

悬浮按钮（AI 悬浮按钮）是各智能体在信贷系统作业页面上的统一入口，常驻页面右侧。系统根据管理员功能配置、用户逐功能显示偏好、当前末级功能、页面业务上下文以及任务状态，动态展示小查、小审、小核、小问。

• 两层入口语义：折叠态彩色圆形主按钮是"查看已有结果或发起新任务"的复合入口；悬停展开后的自动、手工、运行中和完成徽标均为含义确定的单项入口。
• 圆形主按钮仅对任务类功能执行可排序的点击触发规则；小问直接打开对话。
• 小查的"自动发起/手工发起"均由审查人员发起，作为补充入口；主场景为授信申请提交后由授信作业中心调用统一发起接口自动创建（信贷模式）。放款/出账审核不适用"智能审核"发起操作，其任务由信贷系统提交业务后自动创建，悬浮按钮仅展示运行中和完成结果入口。
• 任务类功能展开后展示运行中数量、已完成未读数量、自动操作和可用的手工操作；不展示部分完成数量或绿点（小核任务不使用部分完成状态）。
• 智能体渲染顺序固定（任务类在前、问答类置底）。

1.2 操作权限

悬浮按钮不承载数据维护权限，所有任务的发起与查看均复用信贷系统的单点登录身份与功能权限。

1.3 显示规则（优先级从高到低）

1. 管理员禁用 → 不展示；
2. 用户"整体隐藏" → 隐藏整个悬浮按钮（保留右侧窄触发条用于恢复）；
3. 用户"始终隐藏" → 隐藏该功能（逐功能隐藏只影响入口，不停止后台轮询和通知）；
4. 用户"始终启用" → 强制展示（不绕过自动任务上下文校验）；
5. “自动显示”：管理员始终显示、存在运行中/已完成未读任务、或当前末级功能命中绑定且上下文满足，任一成立即展示。

1.4 圆形主按钮点击触发规则（可配置顺序，只执行第一条命中）

规则要点：

• “提交自动任务"是复合分支；取消确认后本次点击结束，不执行后续规则。
• 展开后的"自动"按钮只执行自动任务，所有分支均不得切换为手工；“手工"按钮只打开手工入口。
• 配置读取时对规则顺序做规范化：忽略未知项和重复项，按默认顺序补齐缺失规则。
• 展开后的单项按钮不受点击规则顺序影响；“运行中/完成"徽标仅在数量 >0 时显示，点击进入相应筛选后的运行列表。

1.5 风险提醒（仅小查、小核）

• 功能已启用风险提醒且存在未读的已完成任务时，圆点右上角显示风险等级角标（高/中/低/疑，经 FAB_RISK_LEVEL 字典加载），圆点与完成徽标颜色随最高风险等级变化；高风险时圆点字符在"功能字"与"风险字"间交替闪烁。
• 放款/出账审核任务的风险等级按"材料+制度统一考虑"合并：取材料智能审核风险与制度风险分析中的更高者；仅制度发现高风险时该笔业务同样按高风险驱动；均无风险时不驱动。
• 风险提醒只增强视觉提示，不改变点击规则；用户"始终隐藏"仍具最高优先级；管理员可按功能启停并自定义各级颜色（6 位 HEX，统一转大写）。

1.6 界面与关键规则

界面 1：悬浮按钮（折叠/展开）

• 折叠态：每个智能体显示单字标识（查/审/核/问）；运行中任务→脉冲动效；已完成未读→右上角红点。
• 展开态：显示"别名 + 功能说明”，右侧操作区——小查：运行中、完成、自动发起、手工发起；小审：运行中、完成、自动查找、手工查找；小核：运行中、完成（非放款审核场景可按配置展示"智能审核”，放款审核场景不展示发起按钮，无手工入口）；小问：仅"打开对话”。
• 自动按钮不满足当前业务页面或上下文时显示禁用样式，点击给出明确提示。
• 后端接口：配置接口（功能定义 + 末级绑定规则）、汇总接口（按智能体聚合运行中数/已完成未读数/失败数 + 最高未读风险等级，带版本号或变更时间）、自动提交接口（校验页面上下文、权限和唯一性；放款审核禁止经此发起）、已读标记接口、用户偏好接口。

界面 2：AI 助手设置对话框（鼠标悬停约 1 秒浮现设置齿轮）

• 整体隐藏悬浮按钮（开关，默认关；开启后仅保留约 6×48 像素半透明触发条）；
• 各功能显示方式（仅列管理员已启用功能，单选：自动显示/始终启用/始终隐藏，默认自动显示）；
• 纵向位置距底部滑块（最小 24px，默认 88px，上限随视口动态计算，区间内夹取）；
• 底部：恢复默认 / 取消 / 保存（乐观更新，失败回滚并仅控制台告警）。偏好按当前登录用户维度保存在服务端，合并优先级：用户值 > 管理员默认值 > 前端兜底常量；历史"显示全部已启用功能"偏好不迁移、不参与判断。

界面 3：任务完成提醒弹窗——轮询感知已完成未读增量后弹出系统通知"智能分析：有 N 个任务已完成"（成功类型，4 秒自动关闭），同步刷新角标并经事件总线广播。

界面 4：小查手工发起弹窗——标题"小查 · 手工发起"（860px，遮罩不可关闭）：查询条件区（客户号/客户名称/业务流水号，模糊匹配，至少输入一项）；调查报告单选列表（报告编号、客户号、客户名称、业务流水号、报告标题、业务功能、报告日期）；子模块选择区（禁用模块灰色显示"建设中"）。“开始检查"校验：必选一条调查报告 + 至少一个子模块；成功后仅提示"已经发起”，不自动跳转。

界面 5：小审检索配置弹窗——标题"类似案例对比 - 检索配置"（1200px），亦为类案对比列表页"新增"所复用：

• 检索方式（字典 CC_SEARCH_MODE）联动三区显示：精确条件筛选加语义检索 / 语义检索 / 仅精确条件检索；隐藏区域不参与必填校验、已填内容保留。
• 基础信息：类别、检索方式、是否数据抽取、是否项目贷款（CC_LOAN_TYPE，必选默认非项目贷款，项目/非项目不允许混用）、是否比对分析（选"是"时显示对比业务——经业务查找弹窗回填业务流水号、业务名称、客户名称、客户号；个人业务另显示产品种类）。
• 精确条件区：类型（可清空单选，与基础区联动）、企业性质、企业规模、经营年限范围、所属行业三级级联（大类→中类→小类按编码前缀过滤并清空）、贷款用途、产品（命中任意一个即匹配；“授信"匹配无产品业务）、主担保类型、所属分行、审批通过时间范围。
• 近似关键词区：关键词（逗号分隔）+ 最大数量（1–50）。
• 差异化必填校验 + 年限/日期区间合法性校验；通过后提示"检索请求已受理"并广播任务创建事件。

界面 6：小问对话面板——参看知识库部分。现状为简化浮层对话面板（单会话、会话仅内存、刷新后清空、不支持深链定位会话），完整版将参考 A 项目重构后回填。

2. 悬浮按钮配置

面向系统管理员，管理功能启停、末级功能绑定、上下文要求、管理员始终显示、圆形主按钮点击规则顺序及轮询参数；对所有用户统一生效（个人显示偏好在"AI 助手设置"维护）。

页面六区域：功能管理（别名/说明/类型/槽位 1-6/启用开关）、末级功能绑定（管理员始终显示、上下文要求[无/客户号/批复编号/业务流水号]、绑定末级功能多选；开启始终显示时绑定选择禁用并清空）、角色功能路由（小核任务按角色路由到业务功能页面的映射及进入方式[仅查看/正常]；业务材料上传/审查默认"仅查看”；无匹配路由跳转通用运行详情；目标路由与进入方式均为服务端配置项，程序不写死）、点击触发配置（5 条规则拖拽排序）、风险提醒配置（小查/小核启停 + 高/中/低/疑四级颜色，全功能统一，实时预览）、轮询与行为（轮询间隔 3–120 秒默认 10；空闲间隔 30–300 秒默认 60；标签页隐藏暂停轮询默认开）。

小查的末级功能绑定即为小查功能覆盖范围的唯一事实源；风险分析配置不再维护子模块级功能绑定，小查触发后在其覆盖范围内统一运行所有启用子模块。

3. 智能体运行列表

展示当前用户可见的各智能体分析任务记录；悬浮按钮"已完成"区域点击后跳转至本列表并按来源智能体预过滤。

• 主流程：进入运行列表（支持按功能、模式、状态、结果、风险等级、已读、评价状态筛选与分页）→ 点击任务标题/“查看”→（未读先调标记已读接口并刷新角标）→ 运行详情 → 返回列表（保留筛选与分页位置）。
• 详情页路由：审查报告 → 报告详情页；小审 → 类似案例对比详情页；其他 → 通用运行详情页。
• 运行详情页：顶部任务基础信息（只读，双列）；分析结果区按功能差异化渲染（小查渲染结构化风险检查结果组件；其他功能暂为占位）；结果评价区（小查按可评价子模块分项，其他按整任务单面板；评分 0–100、等级自动命中、反馈原因多选、补充说明 ≤200 字符、截图；已有评价回显）。
• 数据权限：按当前登录用户与业务权限过滤；自动/手动任务按提交人关联，信贷任务按业务经办、审查或授权范围关联。

4. 运行管理配置

面向系统管理员，集中管理各任务类型运行策略（与悬浮按钮配置互补：后者管"显示什么、何时显示"，本配置管"怎么执行、能否重复、何时超时"）。

列表操作：新增/编辑（弹窗 560px，确定带加载态防重）/删除；保存时后端校验名称唯一、枚举合法与数值区间。

5. 本章关联文档

• 任务状态与覆盖规则详见：02 业务架构与端到端流程 第 3 节
• 下一章：04 风险检查（小查）

7.1.3.4 - 风险检查（小查）

1. 风险审查（小查）

1.1 功能概述

风险审查（小查）是智能信审系统的风险检查智能体，可由信贷系统在授信申请提交后自动发起（主入口），也可由信贷作业用户通过悬浮按钮自动或手工补充发起，输出结构化风险检查结果供用户参考。

• 适用范围：支持全部业务类型（对公、个人等），不同业务的数据完整性不同；当业务无可用数据支撑时，不执行分析，结果页提示"无数据支撑"（dataSupported=false，子模块数组为空，任务置为已完成/成功）。
• 子模块（按风险分析配置启停；功能覆盖范围以悬浮按钮配置的末级功能绑定为准）：
  1. 制度合规检查：按制度规则核查业务材料合规性，输出风险等级与整改建议；
  2. 调查报告专项分析：按 7 项专项分析调查报告风险——主营业务识别、关联交易、客户集中度、授信匹配、资产结构、利润结构、现金流量，另含自由风险识别；
  3. 财务分析：建设中（占位状态）；所需企查查数据经外部数据管理平台获取（对外交互方案场景 1）。
• 输入材料：调查报告文档（PDF），不使用结构化数据；自动与手工发起均以调查报告为分析对象。

1.2 操作权限

1.3 业务处理流程

1. 信贷自动发起（主场景）：授信申请提交成功后，授信作业中心调用统一发起接口（同时发起小查与审查意见生成），传入业务流水号、提交批次/版本、客户及流程上下文。智能信审系统校验上下文和唯一性后创建任务（状态=运行中，模式=信贷），按业务流水号查询调查报告系统文件索引，获取最新正式版调查报告的文件名与影像位置，从影像平台拉取 PDF 并在本系统对象存储暂存，随后按启用的子模块异步执行风险检查。
2. 悬浮按钮自动发起：读取前端缓存的业务流水号等上下文提交；已有任务时按运行管理配置处理（允许重复→确认后重发并覆盖；禁止→拒绝）。
3. 手工发起：悬浮按钮"手工发起"弹窗，按客户号/客户名称/业务流水号组合查询调查报告（至少一项），单选一条后选择参与检查的子模块（禁用模块不可选，默认全选已启用），提交后任务标记手工模式，提示"已经发起"。
4. 异步分析：先判断业务数据可用性（无数据支撑→直接完成并携带标记）；部分字段缺失按"该维度数据缺失"处理；部分子模块完成→“部分完成”，全部完成→“已完成（成功/失败）"。状态经悬浮按钮轮询感知。
5. 结果查看与评价：经悬浮按钮"已完成"或运行列表进入运行详情页；按可评价子模块分项评价（复用运行列表评价机制）。
6. 打回重提：业务被打回重新提交时再次调用统一发起接口，按"业务流水号 + 小查场景"重新执行，新结果覆盖原当前有效结果，历史执行日志保留用于审计。

1.4 界面：小查风险检查结果（运行详情页）

• 无数据支撑提示：结果携带 dataSupported=false 时，不展示风险概览与模块面板，展示"无数据支撑"提示语及说明。
• 风险概览面板：统计栏展示风险项合计与各等级计数（高风险红、中风险橙、低风险蓝、存疑紫、合规绿）；支持按模块多选与按风险等级多选筛选。
• 各模块面板（可折叠）：制度合规检查、调查报告专项分析展示风险条目列表；财务分析显示"建设中"占位。
• 风险条目卡片：左边框按等级着色；展示风险等级标签、专项名称、风险标题、风险描述、整改建议、溯源原文（可折叠：来源类别[制度/业务类别]、文档名称、路径、原文片段）。
• 分析总结条目不计入风险统计，作为模块底部总结性描述。

后端要点：统一发起接口返回任务编号与受理状态；调查报告不存在、不可访问、格式错误或版本不一致时任务置为失败并保留错误原因，按运行管理配置重试；任务详情接口返回子模块数组（编码、名称、启用/占位标记、风险条目列表、统计信息）及数据支撑标记；风险条目结构含等级（高/中/低/存疑/合规/总结）、专项名称、标题、描述、整改建议、溯源证据数组。

2. 风险分析配置

面向评价分析管理员/系统管理员，管理小查子模块启停与调查报告专项分析参数。

• 参数范围：子模块启停（制度合规检查/调查报告专项分析/财务分析）；调查报告专项分析的系统提示词（所有专项共享）、检查项目（可增删、启停、编辑名称/必查点/提示词；必查点以中文顿号”、“分隔保存为数组）、自由检查（是否开启自由风险识别及其提示词；关闭时提示词框禁用）。
• 边界约定：本页仅维护子模块启停，不再维护子模块×末级功能绑定（小查功能覆盖范围以悬浮按钮配置为准）。
• 界面：四个区域（子模块管理 / 系统提示词 / 检查项目 / 自由检查）+ 右上角"保存风险分析配置”。
• 后端：配置读取/保存接口（合并写入返回完整配置）；统一发起接口按启用的子模块创建运行中的小查任务。

3. 本章关联文档

• 触发与任务状态公共机制：03 悬浮按钮与任务管理、02 业务架构与端到端流程
• 调查报告获取与数据支撑交互：09 对外交互方案 场景 1
• 制度合规检查的制度规则来源：制度拆解（底层能力，见 02 章）
• 下一章：05 类案对比（小审）

7.1.3.5 - 类案对比（小审）

1. 类案对比

1.1 功能概述

类案对比面向信贷作业用户与智能信审系统，对当前在办业务从历史相似案例库中检索、抽取、对比并形成结论，为审查决策提供横向参照与可解释依据。分析结果仅供人工审查辅助，不触发自动审批。

• 案例抽取范围：抽取维度是审批流程结束的结论，即调查报告、审查报告、批复的材料组合；审批结果包括通过、拒绝、再议——通过、拒绝业务入库并纳入抽取范围，仅再议业务不入库；不抽取对比客户自身的业务。
• 抽取数据范围：近五年数据（需连续一致），时间自系统上线起回推。
• 贷款类型：任务贷款类型统一为项目贷款/非项目贷款两类，不允许混用。手工创建必选；自动查找按"固定资产贷款产品名单"自动判定（对公命中名单=项目贷款、未命中=非项目贷款；个人默认非项目贷款）。任务首次抽取记录"首次抽取类型"（=任务贷款类型）；重新抽取固定使用任务贷款类型、不可更改，且不更新首次抽取类型。
• 分析材料：调查报告、审查意见、批复三套文档材料（向量化存入 RAG 知识底座）+ 贷后五级分类数据（经接口从企业知识平台实时获取，不入库）。
• 运行模式：模式一，新增类似案例对比任务（三入口：悬浮按钮手工发起 / 悬浮按钮以当前业务自动发起 / 结果页"新增"）；模式二，在已有任务数据中再次发起数据抽取或类似案例分析。

1.2 操作权限

1.3 业务处理流程

1. 列表页经统一字典加载下拉项，按"首次抽取类型"“发起方式"等列展示，支持按类别、首次抽取类型、状态、结果筛选（提交时间倒序）。
2. “新增"弹出检索配置弹窗（见 03 章 界面 5），提交后创建任务并记录首次抽取类型与发起方式，经 ESB 调用信贷系统查询业务基本信息并启动相似案例检索。
3. 任务期间轮询任务状态，经影像平台拉取该业务对应的调查报告、审查意见和批复三套材料 PDF 向量化处理，并实时获取贷后五级分类数据。
4. 详情页五个页签：类似案例列表 / 对比业务关键要素 / 类似案例数据抽取 / 业务对比分析 / 运行情况与反馈。
5. 对比业务关键要素：自动任务回显信贷数据并标记字段来源；手工任务初始为空（无"对比原业务"卡片）。表单按行业（三级级联）、企业经营、财务表现、申请方案与担保分区；担保方式为抵押时抵押率显示并必填。校验：经营年限 ≥0、敞口与期限 >0、抵押率 0–100。修改值只作用于当前任务、不回写信贷系统。
6. 重新抽取数据：需至少选中一个案例；确认"将重新生成 N 个业务的数据统计，会覆盖当前数据"后按任务贷款类型执行，抽取期间页签显示"数据抽取中"并提供刷新。
7. 重新进行对比分析：先保存并校验关键要素（不完整→跳转要素页签提示缺失项；后端错误码 CC_BUSINESS_INCOMPLETE 同样处理，不覆盖既有结果）；确认覆盖后重算。
8. 类似案例数据抽取页签：上区非项目贷款、下区项目贷款两区动态列表格（列由后端抽取列定义动态渲染；单类型任务仅对应区域有数据）；空值按字段适用性显示"无法确认"或"不适用”；支持按类型导出 Excel（含期次、证据状态和来源证据明细，供审计复核）。
9. 业务对比分析页签：见 1.4。
10. 运行情况与反馈页签：复用审查报告详情的运行反馈组件（基础信息 + 运行情况 + 结果评价）。

异常处理要点：创建/查询/详情/重抽/重算失败均以消息提示后端错误并保留现状；所选案例为空警告"请至少选择一个案例”；大模型分析进行中展示骨架占位与"大模型正在分析中，请刷新"；规则结论与模型结论方向或建议额度不一致时并列展示并提示以人工复核为准。

1.4 业务对比分析页签

• 对比概览卡：参与对比案例数、通过/未通过案例数、平均相似度、高度相似贷后良好率、分析时间。
• 数据对比图形区：相似度雷达图、额度对比、产品构成、担保结构（按担保类型字典聚合，半栏）、财务指标、贷后五级分类分布（半栏）六类图形 + 对比明细表（客户名称、相似度、审批结果、五级分类、申请敞口、批复敞口、担保方式、未通过原因）。
• 量化证据校验（规则分析结论）：结论标签三档——建议通过（绿）/建议谨慎通过并加强风控（黄）/建议审慎，暂不通过（红）；统计指标（对比贷款数、高度相似贷款数、高度相似通过率、建议敞口额度及计算依据）；判定依据列表；触发未通过案例相似度红线时错误告警。有效样本口径：仅同行业且数据覆盖率达标的案例进入有效样本统计，跨行业及行业无法确认案例只展示。
• 辅助审查建议（大模型分析结论）：两阶段执行——第一阶段单案摘要（逐案例基于三套向量化材料与贷后五级分类数据提炼关键证据），第二阶段综合建议；阶段横幅实时展示进度。产出含：建议标签与置信度、可核验的分析思路（每步含事实证据/专业判断/结论影响，四色标识）、关键证据权衡（支持/制约因素 + 决定性判断）、综合判断理由、建议敞口额度与期限、建议风控措施、相似点与差异点、数据局限与待核实事项。

1.5 关联配置

• 摘要与自动查找设置（系统管理员）：按对公/个人分别维护业务摘要提示词、自动检索提示词（均必填）；自动查找配置（是否数据抽取、是否比对分析、最大输出数量 1–100 默认 10）；“项目贷款判定配置（固定资产贷款产品）“经产品字典（CC_PRODUCT）多选维护，可恢复默认。配置保存后仅对后续新任务生效。旧接口仅返回通用提示词时，前端兼容映射到对公配置。
• 类案抽取配置（系统管理员维护公共配置，审批人员可个性化）：按客户类型（对公/个人）分入口，含四页签——行业映射配置、产品映射配置、项目贷款字段配置、非项目贷款字段配置。字段配置含字段编码、名称、值类型、统一单位、期次口径、启用状态、证据要求（“必须返回来源证据”）和提示词；停用字段不进入新任务抽取列。删除行业/产品映射时级联删除对应抽取字段配置与已选关联。一笔业务涉及多行业/产品时抽取列取并集，各案例只填充自身适用字段。个性化配置按作用域标识区分，审批人员可将本人配置按客户类型还原为公共配置快照（不还原行业分类与产品分类基础数据）。
• 业务对比分析配置（系统管理员）：
  • 固定口径只读：综合相似度按维度及维度内字段权重计算；行业层级——同小类 100 分、同中类/同大类分值可配置、跨大类 0 分；覆盖率按实际可用权重披露，缺失字段不以零分代替；结果字段隔离。
  • 相似度权重与行业分值：行业匹配/企业经营/财务情况/申请方案与担保四维权重（各 0–100，合计必须 100%，实时提示）；同中类行业分值不得低于同大类分值。
  • 结论、额度与置信度参数：高度相似阈值、最低有效样本数（1–20）、最低数据覆盖率、高度相似案例通过率门槛、贷后后三类占比上限、未通过案例相似度红线（不得低于高度相似阈值）、额度最低有效样本数、高置信度最低有效案例数（不得低于最低有效样本数）、高置信度最低平均覆盖率（不得低于最低数据覆盖率）。最低有效样本不足时只能输出低置信度辅助意见；存在仅同大类匹配的有效案例时不能评为高置信度。
  • 结构化分析提示词：入库摘要、单案分析、综合分析三类，支持输入预览与恢复系统默认；保存时校验占位符（未知或缺少必要占位符禁止保存）。后端对模型输出执行固定 JSON 结构、样本范围、额度上限和证据完整性校验，管理员提示词不能绕过系统约束。

2. 业务资料自动入库

后台处理能力，无独立前端界面。与历史数据迁移（存量一次性初始化入库）相互独立。

2.1 数据源及触发时点

• 通过业务入库三套材料；拒绝业务仅调查报告与审查意见两套（无批复），统一打标标记审批结论=拒绝；再议业务该流程废弃，不通知、不入库。
• 贷后五级分类数据不入库，经接口从企业知识平台实时获取。
• 入库数据服务于两个场景：类案对比（业务摘要用于语义相似检索，统一打标用于精确条件检索）与小问业务材料问答（原始材料与摘要供检索与溯源）。

2.2 关键规则

• 业务唯一性与版本：业务流水号为唯一主键；一笔业务最多各保留一份当前有效的调查报告/审查意见/批复，同一材料类型更新时覆盖旧有效版本；检索与问答只使用当前有效版本；一笔业务只有一份业务摘要和一套统一打标。
• 摘要与打标：审查意见或批复入库时触发该业务摘要重新生成与统一打标更新；摘要综合当前全部有效材料并使用"摘要与自动查找设置"中当前生效的提示词；调查报告系统的标签作为初始数据，最终统一打标以入库通知文件名承载为准（自文件名解析）。打标字段至少含：企业性质、企业规模、经营年限、所属行业、贷款用途、产品（多值，无产品标"授信”）、主担保类型、所属分行、业务审批通过时间（仅通过业务填写）、审批结论（通过/拒绝）及业务流水号等关联标识。“类型（项目/非项目贷款）“由本系统按产品名单自动判定，不打标。
• 后端处理：自动发起与入库通知均支持幂等；不采用轮询获取新文件；同一业务多材料任务按业务流水号串行化；RAG 底座建立业务流水号、材料类型、来源系统、文件状态、摘要与统一打标关联。
• 异常处理：索引查询超时按退避重试；影像拉取失败进重试队列且未成功前不覆盖原有效文件；格式校验失败保留索引待源系统修正；摘要提取失败不发布不完整索引、重试成功后原子更新；打标缺失允许为空并记录来源；并发更新按流水号加锁/版本号校验；重复通知按流水号+材料类型+更新时间幂等跳过。

3. 本章关联文档

• 检索配置弹窗与悬浮按钮入口：03 悬浮按钮与任务管理
• 材料入库触发链路：02 业务架构与端到端流程、09 对外交互方案 场景 4/5
• 下一章：06 审查报告

7.1.3.6 - 审查报告

1. 审查报告生成

1.1 功能概述

审查报告生成是智能信审平台的核心业务能力，本身无独立操作界面：由信贷系统（授信作业中心）在业务提交环节自动触发，无需人工发起。依据管理员预先配置的审查报告模板、批复条件、运行管理及各类检查配置自动执行，产出可供审查人员查看、编辑和提交的审查报告。

• 报告范围：本期覆盖 9 类报告——非集团审查报告、集团审查报告、住房审查报告、消费审查报告、经营贷审查报告、同业报告、低风险报告、委托贷款报告、银行信用债报告。
• 术语说明：“审查意见生成"指授信作业中心业务提交后自动触发审查报告生成的运行场景编码与接口命名，产物为审查报告，相关接口命名沿用该场景名称。

1.2 业务处理流程

1. 客户经理提交授信业务，系统判定需出具审查意见。
2. 业务提交成功后，信贷系统自动调用审查意见生成接口（传入业务流水号、提交批次/版本、客户及流程上下文）；本系统不提供人工发起入口。
3. 按"业务流水号 + 审查意见生成场景"创建或更新任务，按运行管理配置执行（信贷发起、业务流水号唯一标识、重试次数、运行时限）。
4. 后端冻结本次提交对应的业务数据、材料及配置快照（模板、批复条件等），加载任务模板，从信贷系统查询业务基本信息，从客户中心查询财务要素和客户关系，结合调查报告及相关检查结果启动 AI 生成。
5. 按模板章节、运行批次、输入能力和上游章节依赖依次执行：先生成事实类章节（授信方案概述、借款人基本情况、项目情况、担保情况分析），再生成授信方案可行性分析、结论及建议，最后生成批复条件及各类检查附件章节；各章节调用模板配置的能力提供方（调查报告结构化数据、调查报告专项分析、制度合规检查、政策检查、行业均值检查、批复条件自动生成）并遵循系统提示词约束。
6. 异步任务，通过 SSE 按章节流式推送；报告状态：排队中 → 生成中 → 生成完成/生成失败。
7. 业务打回重提时重新执行并覆盖当前有效结果；历史执行日志保留用于审计。
8. 生成完成后，审查人员进入智能报告详情页查看、编辑、溯源和提交。

2. 审查报告模板配置

面向系统管理员，直接维护模板结构、匹配规则及报告生成规格；配置不描述工作流节点/连线/重试/并发，由后端将报告生成规格编译为生产工作流。

• 模板类型与匹配：区分集团、非集团和个人三类模板，均由管理员新建、不预置；按匹配优先级（1 最高，100 最低，默认 50）+ 授信类型 + 产品维度匹配（产品为空表示适用全部产品）。
• 生效机制：暂存只更新唯一一份未发布草稿，不影响生产；确认发布后生效版本号递增并形成不可变生效版本；任务启动时冻结生效版本、格式和提示词快照。暂存/发布/放弃均携带草稿版本号，不一致返回版本冲突。
• 章节结构：章节、顺序、章内标题树均由管理员配置，无固定结构。章节类型：正文、批复条件（单例系统章节，重复新增时定位已有章节）、附件（能力须声明支持附件场景且输出类型为表格；初始附件为制度检查明细、政策检查明细、行业均值对比，不含财务分析附件）。
• 运行批次：批次为正整数（允许 10/20/30 等不连续批次号），相同批次并行、按数值升序执行；章节序号只控制展示顺序，运行批次只控制执行顺序；前章结果只能引用运行批次更小的正文。出厂配置：事实摘录章节和三类检查附件为第 1 批，可行性分析第 2 批，结论第 3 批，批复条件第 4 批。
• 章内标题树：支持二至四级；节点含稳定编码（一级章节内唯一）、标题、层级（须与深度一致）、同级序号、节点生成要求和子标题；每个节点必须生成正文，渲染顺序固定"标题→本节点正文→子标题→子节点正文”；模型只返回节点正文（Markdown，允许段落/列表/表格），不得返回或修改模板标题；旧版纯标题列表读取时自动迁移为二级节点。
• 提示词分层：
  • 工作流强制规则（不可编辑）：证据编码格式、引用真实性校验、未知证据拒绝、缺失信息兜底、结构化返回校验；
  • 模板系统提示词：审查角色、通用写作规则、集团/非集团差异；
  • 章节提示词与输出约束：章节范围、摘录或分析方式、输入来源、输出组织；
  • 节点生成要求：二至四级标题的细项规则（不得手写文件标识、页码或引用编号）。
• 引用契约：引用含单元内数字编号、工作流证据编码、来源类型（原始材料/系统能力结果）、文件标识、元素标识、原文片段、来源名称、能力编码和前章派生单元标识。模型只能使用本次证据目录中的证据引用标记（如 E001），后台验证后按首次出现顺序转换为数字引用（[1]）；无效引用先由工作流修复，仍失败输出统一缺失口径，不得保存虚假引用。前章结果不作为最终证据，后续章节使用前章事实时须继承并指向底层原始证据。
• 保存校验：至少一个正文；章节编码唯一；正文标题和提示词完整；运行批次为正整数；前章引用合法；系统章节能力有效；节点编码唯一、标题非空、层级连续 ≤4 级、同级序号连续。
• 界面：模板列表（按优先级升序、名称防抖 500ms 搜索、发布状态标签[未发布/已发布/有未发布修改]、操作：编辑模板/查看生效/删除）→ 创建/编辑弹窗（名称 1–200 字符、优先级、授信类型字典 RT_CREDIT_TYPE、产品字典 RT_PRODUCT 多选）→ 模板详情（“章节配置”+“模板格式编辑"两页签；顶部操作：放弃未发布修改/暂存/确认发布——发布前弹监管人工核验提示；模板格式编辑复用智能报告详情富文本编辑器，标题、编号和 AI 内容占位为受保护内容，页边距、页眉、页脚继承原文件只读）。

3. 批复条件配置

以模板方式维护标准贷前、贷后条件及自由审核规则。

• 一份模板可关联多个产品，一个产品只能关联一份模板；模板可暂不关联产品。配置保存即形成新版本；报告任务启动时冻结批复条件配置快照。
• 标准条件项字段：顺序（正整数不重复）、类别（RT_APPROVAL_CATEGORY：贷前落实条件/贷后落实条件）、必选性（RT_APPROVAL_REQUIRED：必选/可选）、合同项、标题、标准文本、分项提示词。
• 自由审核可启停并维护提示词，结果固定归入贷前落实条件；启用时提示词必填。
• 保存携带草稿版本号乐观锁；名称/系统提示词/条件标题/标准文本必填；产品冲突时返回已关联的冲突模板及产品信息，禁止覆盖。删除模板后原关联产品不再具有批复条件模板；已启动任务仍使用冻结快照。

4. 模板分析配置

保留在"功能备份"菜单的独立系统管理员功能，维护历史模板文件分析能力的两份 AI 分析提示词（首次上传分析提示词、变更模板文件分析提示词，均必填 ≤12000 字）。不与当前模板管理流程联动；配置只有当前版本、不保留可恢复历史；保存后立即影响新任务，运行中任务冻结启动快照。单个模板只能维护可选"分析备注”。

• 固定步骤与进度（后端固定实现，进度单调递增，前端只展示返回值）：
  • 首次上传：文件安全和完整性检查 0–10% → DOCX 内容与格式提取 10–25% → AI 全量结构和语义分析 25–65% → 集团/非集团审核基线映射 65–85% → 校验修复及草稿组装 85–100%；
  • 变更模板文件：文件检查和提取 0–25% → AI 全量识别新目录与章节语义 25–55% → 对比当前配置并生成合并建议 55–85% → 校验并形成合并预览 85–100%。
• 校验：再校验最大四级、编码唯一、系统章节、正整数批次、能力和前章引用；仍失败任务置为失败，原草稿和生效版本不变。变更匹配优先按稳定编码、标准化标题和父级路径匹配；匹配节点保留原配置，新增节点生成局部建议，移除节点必须人工确认。

5. 智能报告详情

审查报告模块的核心页面：AI 辅助报告查看、编辑、溯源和修订追踪的全流程工作台。

5.1 布局与进入方式

• 三栏布局：左侧目录树（点击锚定跳转）、中间富文本编辑器（含缩放 50%–200%）、右侧面板（报告溯源、修改记录子页签）；三栏均可折叠。
• 页头：返回、报告标题（客户名称）、页签切换（调查报告/运行情况与反馈）、隐藏/显示标记、保存、报告下载、全屏。
• 进入方式：审查人员从授信作业中心任务入口或运行列表进入已创建的报告任务（携带业务流水号、任务标识与工作区标识）；查看权限由授信作业中心统一判定（暂定仅总行审查人员、总行审批人员），跳转前校验，本系统后端在查看与下载时再次校验授权上下文；未授权访问、拼接 URL、越权下载一律拒绝并记录安全审计日志。菜单入口仅用于查看已有任务，不创建新任务。

5.2 AI 生成与编辑

• 报告状态为排队中/生成中时：编辑器只读、保存禁用，底部悬浮提示"报告生成中/排队中"，仅允许取消生成；通过 SSE 流式接收每个问题的 AI 回答并实时渲染（问题标签按状态显示加载中/已回答/无法回答图标）。
• 问题驱动：模板中以问题标签标记 AI 或人工填写位置；多级标题模板下每个二至四级标题正文对应独立内容单元、引用列表和修改状态。
• AI 改写：选中文本触发悬浮对话框（可拖拽）：原文展示、对话气泡（用户蓝/AI 灰）、AI 回复附接受/复制/重试操作、“参考对应调查报告"勾选（注入上下文，适合重新分析但较慢）、改写提示词回车发送。改写不沿用旧引用，须重新证据匹配与校验。
• 人工修改：保留未删除的引用标记并清理已删除引用，节点状态更新为"AI 已人工修改”；溯源面板提示引用只对应保留标记。
• 退出自动保存：返回或关闭标签页时自动保存编辑器内容。

5.3 溯源与修改记录

• 报告溯源：溯源点导航（翻页/单切换箭头 + 圆点列表）；内容区按文件类型自动选择预览器（PDF 分页高亮/图片/Excel/Docx/文本）；全屏预览（Esc 退出）附 RAG 召回结果卡片列表（文件名、摘要、命中分数，点击切换溯源点）。区分"原始材料"与"系统能力结果"（制度、政策、行业检查结果经虚拟来源文档复用预览与高亮）。引用列表按答案文本中的引用标记过滤展示。
• 修改记录：当前问题答案的历史版本列表（版本号"第 X 版"、当前标记、操作人、时间）；展开左右对比（改前灰/改后橙），支持还原至历史版本（二次确认）；按版本号倒序。

5.4 运行情况与反馈页签

运行详情基础信息（任务编号、标题、功能、业务功能、客户号、业务流水号、状态、结果、提交/完成时间）+ 运行情况（小查展示子模块结果组件）+ 结果评价（小查按子模块分项，其他整任务评价）。

5.5 异常处理

SSE 中断→保留已渲染内容并提供重新生成入口，启动状态轮询兜底；SSE 超时→拉取最新答案回填并清理连接；停止生成失败→保留连接可重试；模板获取失败→编辑器不渲染；保存/下载失败→错误提示不丢内容；ESB 调用失败→对应问题区域保持加载中/空态；影像平台拉取失败→溯源面板该来源不可预览并提供重试；权限校验失败→拒绝并记录审计。

6. 本章关联文档

• 自动触发链路：02 业务架构与端到端流程 §2.1
• 权限与页面跳转交互：09 对外交互方案 场景 3
• 下一章：07 智能审核（小核）

7.1.3.7 - 智能审核（小核）

1. 总体说明

智能审核（小核）提供"目录同步与确认、资料自动分类配置、审核规则配置、业务材料上传、业务材料审查、小核配置"六个三级功能，覆盖放款/出账环节的材料审核全链路。

• 子模块：对公含放款基本审核、出账基本审核、贷前落实条件审核、借款合同审核、贸易合同审核五个；个人条线不含出账基本审核，其余四个同名复用。
• 发起边界：放款审核、出账审核由授信执行中心在客户经理提交对应业务后自动发起（唯一发起点），本系统不提供人工新增/重新发起按钮；非放款审核场景可经悬浮按钮按配置发起"智能审核"。
• 材料+制度双审核：“放款智能审核接口"同时受理材料智能审核与制度风险分析：制度检查范围按智能制度检查配置的节点制度映射确定——放款申请（loanReleaseApply）与出账支付管理（paymentManage）分别映射各自制度集合，个人条线复用同名个人制度映射；返回材料风险、制度风险及合并风险等级（取高）。

全屏打开 ↗

2. 目录同步与确认

从信贷系统同步审查目录（材料目录树），在系统内进行版本化管理、影响确认与受控生效。同步生成的候选目录不会自动替换当前生效目录。目录节点携带材料要求属性（适用阶段、主体角色、必传规则、文本形态、份数规则、缺失风险、命名方式、命名模板、有效期、复用策略等），本期仅供配置和确认，上传资料功能暂不消费。

全屏打开 ↗

2.1 业务流程

1. 同步：点击"从信贷系统同步”，后端拉取最新目录并与当前生效目录差异比对，生成候选版本（状态"待确认"）；无差异提示"当前已是最新目录"；同步调用超时（30 秒）或数据校验失败不生成候选并记录日志。同一时间仅允许一个候选版本。
2. 影响确认：候选版本详情"影响确认"页签展示影响清单（影响等级[高/中/低/同步阻断]、变化类型[新增节点/删除节点/节点改名/调整上级/层级结构变化/材料要求变化/适用范围变化/命名规则变化]、节点、变化前后路径、变化说明、规则影响[直接/继承关联数]、确认状态）；支持逐条、按等级批量、勾选批量确认。
3. 失配处理：因节点删除导致规则失配的项，须先在"处理失配"弹窗选择处理方式——重新绑定（选择目标节点，必填）/ 停用并保留 / 删除规则；处理方案在目录生效时批量应用。
4. 生效与放弃：全部影响项确认且失配处理完成后候选状态变"待生效"，点击"生效候选目录"经二次确认后置为生效，原生效目录转为历史版本；可"放弃候选"丢弃候选及全部确认记录。
5. 回退：对历史版本点击"生成回退候选"，基于该历史版本快照生成新候选（待确认），需重新完成影响确认后生效。

2.2 界面要点

• 目录版本列表：平台版本、信贷源版本、状态（生效中/待确认/待生效/历史版本彩色标签）、节点数、同步/生效时间、操作人、说明；候选状态显示"确认"，历史版本额外显示"生成回退候选"（存在待处理候选时禁用）。
• 目录展示页签：左树（300px，搜索过滤、默认展开）+ 右侧节点材料要求详情（描述列表；非生效目录顶部黄色警告）。
• 目录变化详情弹窗（680px）：节点、影响等级、变化说明、变化前/后路径、关联规则、上传影响、确认记录（确认人+时间或"尚未确认"）。

3. 资料自动分类配置

管理上传材料的自动分类规则与全局分类参数。规则与目录版本"绑定+继承"：规则绑定到目录节点，作用范围为"仅当前节点"或"当前节点及全部后代"；最终生效提示词按目录层级从上到下拼接全局分类业务提示词 + 各层级适用节点提示词 + 系统固定输出协议，调用大模型完成自动分类。节点不在当前生效目录时规则状态为"待目录匹配“且不执行。

• 分类规则配置页签：平铺模式（表格：配置名称、绑定目录全路径、作用范围、节点补充提示词、当前状态[启用且可执行/待目录匹配/已停用]、更新人/时间；筛选：关键词、目录匹配状态、启用状态）/ 目录模式（左树 + 右侧节点规则列表，区分"本节点配置/继承自[上级]"；底部"最终生效提示词预览"按全局（蓝底）→各层级（标注来源）→固定协议（灰底）展示，仅显示启用规则；失配规则归入虚拟"失配规则"分组）。规则保存后立即生效。
• 全局配置页签：材料不符判断开关（默认启用；关闭后仍自动分类但不判断人工调整后的材料是否与节点不符）、分类业务提示词（≤2000 字符）、固定输出协议（系统固化不可编辑）、聚合判断规则（只读：同一节点多份材料时，至少一份符合则整个节点不提示材料不符）。“保存配置"需确认并立即生效。

4. 审核规则配置

管理智能审核所依据的审核规则、材料提取要素、业务数据项及全局提示词，是材料上传预审与审查环节的规则来源。规则按目录节点触发，可组合材料提取字段与业务系统结构化数据，通过可视化条件或大模型提示词完成风险判断。规则保存后立即生效；“目录匹配状态"计算规则同上。

4.1 页签与关键概念

• 规则配置（平铺/目录两种视图）：规则属性含规则编号/名称、绑定目录、作用范围、业务场景（放款基本审核/出账基本审核/贷前落实条件审核/借款合同审核/贸易合同审核，多选）、判断模式、执行粒度（当前业务/每个相关主体/每份材料）、命中风险（高/中/低/疑似）、使用端（仅审查端/上传及审查）、配置方式、启用状态、目录匹配状态。
• 五种判断模式：① 图片直接由大模型判断；② 图片提取要素后由规则判断；③ 图片提取要素后由大模型复核；④ 使用已有解析结果由大模型判断；⑤ 已有解析结果先规则初判再由大模型处理例外。模式决定是否需要配置结构化判断条件及大模型提示词。
• 提取要素：独立可复用配置单元（要素编号唯一、名称、绑定节点、数据类型[文本/金额/日期/比例/布尔/枚举]、提取要求、启用开关），同一节点的提取要素可被多条规则共同引用；被规则引用的要素删除需确认。
• 业务数据项（只读）：后端统一注册，来源包括材料提取字段、信贷系统、审批批复、外部查询（经 EDS 获取企查查数据，用于个贷放款核对交易对手经营范围与贷款用途）及系统变量；只暴露业务名称与含义，不暴露接口地址与数据库结构。
• 全局设置：审核通用提示词（≤3000 字符）、风险输出约束（≤1500 字符）、溯源提示词（≤2000 字符；材料证据定位到文件和页码，结构化数据记录数据项、当次取值、来源系统和获取时间，本期不含矩形坐标）、固定输出协议（固化）。单独"保存全局设置并生效”；进行中的预审任务沿用发起时快照。

4.2 规则编辑器（四步）

1. 基本信息与执行范围：规则编号（≤50，唯一）、规则名称（≤100）、绑定目录（必填，可搜索）、作用范围、适用场景（多选）、执行粒度、命中风险、判断模式、启用开关、“仅审查端"开关（开启后客户经理端不返回该规则名称/提示词/数量和结果，仅提交或审查阶段执行）。
2. 规则输入：输入项表格（输入别名必填、业务数据项必填[显示"业务名称（来源系统）"]、主体角色[借款人/保证人/抵押人/出质人/交易对手，可空]、必需开关、缺失风险）。
3. 判断逻辑：按判断模式动态展示——无需规则条件时提示直接填写提示词；需要时选择配置方式：可视化规则（条件关系[满足全部/任一] + 条件表格：左侧输入、操作符[按数据类型过滤：文本=等于/不等于/包含/不包含；金额与比例=数值比较；日期=比较及"在有效期内”；布尔与枚举=等于/不等于]、比较对象[固定值/其他输入项/系统变量]、比较值）或预置复杂规则（模板：抵质押物多材料描述一致性/主从合同核心要素一致性/公司决议合法有效性/押品保险覆盖有效性 + 模板业务参数）。
4. 模型提示词与制度依据：大模型提示词（≤2500 字符，需提示词的模式必填）、制度依据、适用日期、条款说明。

保存前校验：别名与数据项非空、条件完整或模板已选、提示词非空（按模式）；启用但绑定节点不在生效目录时确认"待目录匹配”。复制规则生成新编号、名称追加”-副本"。

5. 业务材料上传

授信执行中心完整放款和出账流程中的资料上传子功能（放款资料上传/出账资料上传两场景）。文件实体存影像平台，本系统仅保存元数据、分类信息和任务状态；完整放款、出账业务功能及最终业务提交均由授信执行中心提供。“新增任务/一键预审/提交"仅处理资料上传任务，不代表创建、提交或审批放款/出账业务，也不是审核任务的人工发起入口。

5.1 关键机制

5.2 界面

• 任务列表：关键词查询；列含任务名称、客户名称、业务流水号、上传场景、目录版本、完整度（进度条）、风险（有风险红色数字/无风险绿色 0）、状态（草稿灰/分析中橙/已完成分析与审核完成绿）、创建时间；草稿显示"上传/查看/删除"，其他仅"查看"。
• 材料工作台：顶部标题栏（返回、任务信息、目录版本/完整度/风险标签、一键预审、下载材料、提交）；预审结果面板（进行中蓝色含阶段与进度；完成绿色含统计与"沿用"说明；失效橙色提示重新发起）；中部左目录树（虚拟根目录 + “未分类”，节点状态齐/缺/处理中/未分类/险）右材料面板（复用历史材料、上传到当前节点[含子节点禁用]）；文件卡片（缩略图/后缀、材料名称、原始文件信息、风险等级与项数、分类状态、改名/移动目录/失效/删除）；底部上传队列可折叠。预审预计 1–3 分钟。

6. 业务材料审查

放款审查岗和出账审查岗查看由授信执行中心自动发起的审核任务，以问题优先方式复核智能分析结果及证据。审查模式只读：不显示上传、改名、移动、删除、预审和提交操作。

6.1 审查工作台

• 顶部：任务信息、目录版本/完整度/风险标签、下载材料；任务进入分析中/已完成分析后显示"材料审核 N / 制度审核 M“分段切换（默认材料审核；任一维度风险为 0 时按钮置灰仍可切换查看空态；下载与评价常驻，评价针对材料智能审核任务整体）。
• 制度审核维度：整面板复用"小查"样式（风险概览统计 + 制度合规检查模块 + 风险条目制度条文/业务证据双重溯源）；制度风险分析中显示"制度风险分析中，请稍后刷新查看结果”；0 条显示"审核完成，未发现制度风险"。
• 问题审查视图（默认）：问题队列（风险标签、规则名称、结论摘要、主证据来源；按高/中/疑似/材料不符/低过滤，字典加载）+ 证据原文栏（PDF 原生页码定位、图片预览、全屏；多证据按钮切换；证据文件不可用时展示"证据文件当前不可用"及最后已知定位）+ 问题详情栏（审核结论、比对数据、判断依据、规则详情）；三栏可折叠，“专注证据/恢复三栏"切换。
• 全部材料视图：目录树 + 材料只读预览 + 风险面板；风险项可"进入问题审查并定位证据”；无风险任务显示"未发现问题"并可查看全部材料。失效文件置灰展示"已失效"标签，不作为问题与风险依据。
• 证据契约：材料证据（证据编号、文件编号、文件名、页码、原文或提取值、主证据标识）+ 结构化数据证据（数据项名称、当次值、来源系统、获取时间）；同一风险可关联多份。旧记录单一定位信息自动适配为单条材料证据。
• 结果来源约束：正式审核可复用未变化的材料解析结果，但必须按当前审核场景、业务数据和生效规则重新确定最终结论；不得直接将上传环节预审结果作为正式审核结论。

7. 小核配置

管理小核子模块启停与"子模块 × 末级功能"绑定（与风险分析配置结构一致）。

• 默认绑定：放款基本审核→放款申请；出账基本审核→支付管理；贷前落实条件审核→贷前条件审查；借款合同审核→借款合同；贸易合同审核→支付用途审查。个人条线同名子模块按各自末级功能复用上述绑定；不绑定任何末级功能时对所有功能生效。
• 悬浮按钮进入业务材料上传/审查页面按"角色功能路由"配置的目标与进入方式执行，默认"仅查看"（只读，不提供上传、新增任务、删除或重新分析）。

8. 本章关联文档

• 放款智能审核接口契约：09 对外交互方案 §六/§七
• 目录版本状态机：图表 life-directory-version.html（全屏 ↗）
• 上一章：06 审查报告 ｜ 下一章：08 评价分析

7.1.3.8 - 评价分析

评价分析模块构成"用户评价 → 明细沉淀 → 周期量化分析 → 提醒回收 → 参数配置“的闭环，覆盖小查、小审、小核、小问及审查报告生成的评价数据。

1. 评价查询

面向评价分析管理员与业务用户，对用户在各智能体会话中提交的逐条评价记录做明细查询与详情查看。

• 查询条件：功能（小查/小审/小核/小问）、评价等级、评分范围（0–100 闭区间）、反馈原因、评价人（精确匹配）、评价机构（机构树搜索选择器单选，按名称精确匹配）、评价时间区间；按评价时间倒序分页。
• 列表列：评价时间、评价人、评价机构、功能、评价对象、评分、等级（彩色标签，颜色取自评价等级配置）。
• 评价详情：基础信息（评价时间、评价人、机构、功能、评价对象、任务编号、评分徽章、等级标签）+ 反馈区（反馈原因标签列表[无则"未选择”]、补充说明[无则"无"]、上传截图缩略图网格可预览大图）。
• 返回列表保留筛选与分页位置。

2. 效果评价分析

面向评价分析管理员，对信贷智能体服务效果做周期性量化分析。

• 主流程：分析列表（新增/查看/PDF 下载）→ 新增分析（配置统计周期、功能维度[知识库/审查意见/智能问答/风险识别，可多选]、功能类型[全部/试用/非试用]、评分范围、评价最多用户数 1–50 默认 10）→ 系统聚合生成报告 → 详情查看 → PDF 预览与下载。
• 执行机制：创建接口同步落库（状态=已提交）立即返回；异步聚合（按统计周期+功能维度+功能类型+评分范围过滤 → 聚合核心指标、等级分布、反馈原因统计、四维分组统计 → 落库 → 生成 PDF → 状态"已完成"）。状态非实时推送，重新拉取列表/详情时更新。
• 聚合口径：评价参与率 = 产生评价的对话数 ÷ 服务对话数 ×100%；评分平均值 = Σ评分 ÷ 评价数；评分中位数 = 升序取中位（偶数取中间两数均值）；评价数 = 满足筛选条件的评价记录计数。
• 分析详情：核心指标概览（服务对话数、评价参与率、评分平均值/中位数）+ 图形化分析（评价等级分布环形图[超出预期/优秀/合格/不及格]、反馈原因词云[没说清楚/回答错误/溯源错误/答非所问/异常报错/其他]）+ 分维度评价分析（用户/角色/机构/功能四维分组表：参与率/平均分/中位数/评价数）。
• PDF 报告：仅"已完成"可下载；下载接口后端再次校验任务状态与权限。

3. 评价提醒配置

管理未评价 AI 结果批量提醒参数；保存即时生效，次日批量程序按新配置执行。

4. 未评价提醒

批量后台程序，无前端界面。每日按配置时间执行一次：

1. 读取评价提醒配置（各功能启停、最大提醒天数）。
2. 任务式 AI 功能：扫描已完成且评价状态"未评价"、完成时间在最大提醒天数（含）以内的任务；对话式（小问）：扫描配置天数内有对话的会话，会话中存在任一未评价 AI 回答即视为整任务未评价。
3. 将待提醒记录写入提醒文件（用户标识、提醒标题、提醒内容、链接 URL），上传至影像平台约定目录；门户定时轮询获取并处理为门户提醒。
4. 链接规则：任务式→运行列表对应任务详情页（携带任务编号）；对话式→小问对话主页面并定位指定会话（现状简化浮层不支持深链，降级为仅打开对话面板）。
5. 已发送提醒的任务/会话标记"已提醒"避免重复；批量程序记录执行日志（起止时间、发送/跳过/失败条数）；文件生成或上传失败按重试机制处理，不阻塞后续批次。

5. 评价设置

维护评分等级标准与预设反馈原因两项基础配置，保存即时生效。

• 评分等级标准（0–100 须连续覆盖、互不重叠）：每行含最低分/最高分（0–100 整数）、等级名称、编码（同级唯一）、颜色（默认蓝色）、弹出反馈开关（默认开）、必填说明开关（默认关）。保存校验：至少一个等级；编码名称非空；区间合法（最低 ≤ 最高）；编码不重复；按最低分升序后首段最低分为 0、末段最高分为 100、相邻区间无缝衔接（上一段最高分 +1 = 下一段最低分）。
• 预设反馈原因：原因名称、编码（唯一）、启用开关（默认开；关闭后评价录入下拉不展示）。保存校验非空与编码唯一。
• 保存成功后按最低分降序排列等级（高分在前）；接口异常或无数据时回退内置默认配置。

6. 本章关联文档

• 评价录入入口与要素：03 悬浮按钮与任务管理 §3、§4
• 提醒文件经影像平台送达门户：09 对外交互方案 场景 10
• 下一章：09 对外交互方案

7.1.3.9 - 对外交互方案

门户以微前端形式集成信贷系统与智能信审系统两个平级子应用：智能信审不与门户直接做前端交互，页面级互操作（悬浮按钮读取缓存、页面跳转、iframe 嵌入）均发生在信贷系统与智能信审两个微前端子应用之间；门户与智能信审之间仅存在系统级对接（主数据同步、知识库菜单集成）。外围交互系统：信贷管理系统各业务中心（授信作业中心、授信执行中心、客户中心等）、门户、调查报告系统（智能尽调系统）、企业知识平台、外部数据管理平台（EDS）、影像平台。

全屏打开 ↗

1. 六种交互模式

缓存字段（场景 2/4 共用）：业务流水号、合同号（合同环节必须提供）、客户号、批复编号。

2. 交互场景总览（12 个）

场景要点

• 场景 1（业务发起与调查报告获取）：调查报告正式版保存后自动 PDF 入影像并登记索引（不感知信贷提交状态）；授信业务提交成功后授信作业中心调用统一发起接口（同时发起小查与审查意见生成，不再传输调查报告文件）；本系统查询文件索引并拉取 PDF 本地暂存，先统一执行一次财务分析与制度分析（结果供两任务复用），再分别创建任务。通知式查询替代以往准实时轮询，仅业务提交后查询一次。数据支撑：财务要素←客户中心；企查查←EDS；行业均值与政策法规←企业知识平台 ETL（T+1）。
• 场景 2（审查岗查看小查）：审查审批页面写缓存点亮"小查"；小查已随业务提交自动执行，此时点击属重复发起，按运行管理配置处理（默认允许，覆盖原任务；原任务执行中自动终止）。
• 场景 3（审查岗出具审查意见）：初稿由场景 1 自动生成；查看/编辑经 URL 的 mode 参数区分（同一接口）；授信作业中心跳转前完成权限校验，本系统后端查看与下载时再次校验，未授权/拼接 URL/越权下载拒绝并记审计日志。生成过程中经"客户关系查询接口"获取数据，自行生成集团关系图谱图片放入报告。
• 场景 4（类案对比）：任务期间经"业务基本信息查询接口"取当前业务与关键要素快照；经"五级分类数据查询接口"实时获取历史案例贷后五级分类；查看完整贷款信息时页面嵌入授信作业中心贷款信息查询页面（参数含 mode=current/case、业务流水号、客户号、业务名称、客户名称、客户类型，类似案例另带案例标识）。
• 场景 5（终审与业务资料入库）：通过→审查意见+批复入库（打标含审批通过时间）；拒绝→仅审查意见（打标不含通过时间）；再议→不通知不入库。同一材料更新再次通知并覆盖旧有效版本。统一打标 11 字段：业务流水号、企业性质、企业规模、经营年限、所属行业、贷款用途、产品（多值/无产品标"授信"）、主担保类型、所属分行、业务审批通过时间（仅通过）、审批结论。
• 场景 6/8（资料上传）：目录维护并列两种方式（方式一：信贷修改联动差异确认同时生效；方式二〔现行〕：目录同步接口获取→候选版本→逐条确认→激活，支持回滚）；删除控制按节点/文件粒度传入不可删除标记；复用历史材料物理复制两份；映射回传含失效状态；上传任务提交不触发审核。
• 场景 7/9（出账/放款审核）：以授信执行中心提交事件为唯一发起点；执行期间经"放款/出账要素查询接口"取利率、受托支付、还款方式等，合同审核经"合同信息查询接口"取合同信息；个贷放款审核另经 EDS 取交易对手企查查信息（重点关注经营范围与贷款用途相符性）；打回重提覆盖本场景结果，出账与放款审核相互独立。
• 场景 10（未评价提醒）：每日批量生成提醒文件上传影像约定目录；门户设定时间后轮询获取处理为门户提醒；仅对完成时间在最大提醒天数（默认 7）内的未评价任务生成。
• 场景 11（主数据同步）：实时（ESB 变更通知）+ 批量（企业知识平台表级同步）双通道；菜单由门户配置，本系统提供前端文件。

3. 接口清单（38 项）

业务层面接口清单。实际设计可复用/合并/拆分接口，数量、名称与出入参以接口设计文档为准。

注：原序号 14"审查意见下载接口"已取消——报告下载改为在审查意见查看/编辑页面内通过"报告下载"按钮完成；序号 36 上传文件失效接口、37 统一发起接口、38 放款智能审核接口（材料+制度双结果回执）为新增。

4. 接口必要字段（必传最小集合）

5. 放款智能审核接口契约（材料 + 制度双审核）

客户经理提交放款申请或出账申请后，授信执行中心调用本接口发起统一审核回执。本系统按业务流水号幂等创建或更新小核任务，执行材料智能审核的同时调用制度分析模块执行制度风险分析，一次性返回双结果。

5.1 触发节点映射

5.2 请求字段（授信执行中心 → 本系统）

5.3 响应字段（本系统 → 授信执行中心）

5.4 页面双审核切换约定

• 任务进入分析中/已完成分析后，顶部显示"材料审核 N / 制度审核 M"分段按钮，默认材料审核；任一维度 0 条时按钮置灰仍可点击查看空态；“下载材料/评价"常驻。
• 制度审核面板整面板复用小查样式；零风险显示"审核完成，未发现制度风险”。

6. 影像平台角色汇总

7. 本章关联文档

• 各场景对应的业务功能：04 风险检查（小查）、05 类案对比（小审）、06 审查报告、07 智能审核（小核）、08 评价分析
• 交互全景图：arch-interaction.html（全屏 ↗）

7.1.3.10 - 10 财务风险分析

依据《财务风险分析系统需求文档（1028）》整理。本版规则库由 969 条增至 972 条（2026-10-23 评审会新增 U-0970～U-0972 三条），并新增独立上传使用方式与财报上传与解析模块。

一、系统定位与两种使用方式

财报风险分析系统按 972 条规则逐条核查企业财报，给出风险评级与授信建议；每条结论都能追溯到实测数值、阈值档位与规则编号。系统支持两种使用方式：

输入与输出：

二、功能结构

2.1 财报上传与解析（新增）

任务与状态：一个任务对应一家企业、含一份或多份财报；任务名称不得与已有任务重名。任务状态由财报状态自动推出（从上往下取第一条满足的）：待上传 → 解析中 → 解析失败 n → 待审核 → 分析中 → 已完成。财报状态：排队中、解析中、解析成功、解析失败、已审核。

四个页面整页跳转、与风险分析页彻底分开：

• 任务列表页：「新建任务」必选适用对象（四选一、无默认值，选中即提示参与判定的规则条数——全部对公 724／上市公司 880／集团 796／上市集团 972），选填实控人、董事长、总经理出生年份（供 U-0972 使用；上市公司以年报「董事和高级管理人员情况」所列年龄为准，录入值仅作补充；只录年份不录身份证号）；仅创建人可删除，已生成分析的任务删除时确认框写明财报、解析结果、风险分析与人工补充记录一并删除。
• 财报上传页：「财报文件／数据明细」两个视图；添加财报时选报表类型（三张主表、年报含附注——决定规则按哪一档数据运行）；试算情况按口径分格（绿＝勾稽平衡且科目全映射、红＝有不平或未映射、灰＝文件中没有这张表）；数据明细按年份并排显示已审核数据，支持六张报表切换、变动对比（A 较 B：变动额、变动率，减少标红）、单位切换（元/万元/亿元）与 CSV 导出。
• 解析结果页：左边原文、右边科目表，分隔条 25%–75% 可拖动；表格类型纠正——原文上每张识别出的表格可跨页勾选多张后统改类型（合并三表/单体三表/未匹配），改后按新模版重新映射并重算勾稽；模版科目下拉带搜索，模版确实没有的科目用**本科目「＋/− 归属合计项」**并入勾稽式，并可反馈到模版或仅本报表生效；试算不平/校验通过面板点条即定位到科目与原文；基础信息（报表口径、报告期、金额单位、币种、是否经审计、审计意见类型）全部下拉选择不许手填，已审计必须选审计意见类型才能审核完成（供 U-0717 等审计类规则直接读取）；未匹配表格（如所有者权益变动表）只做基础解析、不映射模版科目。
• 风险分析页在新标签页打开。

勾稽校验：每张主表按模版科目分组自动生成勾稽式（不需逐家配置），容差 0.5；「其中」项不参与求和。跨期校验：本期财报的上年数＝上一期财报的本年数（比对资产总计、负债合计、所有者权益合计、营业收入、净利润、期末现金余额），追溯调整以本期重述数为准。

审核完成与解锁重审：「审核完成」作用于整个任务，前置条件为全部解析完成、每张主表无试算不平且无未映射科目，不满足时弹窗逐条列出「报表：试算不平 n、未映射 n」；完成后数据锁定、状态「分析中」，系统随即运行规则判定、评分与结论文案（第一次自动运行）。「解锁重审」只在财报上传页，确认后回到「待审核」可改数据、增删财报；重新审核完成后按新数据重生成，风险分析页已做的人工补充保留。

解析技术路径：默认走流水线（取文字层 → 扫描页 OCR → 版面分析 → 表格结构识别 → 字段匹配），数字逐字取自原文、可定位到页码坐标、结果确定、普通服务器可运行；对解析不准的页可点**「增强识别本页」**改用视觉大模型（VLM，适应扫描件、复杂版面与跨页表，需显卡算力、只在用户发起时用）。两条路径的结果都须通过勾稽与跨期一致校验，不过的字段进人工补录、不自动填数。留痕：每个数值记录解析路径、页码坐标、置信度，人工修改记录前后值与修改人；审核完成、解锁重审与风险分析版本一一对应。

2.2 总览页

评审进入后的第一屏，“不看明细也能下结论”，自上而下十个版块：

1. 评级横幅与核心结论：综合评级（极高/高/中/低）取三条轴的中间档；触发重点关注事项时结论直接覆盖为「不建议准入」并写明触发的闸号。数据不足按档处理：严重档（占比 ≥ 50% 或必查规则 ≥ 30% 数据不足）评级位置换成「无法评级（数据不足）」、授信建议「待补充资料」；中等档（20%–50%）保留评级加橙色提示并附链接直达规则库筛出数据不足规则；两条提示并存时否决在上。
2. 核心结论正文：三到五段、每段一个主题，大模型生成；生成前或失败时系统先写兜底正文（前 5 张卡各一句「议题名：风险指向原句」＋评级与行动建议），成功后整段覆盖。
3. 重大舆情与外部核查：结论区内一段话，明细在舆情核查页。
4. 授信建议表：六维（新增授信、存量授信、担保结构、财务指标约束、资金监控、治理与信息质量）档位由系统算出、文案由模型生成且不得与档位相反。取档规则：新增授信跟随综合评级（任一重点关注事项触发即「不建议」，否则极高「不建议」、高「审慎准入」、中低「可准入」）；其余五维按规则计数——所看域内任一 P0 且重点关注取红档，否则任一重点关注（任何优先级）或任一 P0 且关注取黄档，其余绿档；十个风险域被后五维全覆盖、不重不漏，档位旁显示「依据 N 条规则」可展开编号。
5. 放款前必须落实的核查清单：模型按风险议题生成、通常五到十条、不允许为空；兜底清单取前 10 张卡的处置动作原句去重，0 张卡时固定写「按常规贷前流程核查」一条，数据不足中等或严重时再加补录提示。
6. 核心指标概览：公司特定指标（重点关注且卡片优先级 P0 的议题卡按加权分取前 3 张）＋ 15 张四类核心指标（偿债/营运/盈利/现金流，含流动比率、资产负债率、现金转换周期、净现比、自由现金流等）＋ 大额科目（占总资产 20% 以上逐项列示，无超标改列最大三项）。每张卡数值、对照基准、好坏判断三样齐全；颜色只按警戒线定，基准只用来写「比行业均值高/低多少」；15 张中 7 张可用行业均值（ALR/ROL/365÷TAR/365÷ITR/GRP/NPR/ROE），其余只比上年；周转异常快（应收 < 5 天、存货 < 7 天、CCC < −60 天）不判红黄、改中性色提示确认业务模式。
7. 主营业务概览：分产品（或分行业）与分地区近三期收入、占比、毛利率；只由聚合组一方写入，无数据写「未取得」不留空。
8. 各域结论一览：十行——域名、判定标签与触发条数、一句话本域结论（即维度页本域结论第一行），点域名跳转。
9. 重点关注项：八条一票否决事项的状态表。
10. 风险项清单：一级风险（红，卡片等级为重点关注）与二级风险（橙，关注）两级；每个议题一张卡：规则编号（可跳转）、议题名（系统生成）、结论句、判读三段、依据规则列表；按卡片计数，与规则库「重点关注/关注」条数不相等是正常的。

2.3 风险域维度页（十个）

左侧栏按四个阶段分组：

每页含域头（规则数、必查项数、各判定计数）、本域结论两行、图表区、触发规则明细表。本域结论两行由大模型生成：第一行总判断（≤ 30 字、不带数字、先肯定再转折，必须覆盖本域最严重议题）；第二行支撑数字（2–4 个指标、≤ 120 字，逐字出现在实测依据里、不允许计算改写）。三种情况不调用大模型直接写固定文案且不显示第二行：全部不适用、未触发、可判定规则全部数据不足。

2.4 舆情核查、阅读指引与规则库

舆情核查页：舆情（随时发生、无人审计）与财报（一年一期、经审计、可勾稽）是两种证据，单独成页、不合并计数——舆情记录时间线（级别与正负面分两栏）＋ 外部信息族六条必查规则。

阅读指引页：134 条不直接产生判定的规则分三类——阅读路径 109、口径护栏 20、证据效力 5。其中只有 74 条 NOSCORE 阅读路径移出规则清单编成 109 步动线（另 35 条带阈值、既在动线上也照常判定打分，仍保留在清单里）；口径护栏与证据效力留在清单内，挂到指标出现的地方与上下文提示中。

规则库页：清单展示 898 条（972 − 74 条不判定的阅读路径），支持按域、类型、判定状态、关键词筛选，每页 150 行；其中 861 条参与判定与打分（每条一个状态：重点关注/关注/通过/数据不足/不适用/不可执行），另 37 条 NOSCORE 只展示不打分（口径护栏 16、证据效力 5、重点关注事项 7、其他 9）。972 ＝ 898 ＋ 74，898 ＝ 861 ＋ 37。每条展开显示 17 个字段全部内容并提供人工改判入口（改判、填实测值与核查说明，留痕）；页面顶部「大模型重算」按钮在人工判定后触发结论文案重写。

2.5 场景筛选

同一份规则库，不同评审环节看的条目不同。场景只过滤显示，不重跑判定、不改评级；人工改判在任何场景下做都即时改变全量评级。顶部场景条通栏吸顶（评级横幅之上）、可收起，九个按钮按审批流程排序：

每条规则有主场景（必填）与至多一个次场景；S6 贷后监控只出现在次场景，S8 舞弊识别规则以审批环节为次场景（如 67 条落到 S2）；S7 只有 U-0967、U-0968 两条，并入 S1 显示。场景字典与规则归属随规则库版本固化。各页面在场景下的行为有明确定义：评级、重点关注项、授信建议、核心指标、主营概览、核心结论始终按全量规则；风险项清单只列命中卡片但严重度、优先级与排序仍按全量计（不因过滤降级）；当前域 0 条时自动跳到第一个有命中的域。

三、整体逻辑：七个环节

数据层归集 → 规则判定 → 议题聚合 → 评分分档 → 图表与判读生成 → 结论文案生成 → 质量检查，任何一环的产物都可单独验证。

全屏打开 ↗

3.1 数据层

所有数值集中在七个命名空间，规则只能从这里取数、不允许写死数字：年报科目原值、派生指标（现算，全系统统一口径，如现金转换周期恒为"应收天数＋存货天数−应付天数"）、分季度数据（识别年末利润塌陷）、母公司报表科目（母子背离核对）、外部工商舆情（可缺，缺时显示未接入）、行业均值（固定取数）。

3.2 规则库结构

每条规则 17 个字段，核心九个：规则编号（全库唯一可点击）、所属风险域、检查项、计算口径（须可复算）、阈值（黄档/红档两段）、判定、实测依据（必须对得上口径）、优先级（P0 214 / P1 594 / P2 164）、实测标题。规则分布：按风险域 C 257 · J 198 · A 122 · I 95 · E 65 · K 55 · L 51 · F 50 · B 49 · H 30；按阈值形态比率 583 · 恒等式 151 · 不计分 111 · 状态 111 · 计数 16。

2026-10-23 评审新增三条（969 → 972，均为 P1、适用全部对公客户、参与判定打分）：U-0970 长期资产投入与融资期限匹配（短贷长用，B 域 F15，短贷长用比例 > 20% 关注、> 50% 重点关注）；U-0971 匡算应回款与实收现金差异（K 域 F20，差异率 > 10% 关注、> 20% 重点关注）；U-0972 实控人及核心管理层年龄（J 域 F40——董事长与总经理同时 ≥ 60 岁判关注，任一人 ≥ 70 岁判重点关注，边界归严；同一人兼任两职按该人计；实控人为法人或国资时只判董事长与总经理；判读提示人工核实接班安排但不作判定条件；2026-10-28 按评审意见调整）。

3.3 四层筛选

972 条不对每家公司全跑：

1. 适用对象：全部对公 724 / 上市公司 156 / 集团客户 72 / 上市集团 20，可叠加（上市公司 880、集团客户 796、上市集团 972）。程序不自行推测：独立上传由任务必选，对接信贷由跳转参数「是否上市」「是否集团」提供；参数缺失时先按 724 条跑，其余规则写数据不足、原因「客户类型未知」。
2. 数据可得性（累计）：仅定期报告 279 条（P0 覆盖 32%）→ ＋年报附注 770（90%）→ ＋外部数据 962（99%）→ ＋现场尽调 972（100%）；与适用对象交叉成矩阵（如普通对公仅定期报告 223/51，上市集团全量 972/214）。
3. 业务前置：19 类业务（并购商誉、制造业存货、境外业务等）不开展即标「不适用」，不计分母、不占清单，共 198 条。
4. 规则类型：量化检查 481（全自动）、勾稽校验 166（全自动）、定性判断 136（模型初判＋人工复核，报表外证据必须人工）、归因分解 26（全自动）、认知原则 41 与阅读方法 122（其中 NOSCORE 的 27/84 条移出执行队列做成检查清单/阅读引导，带阈值的照常判定）。是否参与打分只看判定形态：NOSCORE 111 条不打分，其余 861 条参与判定与打分。

阈值五形态：RATIO 连续比率分档、IDENT 勾稽等式超容差即异常、STATE 条件成立与否、COUNT 发生次数/连续期数、NOSCORE 不打分。

3.4 判定引擎与容差

阈值引擎用受限表达式语言描述规则——只允许调用白名单函数，不能执行任意代码。容差双口径：恒等式类用 1% 容差；近似勾稽关系用偏离度与跳变双阈值——偏离 10pp 判关注、20pp 判重点关注，相邻两期跳变 15pp/30pp 同理；只有两期数据的公司只判偏离不判跳变。

判定结果的完整性：结果须包含该客户、该套材料下应跑的每一条规则（未触发的行也要在内，问题密度与「数据不足有几条」都要看）；每行至少有规则编号、状态、实测值、实测标题、实测依据，关注/重点关注还要写越线方向（由判定引擎按当前实测值与阈值比较写回，比较不出记「无方向」，议题名第三层直接使用）。完整性校验：写回的编号集合须与规则库版本完全一致，缺一条、多一条都不收——分析状态记「生成失败」、自动重试一次、仍失败即停止不展示任何评级。NOSCORE 111 条状态一律写「不适用」、原因「不打分规则」（不得写成数据不足，否则虚增待补录）；定性判断暂不能初判的写数据不足、原因「定性项待人工判定」；创建分析实例时校验规则库版本须「已发布」且条数与登记一致，不得以空规则集输出「无风险」。

3.5 议题聚合

按 43 个事实域聚合（有规则的事实域 42 个；F12 法定公积计提挂 0 条规则不生成卡不出现在任何页面；事实域只用于合并议题，与十个风险域不是一回事）。同域触发规则合并为一个议题；卡片优先级取组内状态等于卡片等级的规则中的最高优先级（不能取全组最高，防止 P1 重判从 P0 轻判借权重）；未归入事实域的 191 条规则（可打分 141 条）单独成卡、一条一张。主规则决定议题名、所属风险域与判读字段（先取状态等于卡片等级的最高优先级，再取规则条数最多的域，再取编号最小）；跨风险域的卡片只在主规则所属域出现一次，另一域明细注明「已并入议题卡」可跳转；卡片排序依次比较严重程度 → 卡片优先级 → 触发规则条数 → 主规则编号。868 个议题簇只用于选图去重，不用于卡片合并。

3.6 评分与分档

三条相互独立的轴取中间档（任一轴单独拉满升不了档，必须两条同时到位；卡在切点上算高的一档；无触发卡片时问题密度记 0% 算低）：

三轴都按合并后的卡片计、不按规则条数；通过、数据不足、不适用、不可执行不进分子分母。档位与行动建议一一对应：低·可准入，中·可准入·加强监控，高·审慎准入，极高·不建议新增授信；任一重点关注事项触发时行动建议覆盖为「不建议准入」。加权分（重点关注 P0=6/P1=3/P2=1，关注 P0=2/P1=1/P2=0.4）按卡片计一次，不参与定档、不用于排序，只在传给模型时标明轻重、页面不显示。数据不足分档：占比 ≥ 50% 或必查规则中 ≥ 30% 数据不足 → 「无法评级（数据不足）」、授信建议「待补充资料」；20%–50% 照常评级加橙色提示；< 20% 照常。提示与核心结论首句由系统固定写（不交给大模型）；全部规则数据不足时直接显示「无法评级」。

3.7 重点关注事项（八条一票否决）

八条规则写明「直接排除/暂停授信」，不参与打分、单独判定位，触发即覆盖结论为「不建议准入」，优先级高于评分。按可判定程度分三类：自动三条（货币资金五类反常 U-0171 下挂 U-0166~0170、非标准审计意见 U-0717 下挂四条、现金流肖像排除型 U-0593——直接取最新一期经营/投资/筹资净额符号，排除型三种：大出血 −−−、骗吃骗喝 −++、混吃等死 −+−，不读下挂规则状态）；待确认三条（单点异常全面核验 U-0092、重大疑点存疑即排除 U-0773、无法解释的重大突变 U-0867——机器不预判、始终先显示「待人工确认」，评审点「核查后仍无法解释·否决」并填理由才触发，不操作就一直是待确认、任何时候不显示「未触发」）；未接入两条（高风险行业不计提存货跌价 U-0213——需存货跌价多期序列＋行业风险等级两类数据，其本身仍作为普通比率规则照常判定计提率；变相抽回注册资本 U-0406——需其他应收款按对手方拆分明细等三类数据）。「未接入」必须明确显示为「数据未接入」而非「未触发」——后者等于替公司声明查过了没问题；自动闸只许人工推翻（填理由留痕）、不许人工手动落闸；触发后不停止其余规则执行；与数据不足提示同时出现时两条都显示、否决在上。

3.8 图表体系

38 条图表定义覆盖 34 个事实域（四个域各两张），全部程序生成（序列只允许取数据层）。三道出图筛子：排除 NOSCORE 规则（111 条，带阈值的照常参与选图）、排除二值 STATE 判据（111 条）、同一议题簇（868 簇）只画一张且出在触发最多的维度页。图型匹配判据：走势拐点→折线、同向背离→并列柱、总量构成→横条、年内分布→分季柱、与基准距离→折线加基准线。折线图带阈值带（黄区/红区，双向阈值都渲染，阈值线参与纵轴范围）。出图条件＝该事实域有触发规则＋至少一条序列有非空、非零的数（全 0 不出，防缺数填 0 误判）；各公司实际渲染 11~34 张；43 个事实域中 9 个不单独出图（8 个无序列：对外担保、关联方交易、法定公积、人工成本、流动性比率、披露充分性、现金流勾稽、客户与供应商集中；递延所得税挂在税负域下）。行业均值不画进图（只有一年构不成对照），单期对照放总览指标卡。图下判读三行由程序现算（最新读数对比、触发条数与最重规则、通用读法），不调用模型。

3.9 大模型判读与结论文案

分工边界：议题聚合、风险评级、授信分项档位由系统计算（人工判定保存即自动刷新）；核心结论标题/行动建议/正文/总体判断、授信六项文案、放款前核查清单、议题卡判读三段、十个风险域本域结论两行由大模型生成。触发时机：审核完成后第一次自动跑 + 规则库页人工补充后点「大模型重算」。

判读三段：归因（数怎么变成这样，收入类补分产品分地区变动）→ 定性（取规则库风险指向字段）→ 处置（取处置动作字段）。定性与处置两段必须逐字包含对应规则字段的原句，程序按原句是否出现检查，不出现即判生成失败、卡片改用规则原句拼装；归因首句三级回落（实测结论句 → 计算口径展开 → 不写首句）。

议题名三层回落（全部系统生成、评审不修改）：① 大模型本案议题名（≤ 16 字、必须含卡片关键指标数值且逐字出现在实测依据中、结论措辞方向与阈值判定一致、程序校验长度/数值/禁用词/方向词，不过即回落）→ ② 事实域结论名（43 个固定配置表，如 F06「控股股东质押偏高」）→ ③ 主规则检查项＋越线方向词（高于上限补「偏高」、低于下限补「偏低」，无方向只写检查项）。

结论文案五条硬约束（写在提示词里）：只使用给出的事实和数字，不得编造；人工判定优先于系统原判定；授信六维文案必须与系统算好的档位一致；触发重点关注事项时结论必须是不建议准入；只输出固定字段的 JSON 对象。档位措辞约束：综合档与六维各档均规定允许写/禁止写的说法（如「不建议准入」禁写可准入、风险可控；存量授信「压降」禁写可提额），程序逐项检查，判词前一字为「无不未勿非」时不算命中；数据不足的维度只许写「数据不足，待补录后判定」；档位为空时固定写「档位未形成」。正文与核查清单都有系统兜底文案，大模型成功后整段覆盖；报告状态三态——生成中、已完成、生成失败（不展示任何评级）。

四、与信贷系统的集成

统一发起（新）：客户经理在授信作业中心提交业务（业务流水号、提交批次版本、客户及流程上下文）→ 调查报告为完成状态且业务提交成功时，信贷系统调起「小查与审查意见生成统一发起接口」（财务分析与制度解析由同一接口调起）→ 系统经「调查报告文件索引查询接口」向影像平台查询并下载该业务最新版调查报告 → 获取成功后执行财务分析，数据一次取齐（财务要素从客户中心、外部工商与舆情走企查查接口），执行过程中不重复拉取 → 授信作业中心查询完成状态、查看结果。审批退回后重新提交时再次调用统一发起接口，重新拉取最新调查报告覆盖本地暂存版本并重跑，历史执行日志保留用于审计；审批拒绝则业务结束。

评审跳转：审批单财务分析环节放入口，新窗口带参跳转 + 单点登录——bizNo 审批单号、custId 客户标识、opId 操作员、token SSO 票据、ret 返回地址（必填）；period 分析期间（缺省取最新完整年度）、isListed／isGroup 是否上市/集团（决定适用对象）、ctrlBirthYear／chairBirthYear／ceoBirthYear 三项出生年份（信贷系统按关联人身份证号算出后只传年份不传身份证号，供 U-0972）、scene 默认进入场景（可选）。选择跳转而非内嵌——本系统左栏十余个视图，嵌在面板里挪不开。不自建账号体系，权限沿用信贷系统客户可见范围。

数据：三表主体科目自动取自行内已审批的尽调报告；附注明细自动 OCR + 人工补录；外部工商数据接口自动，未接通时如实显示未接入。科目对照：合并三表 56 个科目、附注 13 项、母公司与分季度 6 项须由数据方填科目编码，名称对不上编码的序列不出图；增值税率按公司主营取参数（软件与服务 6%、农产品 9%、多数货物 13%），取不到时收现比只画不含税口径。

结论回写：评审确认后结论摘要（风险卡片）回写审批单财务分析栏（按 bizNo 定位）。

五、行业数据与外部接口

行业均值表（数据方提供）：国标行业小类 × 上市板块共 22 个行业小类，各公司比率简单平均；表内 14 个指标中 5 个可与规则直接比对、驱动 10 条行业比较规则（ITR 存货周转率 3 条、TAR 应收周转率 3 条、GRP 毛利率、ROE、营收/净利润增长率），其中 ITR/TAR 共 5 条「无可比样本时退自身近三年均值（至少三期）」、其余无兜底缺数即数据不足；ROA_TA 口径不明（U-0646、U-0507、U-0542、U-0647 四条保持数据不足）、ICR 仅 2 行有数、ALR/ROL 在规则里只有绝对阈值。行业均值表只用在两处：10 条规则的判定 + 总览指标卡的对照基准；只认同一会计年度、行业归属须写依据、卡上标明「行业均值」。

企查查接口（取与规则清单的交集，7 个 P0 必查）：被执行人详情 IQCC002（U-0968 红档「存在被执行记录」＋涉诉金额÷净资产 > 5%）；失信详情 IQCC001/047（同上）；股权出质 IQCC033＋069（U-0968 实控人股权出质率 > 60%、U-0862、U-0938）；股权冻结 IQCC037＋036（U-0938 司法冻结、U-0968）；行政处罚详情 IQCC008＝038（U-0767 红档处罚性质与整改状态）；破产重整 IQCC007＝053（U-0758 红档已进入破产重整程序）；企业对外投资核查 IQCC039＋081 穿透（U-0962 子公司清单工商核对）。

附录：A 38 张图逐图规格（数据层要求、事实域、序列口径、阈值带、图下判读、关联 P0 规则）；B 科目与字段对照；C 不打分与动线规则清单（74/37/35 条）与 43 个事实域结论名。

7.1.4 - 财务风险分析系统详细设计与实施方案

依据《财务风险分析系统需求文档（0924）》编制。本页是多智能体财务分析系统 PoC 的详细设计与实施方案——先跑通"数据层归集 → 规则判定 → 议题聚合 → 评分分档 → 图表与判读生成 → 结论文案生成 → 质量检查"七环节全链路，为行内落地探路。需求口径详见10 财务风险分析章。

一、定位与范围

目标：交付一个可运行的 PoC——样本公司数据 + 种子规则集 + 真实 LLM 调用，验证多智能体协作架构、判定可复算性、五条硬约束的可行性。不受行内技术栈约束，但选型与行内《综合智慧信贷 AI 架构方案》同构，验证结论可直接迁移。

PoC 要验证的四个核心命题：

1. 判定、聚合、评分全部由代码计算，每条结论可追溯到实测数值、阈值档位与规则编号；
2. LLM 只承担叙述与判读（判读三段、六项结论文案、核查清单），在五条硬约束下输出稳定 JSON；
3. 人工改判 → 档位即时刷新 →「大模型重算」→ 文案重写，这条核心交互链闭环；
4. 八条一票否决触发时评级被覆盖为「不建议准入」，且不停止其余规则执行。

明确不做（落地阶段再补）：信贷系统 SSO 与带参跳转、结论回写审批单（0924 待对齐点⑨在 PoC 中搁置，改为页面展示 + markdown/JSON 导出）、企查查接口、影像平台 OCR。外部工商舆情在数据层保留命名空间、以 mock 数据注入，未接入时如实显示「未接入」，不得显示为「未触发」。

二、总体架构

四层：评审前端（Vue3）、FastAPI 确定性服务层、LangGraph 多智能体层、数据与模型接入层。核心原则一句话：确定性计算走代码、Agent 不承担口径决策、LLM 只做叙述与判读并受硬约束。

全屏打开 ↗

关键设计决策（逐项经评审确认）：

三、分析流水线与重算回路

七环节中前四环（归集、判定、聚合、评分）与图表数据全部是确定性代码；后三环（判读、结论、质检）由 LLM Agent 承担，编排 Agent 负责调度。人工改判从评审复核泳道回流：改判保存 → 确定性结果即时重算 → 点「大模型重算」→ 判读与文案重写（只重写文案，不改档位）。

全屏打开 ↗

八条否决闸在评分后并行判定：触发即在结果上打覆盖位（结论变为「不建议准入」），但流水线继续走完——评审仍需要完整的判定明细；人工推翻必须填理由并留痕。

四、数据层设计

七个命名空间落为独立取数接口，规则只能从这里取数、不允许写死数字：

两家样本公司（5 年年度序列 + 附注 + 分季度 + 母公司报表 + 舆情 + 所在行业均值）：

• 健康厂：数据干净、少数触发、图少议题少——验证通过路径、低风险分档、「未披露」中性显示；
• 藏雷集团：预埋非标审计意见（一票否决）、存贷双高（F03 存贷利差）、应收与收入剪刀差（F21）、其他应收款长账龄占比（F09）、净现比持续低于 0.5（F38）、四季度利润塌陷（F19）——验证否决覆盖、图多议题多、退回重写路径。

五、规则库与判定引擎

17 字段结构全量落地（编号、风险域、检查项、计算口径、阈值、判定、实测依据、优先级、实测标题等），种子集构成策略：

1. A.01–A.38 图规格反推：38 张图点名的约 150 个 U-XXXX 规则优先编入，阈值直接取图规格（如现金短债比黄 1 / 红 0.5、有息负债率黄 40% / 红 60%、应收剪刀差黄 5pp / 红 20pp）；
2. 勾稽恒等式：资产＝负债＋权益等（IDENT，1% 容差）；近似勾稽如「销售收现 ≈ 营业收入×(1+增值税率)」（偏离 10pp 判关注、20pp 判重点关注；跳变 15pp/30pp；仅两期数据只判偏离）；
3. 八条否决：自动三条（货币资金五类反常、非标审计意见、现金流肖像排除型）+ 待确认三条（立待办）+ 未接入两条（如实显示）；
4. 行业比较 10 条：5 条有兜底（无可比样本退自身近三年均值、至少三期），5 条无兜底缺数判「数据不足」。

覆盖约束：10 个风险域每域 ≥5 条、代表事实域每域 ≥2 条、RATIO/IDENT/STATE/COUNT/NOSCORE 五形态齐备、P0/P1/P2 三级齐备。

判定引擎：自建受限表达式语言——只允许白名单函数（prev 取上期、yoy 同比、share 占比、ratio 比值、streak 连续期数、avg3y 近三年均值、industry 行业均值等），编译为 AST 解释执行，不能调用任意代码。每条规则输出：判定（重点关注/关注/通过/数据不足/不适用）+ 实测依据（算式与科目金额，可对上计算口径）。四层筛选（适用对象、数据可得性、业务前置、规则类型）在执行前收窄规则集，不适用条目不计分母、不占清单。

六、议题聚合与评分

• 议题聚合：按 44 事实域（种子集覆盖约 15 个代表域）聚合，同域触发规则合并为一个议题，议题卡标明「本议题同时触发 N 条规则，已合并计为 1 项」。严重度取组内最重判定；优先级取实际判了重点关注的那条规则的优先级（不取全组最高，防止 P1 重判从 P0 轻判借权重）。
• 评分三轴取中位数：重大问题数（必查项重点关注议题数）、问题密度（触发议题占已判定规则比例）、加权分（重点关注 P0=6/P1=3/P2=1；关注 P0=2/P1=1/P2=0.4）。三轴中位数映射极高/高/中/低四档。
• 否决覆盖：八条否决独立判定位，优先级高于评分，触发即结论覆盖为「不建议准入」。

七、图表体系

38 条图表定义全部落为数据驱动 spec（事实域、图型、序列、序列取数口径、阈值带、读法文本），序列只允许引用数据层命名空间。渲染层：Vue3 + ECharts 封装，折线阈值带用 markArea（黄区/红区，双向阈值都渲染）、阈值线参与纵轴取值范围。

• 出图条件（每次渲染重算）：该事实域至少一条规则判重点关注或关注（按人工复核后状态计）＋ 落在触发最多的维度页（触发数相同取规则数多的，再相同按导航顺序）＋ 至少一条序列取得到非空非零的数；
• 页内排序：按 P0 触发数、重点关注数、关注数依次降序；
• 图下判读三行由程序现算：最新读数与上期对比（有阈值带的加一句相对阈值线位置）、本域触发条数与最重规则（可点击跳转规则库）、规则库通用读法（标「读法」）；
• 8 个无数值序列的事实域（对外担保、关联交易等）不出图；渲染验证选 12–15 张代表图，其余 38 条定义 correctness 由 spec 单测保证。

八、多智能体设计

全屏打开 ↗

五条硬约束：只用给出的事实和数字；人工判定优先于系统原判定；授信六维文案必须与系统档位一致；触发重点关注事项时结论必须是不建议准入；只输出固定字段的 JSON 对象。质检不过由编排退回重写（附违规项），最多三次；仍不过则降级为模板文案并标注「模型生成未通过质检」——禁止带病发布。

LLM 网关：OpenAI 兼容抽象层，RECORD/REPLAY 两种模式——录制模式把 (模型, 提示词哈希) → 响应存入 fixtures；回放模式直接命中缓存，回归测试零 token、结果可复现。温度取低值并使用结构化输出。

九、前端设计

分析任务为长任务（规则数百条 + 多次 LLM 调用），API 以任务 id + SSE 推送进度；前端按环节显示流水线状态。

十、工程结构与实施方案

finrisk/
├── backend/app/
│   ├── models/       # SQLModel：公司/事实/派生/分季/母公司/外部/行业均值/规则/判定/议题/留痕
│   ├── datalayer/    # 七命名空间取数接口（唯一取数通道）
│   ├── rules/        # 规则库加载、四层筛选
│   ├── engine/       # 表达式语言（白名单函数 + AST）、五形态判定、双容差
│   ├── aggregate/    # 议题聚合、三轴评分、八条否决
│   ├── charts/       # 38 图 spec、出图条件、图下判读三行
│   ├── agents/       # orchestrator / readers / writer / qc（LangGraph）
│   ├── llm/          # OpenAI 兼容网关、录制回放
│   └── api/          # FastAPI 路由 + SSE
├── backend/data/     # 种子规则库（YAML，数据驱动可增量）
├── backend/fixtures/ # LLM 录制回放
├── backend/tests/    # 判定引擎与聚合的黄金用例
├── frontend/         # Vue3 + Vite + TS + ECharts
└── samples/          # 两家样本公司数据（健康厂 / 藏雷集团）

里程碑：

验收标准（对应四个核心命题）：①任一条判定点开可见实测数值、阈值档位、规则编号；②结论 JSON 通过 Schema 与质检三道校验，六项文案与档位一致率 100%；③人工改判保存后档位与评级即时刷新，「大模型重算」只改文案不改档位；④藏雷集团评级被否决覆盖为「不建议准入」且判定明细完整。

风险与对策：LLM 输出 JSON 不稳定 → 结构化输出 + 三次重试 + 模板降级；图规格反推的规则口径与行内真实规则库有偏差 → 种子集逐条标注来源（图规格/需求原文），真实规则库到位后按 17 字段导入替换；两家样本覆盖不了中间态分档 → 数据 schema 支持随时增补第三家公司。

十一、术语表