文档

• 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.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: 受害人精准拦截业务需求
  • 4.2: 受害人精准拦截技术实现方案
• 5: AI
  • 5.1: 综合智慧信贷
    • 5.1.1: 智能信审平台业务架构
    • 5.1.2: 综合智慧信贷 AI 架构方案
    • 5.1.3: 智能信审平台需求文档
      • 5.1.3.1: 总体概述
      • 5.1.3.2: 业务架构与端到端流程
      • 5.1.3.3: 悬浮按钮与任务管理
      • 5.1.3.4: 风险检查（小查）
      • 5.1.3.5: 类案对比（小审）
      • 5.1.3.6: 审查报告
      • 5.1.3.7: 智能审核（小核）
      • 5.1.3.8: 评价分析
      • 5.1.3.9: 对外交互方案
  • 5.2: 星辰智能
    • 5.2.1: 结算类凭证要素核验需求规格说明书
• 6: 其他
  • 6.1: 简介
    • 6.1.1: 项目概览
    • 6.1.2: 架构
  • 6.2: 快速上手
    • 6.2.1: 前置条件
    • 6.2.2: 安装
  • 6.3: 教程
    • 6.3.1: 完成第一次修改
    • 6.3.2: 添加文档页面
  • 6.4: 参考
    • 6.4.1: 配置
    • 6.4.2: 命令参考

1 - 智慧信贷

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

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

1.1 - 业务架构

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

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

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

依据《智慧信贷项目业务架构说明书》第七部分。额度是授信决策向业务执行传递信用风险边界和业务资源约束的核心业务对象——授信审批回答"是否给予信用、给予什么条件"，额度管理则将批复结果转化为可持续查询、校验、占用、释放和调整的业务资源。

额度体系承担五项业务作用：将授信批复结构化为可持续管理的额度；在客户、集团、产品、项目及风险承担主体之间建立统一额度关系；为合同、放款及专业交易提供可用额度校验和占用依据；支持额度全生命周期管理；通过限额、分组和双占/多占机制将单笔业务风险纳入客户和组合层约束。

额度分类与对象结构

额度体系从"授信主体"和"风险管控对象"两个层次组织：

• 主体类额度：围绕具有独立客户身份并承担信用风险的主体形成，包括集团客户额度、对公客户额度、同业客户额度、个人客户额度，持续反映银行对某一客户或客户集团承担的总体信用风险。
• 专项主体及场景类额度：SPV 额度（独立风险承担特征的专项主体）、集群额度、项目/合作方等场景类额度，可与客户主体额度形成双占或多占关系。

各类额度均属授信额度对象体系下的业务子型或场景化安排，不因客户类型、业务场景或额度层级差异而新增独立核心业务对象。

额度层级遵循"上层汇总管控、下层承载具体业务"：上层形成客户或集团总体风险视图和总量控制，中间层区分综合授信、专项授信、非授信、业务专项、风险等级等信用用途，最末级额度直接对应具体产品、业务方案、项目或可实际占用的风险资源。层级表达风险资源的归集约束关系，不代表每层都需独立审批。

对公客户额度体系

以法人客户为统一管理主体，形成法人客户总额度，区分母行额度与并表机构额度（后者反映集团内相关机构对同一客户形成的信用资源，形成全口径授信视图）。

母行额度按业务性质划分三类：

• 综合授信额度：基于客户综合偿债能力的经营周转类信用安排，分项之间允许共享统筹，上层承担总量控制，业务落到最末级额度使用；
• 专项授信额度：用途专用、项目收益特征明显的信用安排，专项之间原则上独立；
• 非授信额度：委托贷款、合作方非授信、供应链非授信等管理性额度，部分通过审批形成，部分由实际业务反向汇总形成。

对公额度实行授信金额与敞口双维度管理：授信金额反映允许使用的业务规模，敞口金额反映实际承担的信用风险（因担保方式、保证金、第三方风险承担而差异），可用空间、占用、释放与集团汇总均需同时考虑两个维度。实际使用以最末级额度为承载单元，多个独立项目或业务安排通过业务方案区分。

同业客户额度体系

以金融机构客户为统一管理主体，由同业客户总额度、母行额度和并表机构额度形成统一风险视图。母行额度按票据、贸易融资、金融市场等专业业务形成专项额度，专项额度下按风险等级组织信用资源，产品根据风险等级及额度映射规则使用额度。模式概括为：客户统一授信、专项分类管理、风险等级控制、专业业务用信。

个人客户额度体系

不采用对公式客户统一授信方案，额度以单笔业务批复为基础形成；客户层汇总各笔有效业务额度形成总体信用视图（项目范围外的其他个人业务额度可作为全口径汇总信息进入视图）。客户层风险限额包括个人客户总限额、信用限额和保证限额，构成风险上界约束。个人经营贷及场景型业务可同时受集团、合作方、集群或项目额度约束。

集团客户额度体系

以集团客户为最高统一风险管理单元，形成集团总额度，汇集成员的对公、同业及适用的个人经营类信用资源。三层机制：

• 集团总量与成员额度：集团额度控制整体信用风险上限，成员额度反映自身授信安排，成员业务同时受两层约束——统一识别集团风险而不取消成员自身管理；
• 分组额度：按成员集合、经营机构或业务板块分组并设置授信金额与敞口控制，属于集团内部限额，不替代成员授信；
• 预留额度：为新增成员或新增融资需求预留信用空间，在集团风险边界无实质变化时可领用分配，减少频繁发起整体授信调整；领用和恢复在集团额度体系中持续记录。

额度生命周期管理

额度是具有持续生命周期的业务对象：额度形成 → 生效/启用 → 查询与校验 → 占用 → 调整/冻结 → 释放/恢复 → 到期/失效/结清。

• 形成：授信审批形成（依据批复建立/调整）或业务反向汇总形成（依据已发生业务事实形成管理额度并向上汇总），两类均进入统一额度视图；
• 生效与启用：“额度已批复"与"额度可实际使用"是不同状态，需落实放款前条件的额度须完成启用；
• 占用与释放：合同、放款或交易对最末级额度占用；上层额度不重复记录每笔占用，而是根据下层占用形成汇总视图；还款、结清后按是否循环及业务规则释放或恢复；
• 变更、续作与调整：承接新授信结果的同时保留存量业务关系，确保能解释已发生业务、剩余可用空间和后续约束；
• 冻结与解冻：重大风险事件、条件未落实或风险预警触发时冻结，不改变已形成的授信事实但限制新业务使用；
• 到期、失效与结清：失效后不允许新增使用，已发生业务按合同和贷后要求继续管理。

双占与多占管理

单笔业务可能同时占用多个对象或层级的额度：集团成员业务同时受成员额度和集团额度约束；供应链/合作方/集群业务同时占用融资客户自身额度和关联主体/项目额度；票据、贸易融资业务同时涉及交易客户和承兑人、开证行、担保人额度；SPV 业务同时占用 SPV 额度和担保人、差额补足人、增信方额度。

额度管理不仅记录"占用了多少”，还要记录"占用了哪个主体、哪一类额度以及占用关系为何成立"。双占多占将单笔业务风险传导到所有实际承担风险或负有管理责任的对象，是统一授信和穿透风险管理的重要机制；它属于额度对象体系内部的业务关系，不新增独立核心业务对象。

与限额管理的分工

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

1.1.5 - 客户管理体系

下载矢量版 SVG

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

总体结构

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

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

客户主体体系

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

客户信息统一管理

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

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

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

客户关系与群组管理

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

管户责任与权限

客户权限分三层：

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

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

客户及业务移交

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

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

分类、标签与名单

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

客户统一视图

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

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

客户生命周期

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

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

1.1.6 - 押品管理体系

下载矢量版 SVG

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

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

总体结构：五层组织

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

押品目录与管理规则

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

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

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

押品信息与统一识别

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

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

押品价值管理

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

担保关系与风险缓释使用

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

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

权证与抵质押登记管理

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

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

持续监控与风险管理

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

押品生命周期与处置协作

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

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

与其他领域的协同

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

1.1.7 - 产品管理体系

下载矢量版 SVG

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

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

总体结构：五层组织

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

产品目录体系

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

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

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

产品条件、要素与组件化

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

适用范围与场景化配置

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

与业务执行资源的协同

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

建立测试与发布

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

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

版本与变更管理

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

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

四维状态与三档运营管控

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

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

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

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

生命周期与经营分析

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

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

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

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

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

1.2 - 应用架构

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

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

1.2.1 - 应用架构设计

下载矢量版 SVG

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

业务架构承接

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

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

应用架构总体结构：五层

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

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

20 个微服务清单

服务划分原则

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

服务依赖与调用约束

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

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

服务划分过程

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

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

数据库划分

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

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

微服务定级

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

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

微服务治理

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

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

应用架构图

全屏打开 ↗

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 - 风险防控

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

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

4.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 事中管控模型”。模型策略仍部署在事中交易监控平台，鹰眼侧仅展示与开关操作。

4.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 原有模式，零通道改造。

涉及系统改造清单

5 - AI

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

• 综合智慧信贷：综合智慧信贷项目的 AI 架构方案、智能信审平台业务架构与九章需求文档，含十五张交互式图表
• 星辰智能：结算类凭证要素核验需求规格（申请书 + 转账支票/进账单联合核验），含核验总流程、印章混合管线与系统架构三张交互式图表

5.1 - 综合智慧信贷

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

• 综合智慧信贷 AI 架构方案：业务、应用、技术、集成、部署、数据六个视图的架构总结，含九张交互式架构图（知识库、财务分析、制度解析与场景规则集技术架构）
• 智能信审平台业务架构：五大智能应用、四类底层能力、评价闭环与外部协同的业务架构全景
• 智能信审平台需求文档：依据 911 版软需与对外交互方案编制的九章需求文档，含业务功能架构、两条业务主线、放款智能审核时序与目录版本生命周期等六张交互式图表

5.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 拉取的调查报告仅本地暂存，不进知识库。
• 历史案例库：标准化历史审批案例，以业务摘要 + 统一打标组织，支撑类案对比的语义检索（业务摘要）与精确条件检索（统一打标）。
• 财务分析（建设中占位）：财报解析结构化与指标计算，支撑风险检查与审查意见生成；企查查数据经外部数据管理平台（EDS）获取，行业财务均值由企业知识平台经 ETL 工具同步（T+1）。

运行管理与任务模型

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

评价管理闭环

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

外部协同与交互模式

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

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

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

需求依据

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

5.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，支撑指标计算、风险分析与财务分析报告生成。

全屏打开 ↗

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

依据《政策文件解析需求规格说明书（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、发布与配置运维），其中【待定版】/【待测算】条目随评审逐块定版。

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

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

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

5.1.3.1 - 总体概述

1. 项目背景与系统定位

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

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

2. 建设原则与业务目标

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

3. 术语定义

4. 系统边界

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

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

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

6. 本章关联文档

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

5.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 对外交互方案

5.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 风险检查（小查）

5.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 类案对比（小审）

5.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 审查报告

5.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 智能审核（小核）

5.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 评价分析

5.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 对外交互方案

5.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（全屏 ↗）

5.2 - 星辰智能

星辰智能（Xingchen Intelligence）项目文档：

• 结算类凭证要素核验需求规格说明书：覆盖结算业务申请书与「转账支票+进账单」两个核验场景的完整需求规格——六张核验规则逐条映射、五态结论体系、印章识别混合方案与抽取自修复链，含核验总流程、印章管线与系统架构三张交互式图表

5.2.1 - 结算类凭证要素核验需求规格说明书

依据《AI 审核规则》及 vlagent 项目已实现的核验能力编制。本说明书覆盖结算业务申请书（单张/批量）与**「转账支票+进账单」联合核验**两个场景，规则与需求文档逐条对应（申请书 1.1–1.8、支票 2.1–2.12），并纳入实现过程中经业务确认的判定口径。

一、引言

1.1 目的与范围

为银行柜面结算凭证的人工审核提供 AI 辅助要素核验：识别凭证影像上的要素，按规则逐条给出结论与证据，供柜员快速定位问题。本说明书界定两个核验场景的功能与非功能需求；特种转账借方传票等票种为规划范围（规则文档 §3 占位），不在本期。

1.2 术语

1.3 参考文档

《AI 审核规则》（结算业务申请书 §1、转账支票+进账单 §2）；项目 CONTEXT.md 词汇表与 ADR-0001～0004。

二、总体描述

2.1 系统定位与流程

系统采用抽取-校验分离的两阶段架构：第一阶段完成要素收集与自修复（VLM 整图抽取 → PaddleOCR 印章增强 → 金额/账号复核 → 文本兜底），产出一册完整的要素总集；第二阶段由规则引擎对同一册证据逐条判定，输出五态结论。所有模型不确定性被限制在第一阶段，判定层完全确定、可单测、可审计。

全屏打开 ↗

2.2 系统架构

前端为核验工作台（上传、轮询、报告呈现）；FastAPI 后端编排两阶段管线；AI 服务包括 Qwen-VL 多模态（整图抽取与裁片精读）与内网 PaddleOCR（版面解析与印章定位）；证据（裁片文件、PaddleOCR 输出、校验明细）随记录落库可追溯。

全屏打开 ↗

2.3 结论体系（五态）

总体结论取全部规则的最严重态。

2.4 凭证上传要求

• 结算业务申请书：单面凭证，支持单张与批量上传（一次最多 5 张，逐张独立识别）；批量时逐张展示状态与结论，支持汇总（N 通过 / M 不通过 / K 待复核）与单张钻取。
• 转账支票+进账单：三件配套必传——支票正面、支票背面、进账单，缺一拒绝受理（无背面则背书核对无从做起，无进账单则跨单比对无从做起）；可选输入交易码（票号位数模式用）。

三、功能需求——结算业务申请书

规则与需求文档 §1.1–§1.8 一一对应；申请日期与进账单日期共用公共日期口径。

印章分类按证据判定：类型词/形状会被识别错（如方形名章被读作「圆形+测试专用章」），分类依「章文结构 + person_name/unit_name 互斥字段 + 形状」综合反推；票面有单位章时按单位口径（户名启发式可被章型证据纠正）。

四、功能需求——转账支票+进账单

三件联合核验，规则与 §2.1–§2.12 一一对应。支票正面/背面字段平铺合并，进账单整体挂 slip 命名空间。

说明文案要求（业务确认）：无论结论如何，说明中固定罗列检核用到的各要素（票面收款人、每手背书人（标注形式）与被背书人（含委托收款标记）、进账单收款人全称），未识别项标注「未识别」。

五、印章识别混合方案

整图 VLM 识别印章不可靠（计数幻觉、锚点挪用、示例污染），采用 PaddleOCR 定位裁片 + VLM 裁片精读：

• PaddleOCR 只负责检测印章位置并输出裁片；章文内容由 VLM 按统一印章解剖学口径精读单枚特写；其余字段维持整图抽取。
• 归属用表格结构与 bbox 几何（背面 x 向三区：附加信息 / 第 1 手 / 第 2 手），VLM 不参与。
• 三重透印过滤（两面通用）：低饱和淡红（颜色）、裁片框红墨覆盖率过低（稀疏透痕）、镜像反字（方向）任一命中即剔除。
• 章证优先：检出单位章即以其单位名称重推锚点并覆盖手写标志；手写保护——该手未检出裁片时整图结果原样保留（手写第一行锚点不清空）。
• PaddleOCR 失败优雅降级退回整图值；被剔除裁片仍落盘留证。

全屏打开 ↗

六、抽取自修复链（第一阶段）

所有修复仅发生在证据层，「发现缺口/矛盾 → 定向重读 → 能消解才采纳」：

七、接口需求

八、非功能需求

• 确定性：同一输入必出同一结论；规则层不调用任何模型。
• 可追溯：每条结论附说明与证据；印章证据附裁片文件地址；PaddleOCR 输出目录随记录落库。
• 降级：任一外部服务（VLM/PaddleOCR）失败不影响主流程出报告（退回可用证据，标注待复核）。
• 性能：单张凭证端到端（含两次 VLM 抽取 + 印章增强）目标 ≤60s；批量 5 张并行处理。
• 安全：全接口 JWT 鉴权；影像与输出文件按用户目录隔离。

九、附录

9.1 规划范围

• 结算业务申请书批量上传（≤5 张）前端交互与汇总展示（增量需求）。
• 特种转账借方传票（规则文档 §3 占位）、电汇凭证等新票种。
• PaddleOCR 能力服务化（ADR-0004：独立 OCR 标准化服务，方案已定案）。

9.2 版式先验

背面背书栏位三区/手间分界等几何先验按样本标定，换版式样本须复标；进账单金额位值表格解析依赖表格结构识别质量。

6 - 其他

暂未归类的内容。OINK starter 的示例栏目（简介、快速上手、教程、参考）保留在此作为主题语法参考，确认不需要后可整目录删除。

6.1 - 简介

第一次接触项目时，请从这里开始。

6.1.1 - 项目概览

请用对你的项目最短而有用的说明替换这一页。

要解决的问题

使用读者熟悉的语言描述问题。在读者理解项目价值之前，先不要陷入实现细节。

最终结果

说明用户采用项目之后，能够成功完成什么。

6.1.2 - 架构

记录贡献者在修改代码之前必须理解的少数组件。

系统地图

边界

明确项目刻意不负责什么。清晰的边界可以避免文档承诺软件并未提供的能力。

6.2 - 快速上手

从一台干净的机器开始，得到一个可以工作的本地结果。

6.2.1 - 前置条件

前置条件应当简短、精确，而且可以验证。

工具

• 受支持的操作系统。
• 用于获取源码的 Git。
• 项目所需的运行时版本。

验证

为每个前置条件提供一条验证命令：

$ project --version
project 0.1.0

发布前请把占位命令换成你的真实命令。

6.2.2 - 安装

首先给出最短且受支持的安装路径。

安装

git clone https://github.com/OWNER/PROJECT.git
cd PROJECT
./project start

确认结果

准确告诉读者成功是什么样子：要打开哪个网址、会看到什么消息，或者哪条命令应当返回零。

6.3 - 教程

跟随一个端到端任务，而不是只阅读彼此孤立的知识点。

6.3.1 - 完成第一次修改

这篇示例教程展示一项完整任务：准备、修改、验证与复查。

从已知状态开始

git status --short
git switch -c docs/first-change

只修改一件事

修改一个可见字符串或一个小配置值。第一次任务应足够聚焦，让结果一目了然。

验证

运行项目最小而相关的检查，然后打开修改过的界面亲自确认。

6.3.2 - 添加文档页面

在 OINK 中，内容树就是文档侧栏。新增一个 Markdown 文件，就会新增一个页面。

创建文件

---
title: 新能力
description: 这项能力做什么。
weight: 30
---

在这里说明这项能力。

将它保存为 content/docs/reference/new-capability.md。

添加翻译

在旁边创建 new-capability.zh.md 与 new-capability.fr.md。各语言的显式标题 ID 应当保持一致。

预览

运行 hugo server，打开新页面，再通过语言切换器检查每个译文。

6.4 - 参考

当你已经知道自己要查什么时，请使用这一栏目。

6.4.1 - 配置

请用项目真实的公开配置面替换这张小表。

示例

listen: 0.0.0.0:8080
log_level: debug
read_only: true

请在配置项旁边说明校验与优先级，不要把它们藏在另一份指南里。

6.4.2 - 命令参考

project start

启动本地服务。

project start [--config FILE] [--listen ADDRESS]

project check

只校验配置，不启动服务。退出状态 0 表示有效；任何非零状态都表示该配置不应部署。

project check [--config FILE]

请用真实 CLI 帮助输出中的命令替换这些占位内容。