智慧信贷

• 1: 业务架构
  • 1.1: 业务架构总览
  • 1.2: 授信模式
  • 1.3: 架构图集
    • 1.3.1: 业务架构总览图
    • 1.3.2: 授信模式体系
    • 1.3.3: 额度体系
    • 1.3.4: 客户管理体系
    • 1.3.5: 押品管理体系
    • 1.3.6: 产品管理体系
  • 1.4: 额度体系
  • 1.5: 客户管理体系
  • 1.6: 押品管理体系
  • 1.7: 产品管理体系
  • 1.8: 业务架构成果汇报（V1.4）
• 2: 应用架构
  • 2.1: 应用架构设计
• 3: 技术架构
  • 3.1: 技术架构设计
• 4: 集成架构
• 5: 部署架构
  • 5.1: 部署架构设计
• 6: 非功能需求

1 - 业务架构

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

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

1.1 - 业务架构总览

下载矢量版 SVG

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

总体结构：三类领域

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

11 领域与 40 组件

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

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

68 项核心业务能力

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

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

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

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

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

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

端到端场景与协作

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

关联专业能力与系统边界

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

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

1.2 - 授信模式

下载矢量版 SVG

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

总体结构

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

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

单一对公客户统一授信

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

核心机制：

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

集团客户统一授信

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

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

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

同业客户授信

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

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

个人信贷作业模式

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

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

SPV 及专项授信

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

与核心业务架构的关系

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

1.3 - 架构图集

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

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

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

1.3.1 - 业务架构总览图

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

全屏打开 ↗

1.3.2 - 授信模式体系

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

全屏打开 ↗

1.3.3 - 额度体系

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

全屏打开 ↗

1.3.4 - 客户管理体系

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

全屏打开 ↗

1.3.5 - 押品管理体系

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

全屏打开 ↗

1.3.6 - 产品管理体系

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

全屏打开 ↗

1.4 - 额度体系

下载矢量版 SVG

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

额度分类与对象结构

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

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

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

对公客户额度体系

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

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

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

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

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

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

占用、释放与串用：

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

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

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

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

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

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

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

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

同业客户额度体系

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

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

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

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

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

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

个人客户额度体系

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

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

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

集团客户额度体系

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

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

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

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

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

SPV 与集群额度体系

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

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

额度生命周期管理

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

双占与多占管理

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

限额管理

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

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

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

额度中心公共服务

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

附：业务架构视角结构图

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

下载矢量版 SVG

1.5 - 客户管理体系

下载矢量版 SVG

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

总体结构

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

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

客户主体体系

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

客户信息统一管理

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

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

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

客户关系与群组管理

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

管户责任与权限

客户权限分三层：

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

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

客户及业务移交

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

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

分类、标签与名单

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

客户统一视图

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

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

客户生命周期

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

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

1.6 - 押品管理体系

下载矢量版 SVG

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

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

总体结构：五层组织

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

押品目录与管理规则

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

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

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

押品信息与统一识别

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

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

押品价值管理

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

担保关系与风险缓释使用

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

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

权证与抵质押登记管理

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

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

持续监控与风险管理

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

押品生命周期与处置协作

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

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

与其他领域的协同

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

1.7 - 产品管理体系

下载矢量版 SVG

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

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

总体结构：五层组织

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

产品目录体系

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

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

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

产品条件、要素与组件化

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

适用范围与场景化配置

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

与业务执行资源的协同

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

建立测试与发布

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

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

版本与变更管理

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

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

四维状态与三档运营管控

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

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

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

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

生命周期与经营分析

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

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

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

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

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

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

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

方法论：TOGAF ADM 三阶段

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

架构成果构成：四要素

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

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

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

重构一：授信额度体系

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

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

重构二：集团客户管理

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

重构三：授信作业体系

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

风控决策引擎升级

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

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

AI 与智能化

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

业务建模成果

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

调研与需求成果盘点

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

承接转化

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

架构图

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

全屏打开 ↗

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

全屏打开 ↗

2 - 应用架构

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

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

2.1 - 应用架构设计

下载矢量版 SVG

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

业务架构承接

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

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

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

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

应用架构总体结构：五层

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

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

20 个微服务清单

服务划分原则

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

服务依赖与调用约束

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

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

服务划分过程

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

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

数据库划分

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

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

微服务定级

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

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

微服务治理

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

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

AI 与智能化应用

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

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

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

一期已建能力承接

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

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

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

应用架构图

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

下载矢量版 SVG

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

全屏打开 ↗

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

全屏打开 ↗

3 - 技术架构

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

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

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 次）；人工处理支持手工重试补偿与强制标记补偿结束。

技术架构图

全屏打开 ↗

4 - 集成架构

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

5 - 部署架构

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

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

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

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

全屏打开 ↗

6 - 非功能需求

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