清算结算系统设计文档

文档类型：系统设计实战
难度级别：架构师面试级
设计范围：多机构、多币种的清算结算系统
创建日期：2026-04-13

---

一、需求分析

1.1 面试场景

"请设计一个支持多机构、多币种的清算结算系统，处理第三方支付平台与银行、商户间的资金清分和结算。"

1.2 需求澄清（10个关键问题）

1.3 功能需求

1.4 非功能需求

1.5 业务场景

场景一：第三方支付清算

• 支付平台每日汇总商户交易，计算手续费分润，生成结算指令
• 特点：笔数大、金额相对小、T+1结算

场景二：跨行清算

• 银行间资金往来通过CNAPS大额/小额系统清算
• 特点：金额大、实时性要求高（大额实时、小额批量）

场景三：跨境清算

• 通过SWIFT或CIPS处理跨境汇款清算
• 特点：涉及外汇兑换、时区差异、合规筛查

场景四：证券清算（DVP）

• 证券买卖的券款对付，T+1或T+2交收
• 特点：券和款必须原子化交割，涉及中央对手方(CCP)

---

二、高层架构设计

2.1 C4 Context（系统上下文）

清算结算系统位于金融基础设施的核心位置，与以下外部系统交互：

架构图详见 diagrams/c4-context.mmd

2.2 C4 Container（容器视图）

系统拆分为以下容器（服务）：

架构图详见 diagrams/c4-container.mmd

2.3 清算核心流程

交易采集 → 数据校验 → 清算分组 → 轧差计算 → 结算指令生成 
    → 头寸检查 → 资金划拨 → 回执确认 → 对账 → 报表

详细流程说明：

1. 交易采集：从支付系统拉取当日交易数据，去重后写入清算库
2. 数据校验：完整性校验（必填字段）、合规筛查（制裁名单）、业务规则校验（限额）
3. 清算分组：按币种、参与机构、清算类型分组，形成清算集合
4. 轧差计算：对每个清算集合执行轧差，计算各参与方净额
5. 结算指令生成：根据轧差结果生成结算指令，按通道拆分
6. 头寸检查：校验付款方头寸是否充足，不足则触发预警
7. 资金划拨：通过选定通道（CNAPS/CIPS）发送结算指令
8. 回执确认：接收通道回执，更新结算状态
9. 对账：清算数据与记账数据、银行数据核对
10. 报表生成：生成清算日报、监管报表

序列图详见 diagrams/sequence.mmd

---

三、数据模型设计

3.1 核心表结构

clearing_batch（清算批次）

clearing_instruction（清算指令）

netting_result（轧差结果）

settlement_order（结算指令）

position（头寸）

fx_rate（汇率）

reconcile_result（对账结果）

3.2 状态机设计

清算批次状态机

CREATED → COLLECTING → VALIDATING → NETTING → SETTLING → RECONCILING → COMPLETED
                ↓            ↓           ↓          ↓                       
             FAILED       FAILED     FAILED     FAILED      
                                                   ↓
                                            PARTIAL_SETTLED

结算指令状态机

CREATED → POSITION_CHECKED → SUBMITTED → ACCEPTED → COMPLETED
             ↓                    ↓           ↓
         INSUFFICIENT         REJECTED     TIMEOUT
             ↓                    ↓           ↓
          QUEUED             RETRY/FAILED   RETRY

状态机详见 diagrams/state-machine.mmd

---

四、核心组件详细设计

4.1 轧差计算引擎

轧差是清算系统最核心的算法，直接影响资金效率和系统复杂度。

4.1.1 逐笔清算（Gross Settlement / RTGS）

原理：每笔交易独立结算，不做抵消。

适用场景：

• 大额支付（单笔>5000万元，通过CNAPS HVPS）
• 证券交割（DVP）
• 紧急汇款

特点：

• 优点：结算确定性强，无信用风险累积
• 缺点：资金占用大，需要充足的流动性

A → B: 1000万    → 实际划拨 1000万
B → A:  800万    → 实际划拨  800万
总资金流动: 1800万

4.1.2 双边轧差（Bilateral Netting）

原理：两个参与方之间的往来交易相互抵消，只结算净额。

适用场景：

• 两个银行间的日常往来清算
• 商户与支付平台间的日结

算法：

对于参与方A和参与方B:
  A→B的总额 = Σ(A支付给B的所有交易)
  B→A的总额 = Σ(B支付给A的所有交易)
  净额 = A→B总额 - B→A总额
  若净额>0: A付给B净额
  若净额<0: B付给A|净额|

效率：假设A和B各有1000笔互相交易，轧差后只需1笔结算。

A → B: 1000万
B → A:  800万
轧差后: A → B: 200万（净额）
资金流动减少: (1800-200)/1800 = 88.9%

4.1.3 多边轧差（Multilateral Netting）

原理：多个参与方通过中央对手方(CCP)进行轧差，将N*(N-1)/2对双边关系简化为N对关系。

适用场景：

• 支付清算所日终清算
• 银行间市场结算
• 期货/证券集中清算

算法（核心）：

Step 1: 计算每个参与方的净头寸
  对于参与方i:
    净头寸[i] = Σ(所有收入) - Σ(所有支出)

Step 2: 验证平衡
  Σ(所有净头寸) 必须 = 0（会计恒等式）

Step 3: 生成结算指令
  净头寸<0的参与方 → 付款给CCP
  净头寸>0的参与方 → 从CCP收款

效率分析（5个参与方的例子）：

原始交易:
A→B: 500, A→C: 300, A→D: 200
B→A: 400, B→C: 100, B→E: 200
C→A: 200, C→D: 300
D→B: 100, D→E: 150
E→A: 300, E→C: 100

逐笔清算: 12笔，总资金流动 2850
双边轧差: 10对关系 → 最多10笔结算
多边轧差:
  A: (400+200+300) - (500+300+200) = -100  → A付100给CCP
  B: (500+100) - (400+100+200) = -100      → B付100给CCP
  C: (300+100+100) - (200+300) = 0         → C无需结算
  D: (200+300) - (100+150) = 250           → D从CCP收250
  E: (200+150) - (300+100) = -50           → E付50给CCP
  验证: -100 + (-100) + 0 + 250 + (-50) = 0 ✓
  
  结算笔数: 4笔（3笔付款 + 1笔收款，跳过净额=0的C）
  总资金流动: 100+100+50 = 250（或从收款方看250）
  效率提升: (2850-250)/2850 = 91.2%

4.1.4 轧差效率对比

4.2 头寸管理

4.2.1 日间头寸实时监控

头寸变动触发点:
1. 入金：头寸增加
2. 清算扣款：头寸减少（先冻结，确认后扣减）
3. 清算收款：头寸增加
4. 手动调整：管理员操作

核心原则：可用头寸 = 当前余额 - 冻结金额

4.2.2 头寸预警机制

4.2.3 流动性管理

• 日间透支：允许特定信用等级的机构在限额内透支，日终前补齐
• 流动性节约机制(LSM)：调整结算指令的执行顺序，优先执行能"解锁"其他指令的结算
• 排队管理：头寸不足时，指令进入优先级队列，头寸恢复后自动执行

4.3 结算指令路由

4.3.1 通道选择规则

通道路由决策树:
├── 跨境交易？
│   ├── 是 → CIPS或SWIFT
│   │   ├── 对手方支持CIPS？→ CIPS（更快、更便宜）
│   │   └── 不支持 → SWIFT（MT103/MT202）
│   └── 否 → 境内通道
│       ├── 金额 > 5000万或紧急？→ CNAPS HVPS（大额实时）
│       ├── 金额 < 5万 → CNAPS BEPS（小额批量）
│       └── 同行内部？→ INTERNAL（行内转账）

4.3.2 报文适配

4.4 外汇处理

4.4.1 汇率管理

汇率获取链路:
1. 实时汇率：从央行/路透社/Bloomberg获取中间价
2. 行内挂牌汇率：基于中间价加点
3. 协议汇率：大客户签订的固定汇率协议
4. 锁汇：交易发起时锁定汇率，结算时按锁定价执行

4.4.2 汇兑损益

汇兑损益 = 实际结算汇率成本 - 客户成交汇率收入
         = (结算金额 × 结算汇率) - (客户金额 × 客户汇率)

4.4.3 外汇头寸管理

• 各币种独立维护头寸
• 设置各币种敞口限额
• 日终统一结转或平盘

4.5 清算窗口管理

4.5.1 批次调度策略

4.5.2 并行处理

日终批次并行策略:
1. 按币种并行：CNY/USD/EUR各自独立清算
2. 按机构分片：200+机构分为20个分片并行轧差
3. 按清算类型并行：支付/跨行/跨境各自独立
4. Pipeline处理：批次1结算的同时，批次2进行轧差

4.5.3 异常处理

• 超时处理：清算窗口内未完成的批次标记为TIMEOUT，进入延迟清算队列
• 拆批策略：大批次自动拆分为小批次，失败不影响其他子批次
• 熔断机制：单通道错误率>30%时熔断该通道，切换备用通道

---

五、深度问题

5.1 清算风险

5.2 DVP（券款对付）

DVP（Delivery versus Payment）是证券清算的核心原则，确保券和款的交割同时完成。

三种DVP模型：

实现要点：

DVP原子性保证:
1. 券端: CSD(中央证券登记)锁定卖方证券
2. 款端: 清算银行冻结买方资金
3. 原子交割: 同一事务内完成过户和划款
4. 失败回滚: 任一端失败则全部回滚

5.3 实时清算(RTGS) vs 批量清算(DNS)

混合架构：现代清算系统通常采用RTGS+DNS混合架构——大额实时，小额批量。这也是本系统的选择。

5.4 跨境清算

SWIFT报文体系

跨境清算特殊挑战

1. 时区问题：纽约/伦敦/东京/北京时区差异，清算窗口不重叠
2. 合规筛查：OFAC制裁名单、反洗钱(AML)、反恐融资(CFT)
3. 中转行(Correspondent Bank)：缺乏直连关系时需要通过中转行
4. 汇率锁定：交易发起到实际结算可能跨天，需锁汇或承担汇率风险
5. Nostro/Vostro账户管理：代理行账户的头寸管理和对账

CIPS的优势

• 直连模式，减少中转行环节
• 人民币实时清算
• 覆盖100+国家和地区
• 运营时间覆盖全球主要时区

5.5 灾备设计

两地三中心架构

            ┌──────────────┐
            │  同城灾备中心  │ ← 同步复制(RPO=0)
            │   (热备)      │
            └──────┬───────┘
                   │ 自动切换(RTO<1min)
┌──────────────┐   │
│   生产中心    │───┘
│   (主活)     │
└──────┬───────┘
       │ 异步复制(RPO<1min)
       ↓
┌──────────────┐
│  异地灾备中心  │
│   (温备)      │ ← RTO<30min
└──────────────┘

关键设计要点：

• 同城灾备：同步复制，RPO=0，自动切换，RTO<1分钟
• 异地灾备：异步复制，RPO<1分钟，手动切换，RTO<30分钟
• 清算状态恢复：批次状态持久化，支持断点续清
• 幂等设计：所有结算指令幂等，重复发送不会重复扣款

5.6 区块链对清算的影响

CBDC的影响：

• 央行数字货币使得资金端可以链上结算
• 与证券token结合可实现原子化DVP
• 降低清算系统的复杂度（无需多级代理行）

当前局限：

• 性能：公链TPS不足以支撑高频清算
• 隐私：交易数据公开可见
• 监管：跨境法律框架不完善
• 采用度：传统金融机构迁移成本高

---

六、架构决策摘要

---

七、面试口述版

2分钟版本

清算结算系统的核心目标是将大量交易转化为最少的资金划拨。系统架构包含三层：采集校验层负责交易数据的收集和清洗；轧差计算层是核心——通过多边轧差将N个参与方间的交易压缩为每个参与方与中央对手方的一笔净额结算，资金效率可提升90%以上；结算执行层根据金额和时效选择CNAPS大额、小额或CIPS通道完成资金划拨。

关键设计点有三个：一是轧差模式选择——日常批量用多边轧差提升效率，大额紧急用逐笔RTGS保安全；二是头寸管理——实时监控各机构可用余额，分级预警防止清算失败；三是资金安全——通过复式记账、多层对账、幂等设计确保资金零差错。灾备采用两地三中心架构，RPO=0，RTO<30分钟。

5分钟版本

在2分钟版本基础上，补充：

数据模型方面，核心表包括clearing_batch(批次管理)、clearing_instruction(清算指令)、netting_result(轧差结果)、settlement_order(结算指令)、position(头寸)。批次状态机经历CREATED→COLLECTING→VALIDATING→NETTING→SETTLING→RECONCILING→COMPLETED。

轧差算法的具体实现：以5个参与方为例，原始12笔交易总资金流动2850，经多边轧差后只需4笔结算共250资金流动，效率提升91.2%。算法核心是计算每个参与方的净头寸（总收入-总支出），验证平衡条件（所有净头寸之和=0），然后生成结算指令。

跨境清算是个额外维度：需要处理SWIFT MT103报文适配、OFAC合规筛查、汇率锁定、时区差异。CIPS的出现简化了人民币跨境清算，减少了中转行环节。

风险控制：信用风险通过保证金和净额敞口限额管理；流动性风险通过日间透支、LSM（流动性节约机制）和排队管理应对；操作风险通过自动化校验和四眼原则降低。

15分钟版本

在5分钟版本基础上，进一步展开：

清算窗口管理：日终批次需在2小时内处理5000万笔交易。通过三层并行实现——按币种并行、按机构分片并行（200个机构分20个分片）、Pipeline处理（前一批结算时后一批在轧差）。异常处理采用拆批策略，单批失败不影响其他批次。

DVP（券款对付）：证券清算的核心，确保券和款的交割原子化。三种模型——Model 1逐笔同时交割，Model 2券逐笔款净额，Model 3两端都净额。实现要点是CSD锁券+清算银行冻款+同一事务交割。

RTGS vs DNS架构差异：RTGS实时全额、无信用风险但流动性需求高，适合大额；DNS延迟净额、效率高但有日间信用暴露，适合批量。现代系统普遍采用混合架构。

区块链的影响：DLT技术理论上可以实现T+0结算、原子化DVP、实时账本一致（免对账），但受限于性能、隐私、监管框架，目前主要在CBDC和私链场景探索。长期看，区块链将重构清算结算基础设施，CCP和中转行的角色可能被智能合约替代。

实际经验：在传统金融系统中，清算系统的最大挑战往往不是技术本身，而是与存量系统的集成——需要适配多种报文标准、处理各银行系统的差异性响应、管理异常场景的长尾问题。

---

八、自评与反思

设计亮点

1. 混合轧差架构：多边轧差+RTGS的混合模式，兼顾效率和安全
2. 分层头寸管理：预警-限制-冻结的三级机制，避免清算失败
3. 并行处理策略：多维度并行确保清算窗口达标
4. 完整的状态机：批次和指令都有清晰的状态流转和异常处理

待深入的领域

1. 流动性节约机制(LSM)：只介绍了概念，未展开算法细节（涉及排队论和图论）
2. CCP风险管理：中央对手方的保证金计算模型（SPAN/TIMS）
3. 实时风控：日间风险敞口的实时计算和限额管理的具体实现
4. 监管报表：各国监管的具体报表要求差异

面试可能的追问

1. "多边轧差的参与方有一个违约了怎么办？" → 违约基金机制、损失分摊规则
2. "清算窗口内系统宕机怎么恢复？" → 断点续清、幂等设计、灾备切换
3. "如何测试清算系统？" → 模拟清算日、影子模式、混沌工程
4. "与DeFi的清算有什么区别？" → 智能合约自动清算、超额抵押、清算人激励