金融市场

• 1: 新一代资金交易管理系统架构总览
• 2: 新一代资金交易管理系统数据移植方案
• 3: 配合系统建设架构方案
• 4: 新资金交易管理系统适配改造方案

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 日迁移完成后经科目余额表逐级核对，确保存量数据准确、完整、无差异迁入，不影响日终批量与账务连续性。

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 - 配合系统建设架构方案

本文档总结自《新一代资金交易管理系统项目配合系统建设架构方案》（提出部门：金融市场部；所属部室：中台产品开发室；项目经理：郭园 / 邱帅；需求经理：邱帅；架构方案负责人：李彬；需求输出时间：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 / 中间件 / 数据库 / 终端 / 外设）与兼容性验证结果、数据迁移模板与投产切换脚本、接口平迁的双向确认流程基线。

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 日：资产余额核对、资产与科目一致性验证、外部登记托管机构（中债登 / 上清所）余额核对、双轨比对收口。

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

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