【金融科技工程】证券登记结算：中证登、DTCC、Euroclear、T+1、DvP

引子：撮合之后的世界

上一篇《行情分发》讲的是交易所从撮合引擎向外喷涌行情的毫秒级游戏。但对真正持有头寸的投资者而言，撮合”成交”只是一张欠条——账户里券的数字变了、资金的数字变了，但券真正从卖方过户到买方、钱真正从买方划到卖方，要等到 T+1、T+2 甚至更久之后。这段”交易日之后”的流程，就是证券登记与结算（Post-Trade）。

这个领域长期不性感：没有 10 微秒尾延迟的炫技，没有深度学习模型的光环，也没有 C 端用户的欢呼。但 2008 年雷曼倒闭时，全球金融体系险些崩溃的真正原因不是撮合停摆，而是已成交未结算的几万亿美元头寸突然失去了对手方——是 DTCC、LCH 这些中央对手方在几天内完成了雷曼头寸的拍卖与结算，才把系统从悬崖边拉回来。2021 年 GameStop 事件中，Robinhood 被迫暂停买入 GME，真正的原因也不是”市场操纵配合”，而是 NSCC 要求它在一夜之间追加 30 亿美元保证金，它没那么多现金。

读者画像：交易所、券商、基金、托管行、清算所的后台工程师；希望理解”为什么美股能 T+1 而我们看到的依然是 T+1 券商 App”的技术同学；以及想进入证券 DLT / 代币化领域的开发者。本篇的视角是工程——把 CSD、CCP、CSM 三块砖头铺开，讲清楚它们的职责边界、数据流、一笔成交如何在 24~48 小时内完成”券款对付”，以及哪些正在被区块链改写。

本文偏长，分 12 节。第一节先把”证券后台三要素”和行业地图立起来，后面逐块展开。

一、证券后台三要素：CSD / CCP / CSM

一笔股票成交要最终生效，需要三类基础设施协同。用一句话概括：

• CSD（Central Securities Depository，中央证券登记结算机构）：回答”这张券归谁”——证券的中央名册与托管账户。
• CCP（Central Counterparty，中央对手方）：回答”如果一方违约怎么办”——介入每一笔交易，成为买方的卖方、卖方的买方。
• CSM（Clearing & Settlement Mechanism，清结算系统）：回答”券怎么过户、钱怎么划”——在 CSD 与央行支付系统之间搬运证券与资金。

1.1 三者职责对比

三者并非总是三家公司：DTCC 旗下同时有 DTC（CSD）、NSCC（股票 CCP）、FICC（债券 CCP），是典型的”集团化”后台。而在中国，中国证券登记结算公司（CSDC，俗称”中证登”） 同时承担 CSD 与股票 CCP 的职能，这种”CSD+CCP 合一”的结构在新兴市场较常见。

1.2 一笔 A 股成交的后台全景

sequenceDiagram
    participant Buyer as 投资者（买方）
    participant BrokerB as 券商 B
    participant SSE as 上交所撮合
    participant BrokerS as 券商 S
    participant Seller as 投资者（卖方）
    participant CSDC as 中证登（CSD+CCP）
    participant PBOC as 央行 HVPS

    Buyer->>BrokerB: 买入委托
    Seller->>BrokerS: 卖出委托
    BrokerB->>SSE: 报单
    BrokerS->>SSE: 报单
    SSE-->>BrokerB: 成交回报（T 日）
    SSE-->>BrokerS: 成交回报（T 日）
    SSE->>CSDC: 成交明细批量送达
    Note over CSDC: T 日日终：多边净额计算
    CSDC->>BrokerB: 应付资金净额
    CSDC->>BrokerS: 应收资金净额
    Note over CSDC,PBOC: T+1 资金交收
    BrokerB->>PBOC: 资金划拨
    PBOC->>CSDC: 资金归集
    CSDC->>BrokerS: 资金入账
    Note over CSDC: T+1 证券过户
    CSDC->>Buyer: 证券记入账户

这张图藏着几个关键事实：

1. 撮合 ≠ 结算。上交所给出成交回报瞬间，投资者 App 里头寸就变了——那是”可用头寸”的逻辑标记，不是实际过户。
2. 中证登做的不是 DvP Model 1。A 股历史上是 T+0 证券过户、T+1 资金交收，属于 BIS Model 2（证券逐笔、资金净额），这也是为什么 A 股”买入当日不能卖出”的根源（货已经是你的，但钱还没清）。
3. 两条网络协同：证券腿走中证登的 DCSS，资金腿走央行的 HVPS（大额支付系统）。任何一条失败整笔挂起。

二、CSD：证券的中央名册

2.1 从”实物凭证”到”簿记登记”

1960 年代的华尔街曾经有一个极具讽刺意味的故事：交易量激增到每天几百万股，证券公司后台被纸质股票凭证淹没，交易所不得不每周三闭市一天让后台追赶。这场”Paperwork Crisis”直接催生了 1973 年的 DTC（Depository Trust Company）——把所有上市公司的股票凭证物理集中到 DTC 金库，之后所有过户都变成 DTC 账本上的借贷记，而不是纸张易手。这就是 CSD 的起源：Immobilization（实物固定化）。

更彻底的一步是 Dematerialization（无纸化）：连纸张都不印了，直接以电子登记为法定证据。欧洲大陆 CSD 多走这条路，中国则从一开始就是无纸化——A 股从未有过实物股票凭证。

2.2 两级托管：直接持有 vs 间接持有

CSD 的会计模型有两种流派：

直接持有（Direct Holding）：投资者直接在 CSD 开立账户，CSD 账簿上记的是最终持有人。中国 A 股是世界上极少数实行直接持有的大型市场——每个投资者在中证登都有一个唯一的证券账户号（沪市以 A/B/D 开头，深市 10 位数字），法律上持有人就是投资者本人。

间接持有（Indirect Holding / Nominee）：CSD 只认托管银行 / 券商的”综合账户（Omnibus Account）“，底层投资者的权益由下级中介负责记账。美国 DTC 的户名是”Cede & Co.”——DTC 的全权代理人，所有美股股份在 CSD 层面都登记在 Cede & Co. 名下，个人投资者的权益只存在于券商（Broker）或中介的账本上。欧洲更极端，可能有三四层嵌套：Euroclear → Global Custodian → Local Custodian → Broker → Investor。

两种模型的工程后果完全不同：

2.3 CSD 的核心数据模型

用 SQL 简化描述 CSD 核心三张表：

-- 证券主档（Security Master）
CREATE TABLE security (
    isin           CHAR(12) PRIMARY KEY,        -- ISO 6166
    local_code     VARCHAR(16),                  -- 如 600519 / AAPL
    cfi            CHAR(6),                      -- ISO 10962 分类
    issuer_lei     CHAR(20),                     -- ISO 17442
    face_value     DECIMAL(20,6),
    currency       CHAR(3),
    issue_date     DATE,
    status         VARCHAR(16)                   -- active / suspended / delisted
);

-- 投资者账户
CREATE TABLE holder_account (
    account_id     VARCHAR(32) PRIMARY KEY,      -- 中证登 A/B/D 账户号
    holder_type    VARCHAR(8),                   -- person / legal / nominee
    id_doc_hash    CHAR(64),                     -- 身份证号的哈希（PII）
    custodian_id   VARCHAR(16),                  -- 指定托管券商
    status         VARCHAR(16),
    opened_at      DATE
);

-- 证券持有（Position，单只券单一账户一行）
CREATE TABLE position (
    account_id     VARCHAR(32),
    isin           CHAR(12),
    qty_total      DECIMAL(28,6) NOT NULL,       -- 总持仓
    qty_available  DECIMAL(28,6) NOT NULL,       -- 可用（未质押、未冻结）
    qty_pledged    DECIMAL(28,6) NOT NULL,       -- 质押冻结
    qty_pending    DECIMAL(28,6) NOT NULL,       -- 待交收（T+1 待到）
    avg_cost       DECIMAL(20,6),
    updated_at     TIMESTAMP(6),
    PRIMARY KEY (account_id, isin)
);

真实 CSD 还会有过户簿（Register）、公司行为日程（Corporate Action Calendar）、质押登记（Pledge Register）、权益记录日（Record Date Holder List）等几十张表。但上面三张已足够讲清楚后续流程。

2.4 国际主要 CSD 一览

ICSD（International CSD）指 Euroclear Bank 与 Clearstream Banking Luxembourg，专门处理跨境欧元债券（Eurobond）发行与结算，与”国家级 CSD”是不同物种。

三、CCP：站在每笔交易中间的巨人

3.1 什么是 Novation（合约新颖化）

CCP 的法律魔法叫 Novation：一笔买卖撮合成交后，原始合同被撕毁，取而代之的是两笔新合同：

原始:   Buyer  ———  Contract  ———>  Seller
新颖后: Buyer  ——>  CCP  <——  Seller

从此刻起，买卖双方不再互为对手，双方都只与 CCP 结算。这意味着：

1. 买方不用关心卖方信用——CCP 担保履约；
2. 卖方也一样——哪怕买方破产，CCP 会替买方付钱；
3. 匿名交易成为可能——集中撮合的基础设施之一。

但代价是：CCP 集中了整个市场的对手方风险。LCH 的信用评级（Fitch AA-）往往比它的任何清算会员都高，因为一旦 LCH 倒下，欧元利率互换市场会瞬间瓦解。这也是 2009 年 G20 匹兹堡峰会决定把所有标准化 OTC 衍生品推进 CCP 集中清算的核心动因。

3.2 CCP 的保证金体系

CCP 最核心的工程资产是保证金（Margin）系统。以 SPAN（Standard Portfolio Analysis of Risk，芝加哥商品交易所 1988 年发明）为代表的组合风险模型，每天夜里对会员头寸跑一次”压力场景扫描”。

三层资金结构：

1. 初始保证金 IM（Initial Margin）：开仓时缴纳，按 1–5 日持有期、99%/99.5% 置信度的 VaR 或 Expected Shortfall 估算。
2. 变动保证金 VM（Variation Margin）：按每日收盘价（Mark-to-Market）结算盈亏，亏方必须当日补足，盈方当日提出。
3. 违约基金 DF（Default Fund / Guaranty Fund）：所有会员按规模和风险贡献度分摊的”互保池”，在单个会员违约且其 IM 耗尽后才动用。

瀑布式损失分摊（Default Waterfall）：

flowchart TD
    A[违约会员的<br/>初始保证金 IM] --> B[违约会员的<br/>违约基金出资]
    B --> C[CCP 自有资金<br/>Skin-in-the-Game]
    C --> D[其他会员的<br/>违约基金]
    D --> E[评估式追加<br/>Assessment Call]
    E --> F[VMGH / IMGH<br/>利润与保证金分摊]
    F --> G[CCP 自身破产<br/>Resolution]
    style A fill:#388bfd,color:#fff
    style B fill:#388bfd,color:#fff
    style C fill:#f0883e,color:#fff
    style D fill:#a371f7,color:#fff
    style E fill:#f85149,color:#fff
    style F fill:#f85149,color:#fff
    style G fill:#f85149,color:#fff

层级越高，触发概率越小，政治敏感度越高。2018 年 LCH 的 Einar Aas 事件——一个挪威独立交易员在北欧电力期货上爆仓——直接把 LCH 的 Default Fund 烧掉了约 1.1 亿欧元，占掉了非违约会员出资的约 2/3，是近年最”教科书”的瀑布穿透案例。

3.3 保证金模型：SPAN、VaR、历史模拟

• SPAN（CME）：16 个标准场景（价格 ±, 波动率 ±, 跨月/跨品种价差, 极端下行等），取组合在各场景下的最大损失。老牌、透明、易解释。
• HVaR（Historical VaR）：把过去 1000~2500 个交易日的因子变动套到今日头寸上，取分位数。LCH SwapClear、DTCC NSCC 都用这类模型。
• Filtered HVaR / EWMA HVaR：用 GARCH/EWMA 对历史收益做波动率缩放，在低波动期放大历史、在高波动期缩放历史，解决”宁静期保证金过低”的老问题。
• SIMM（ISDA SIMM）：用于双边非清算衍生品（Non-cleared OTC）的统一初始保证金模型，2016 年起按 UMR 规则逐步推开。

保证金充足性的监管底线，参见 CPMI-IOSCO《Principles for Financial Market Infrastructures》（PFMI）与欧盟 EMIR、美国 CFTC 17 CFR Part 39：CCP 初始保证金必须覆盖”Cover 2”（最大两家清算会员同时违约在极端但可信情景下的损失）。

三补、CCP 案例研究

3C.1 MF Global 崩盘（2011）—— 客户资金被挪用的教训

MF Global 是美国大型期货经纪商。2011 年 10 月，Corzine 押注欧洲主权债券反转失败，公司破产。清算时发现客户隔离账户（Segregated Account） 短缺 $16 亿——客户保证金在不同内部账户间被”错误”划用以补公司自有敞口。事后 CFTC 建立 Residual Interest 规则与每日三次客户头寸重算，保证金系统必须有 T+0 逐日重建能力。

3C.2 Nasdaq OMX 电力期货事件（2018）

2018 年 9 月 Einar Aas 在 Nasdaq Clearing 电力期货组合亏损触发强平，组合规模远超 IM，违约基金被穿透约 €1.14 亿（其中 Aas 自身 IM 约 €700 万 + DF 出资约 €700 万，另约 €1.07 亿来自非违约会员 DF）。教训：

1. 组合保证金（Portfolio Margin） 对跨品种价差过度优惠，极端跨品种价差一旦爆仓，IM 瞬间蒸发；
2. 单会员集中度限额未生效，单人组合占比过高；
3. 流动性估值误差——电力期货流动性远低于金融期货，Liquidation Time 被低估。

此后 ESMA EMIR 2.2 引入反顺周期边际（APC Margin）、集中度附加（Concentration Add-on）。

3C.3 LME 镍价风暴（2022）

2022 年 3 月 7–8 日伦敦金属交易所 LME 镍合约两日上涨 250%，LME 宣布取消 3 月 8 日全部交易并暂停市场 8 天。清算所 LCH LME Clear 避免了违约基金穿透，但”取消交易”作为 CCP 的”最后防线”工具，在金融市场监管史上极其罕见，至今仍有诉讼。教训：

• CCP 的 IM 模型对极端单向行情的前瞻性不足；
• 大户集中度（青山控股 20 万吨空单）未被 LME 风控识别；
• 商品交易所的 CCP 与金融交易所 CCP 风险文化差异巨大。

3C.4 LCH SwapClear 规模

LCH SwapClear 是全球利率互换清算霸主，2024 年末未平仓名义本金约 $680 万亿，月清算量 $150 万亿，约 120 家直接清算会员，覆盖 24 种货币的利率互换、OIS、FRA。保证金模型采用 PAIRS（Portfolio Approach to Interest Rate Scenarios）：历史 1250 日场景 + 压力场景叠加，5 日持有期 99.7% VaR，另加 Credit Risk Multiplier 反顺周期层。

3C.5 SPAN 的一个简化例子

以 CME E-mini S&P 500 期货为例，SPAN 扫描 16 个场景：

PSR = Price Scan Range，由交易所周度校准。对组合计算每场景净盈亏，取最大损失即 Scan Risk。再加 Inter-month Spread Charge（跨月价差补偿）、Inter-commodity Spread Credit（跨品种对冲优惠，负值）、Delivery Charge（临近交割月附加）、Short Option Minimum（裸卖权底仓）。最终 IM = max(组合 SPAN, SOM)。

Go 伪代码片段：

func SPANMargin(portfolio []Position, scenarios []Scenario) float64 {
    scanRisk := 0.0
    for _, s := range scenarios {
        pnl := 0.0
        for _, p := range portfolio {
            pnl += priceUnder(p, s) - p.MarkToMarket
        }
        loss := -pnl * s.Weight
        if loss > scanRisk {
            scanRisk = loss
        }
    }
    interMonthSpread := calcInterMonthSpread(portfolio)
    interCommodityCredit := calcInterCommodityCredit(portfolio)
    deliveryCharge := calcDeliveryCharge(portfolio)
    som := shortOptionMinimum(portfolio)

    span := scanRisk + interMonthSpread - interCommodityCredit + deliveryCharge
    if span < som {
        return som
    }
    return span
}

真实 SPAN 还区分 Speculator/Hedger 分级、期权 Vega/Gamma 扫描、货币对冲。

3.4 全球主要 CCP

四、结算周期：T+1 浪潮下的世界

4.1 T+N 是什么

“T+N”是 Trade Date + N Business Days 的简写：T 日成交，T+N 日完成券款交收。各国历史与现状：

4.2 为什么 T+1 很难

从 T+2 到 T+1 看似只是少了一天，工程上却是灾难级改造：

1. 时区压缩：全球投资者（亚欧美）必须在美东下午 4 点收盘到次日上午 11:30 NSCC 结算前完成 FX 换汇、调拨资金、指令匹配。亚洲投资者基本上被迫夜班或预置美元。
2. 证券借贷归还压缩：融券方必须在 T+1 内召回/归还，Recall 通知窗口极短。
3. ETF 申赎：ETF 授权参与商（AP）用篮子股票换 ETF 份额，两条腿必须同时变 T+1。
4. 公司行为处理：分红、拆股等 ex-date / record-date 规则整体前移一天。
5. 跨境交易 FX 对齐：CLS（大额 FX 结算）截止时间（00:00 CET）与 T+1 证券截止时间（11:30 ET）之间的时差导致 FX 无法 PvP 结算，被迫走”非 CLS 渠道 + 对手方信用暴露”。

DTCC 的 T+1 切换被认为是 2020 年代金融基础设施最大的一次工程变更，2024-05-28 上线首日，NSCC Affirmation 匹配率从 T+2 时期的约 73% 飙升到上线首周的 95%——不是投资者变勤快了，而是各家都被迫重构了 OMS/IMS 的时间表与自动化。

4.3 T+0 的两种”即时结算”

“T+0”在不同语境下意思完全不同：

1. DvP 即时结算（Real-Time DvP）：券与钱在秒级内同时易手。如 CSDC 的场内现券回购、RTGS 国债结算、DLT 试点。
2. T+0 回转交易：买入后当日可卖出。美股、港股都是 T+0 回转，A 股股票不允许、ETF 允许，债券允许。

第二种是”交易规则”层面的概念，和结算周期正交。

五、DvP：券款对付的 BIS 三模型

BIS（国际清算银行）1992 年发布的《DvP in Securities Settlement Systems》定义了三种 Delivery-versus-Payment 模型，至今仍是行业语言。

5.1 三种模型对比

flowchart LR
  subgraph M1 [Model 1: 逐笔全额]
    direction TB
    S1a[每笔交易<br/>券与钱同时逐笔结算] --> E1[无敞口<br/>高流动性需求]
  end
  subgraph M2 [Model 2: 券逐笔/钱净额]
    direction TB
    S2a[证券逐笔结算] --> S2b[资金日终多边净额]
    S2b --> E2[券先到<br/>钱后到: 卖方敞口]
  end
  subgraph M3 [Model 3: 券钱均净额]
    direction TB
    S3a[券与钱均日终净额同时交收] --> E3[流动性最省<br/>日内敞口大]
  end

一个更直观的 SVG（深色主题）：

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 900 340" width="900" height="340" font-family="ui-monospace" font-size="13">
  <rect width="900" height="340" fill="#2d333b"/>
  <text x="450" y="28" text-anchor="middle" fill="#adbac7" font-size="16" font-weight="bold">BIS DvP 三种模型（1992）</text>

  <!-- Model 1 -->
  <rect x="30" y="60" width="260" height="250" fill="#22272e" stroke="#388bfd"/>
  <text x="160" y="85" text-anchor="middle" fill="#388bfd" font-weight="bold">Model 1: 逐笔全额 DvP</text>
  <text x="50" y="120" fill="#adbac7">每笔成交独立结算</text>
  <text x="50" y="145" fill="#3fb950">券腿: 逐笔, gross, RTGS</text>
  <text x="50" y="170" fill="#3fb950">钱腿: 逐笔, gross, RTGS</text>
  <text x="50" y="195" fill="#f0883e">特点: 同时 & 终局</text>
  <text x="50" y="220" fill="#f85149">成本: 极高流动性占用</text>
  <text x="50" y="250" fill="#adbac7">例: Fedwire Securities</text>
  <text x="50" y="272" fill="#adbac7">     TARGET2-Securities</text>
  <text x="50" y="294" fill="#adbac7">     HKD CHATS 债券</text>

  <!-- Model 2 -->
  <rect x="320" y="60" width="260" height="250" fill="#22272e" stroke="#a371f7"/>
  <text x="450" y="85" text-anchor="middle" fill="#a371f7" font-weight="bold">Model 2: 券 gross / 钱 net</text>
  <text x="340" y="120" fill="#adbac7">证券逐笔过户</text>
  <text x="340" y="145" fill="#3fb950">券腿: 逐笔, gross</text>
  <text x="340" y="170" fill="#f0883e">钱腿: 日终多边净额</text>
  <text x="340" y="195" fill="#f0883e">特点: 券先, 钱后</text>
  <text x="340" y="220" fill="#f85149">风险: 卖方对买方敞口</text>
  <text x="340" y="250" fill="#adbac7">例: 中证登 A 股历史模式</text>
  <text x="340" y="272" fill="#adbac7">     多数新兴市场 CSD</text>

  <!-- Model 3 -->
  <rect x="610" y="60" width="260" height="250" fill="#22272e" stroke="#3fb950"/>
  <text x="740" y="85" text-anchor="middle" fill="#3fb950" font-weight="bold">Model 3: 双边净额</text>
  <text x="630" y="120" fill="#adbac7">券钱均日终多边净额</text>
  <text x="630" y="145" fill="#f0883e">券腿: 日终, net</text>
  <text x="630" y="170" fill="#f0883e">钱腿: 日终, net</text>
  <text x="630" y="195" fill="#3fb950">特点: 最省流动性</text>
  <text x="630" y="220" fill="#f85149">风险: 日内敞口最大</text>
  <text x="630" y="250" fill="#adbac7">例: DTC / NSCC 美股</text>
  <text x="630" y="272" fill="#adbac7">     Euroclear 部分链路</text>
</svg>

5.2 模型选择的工程含义

美股走 Model 3 的根源是历史遗留：间接持有 + 每日上亿笔零售交易 + 券商集中化——若走 Model 1，NSCC 一天可能要过几十万亿美元资金流。净额压缩把实际资金流压缩到原始的 2%–3%。

六、净额结算：把 10000 亿压成 300 亿

6.1 双边净额 vs 多边净额

双边净额（Bilateral Netting）：A 与 B 相互欠款，取差额。简单但压缩有限。

多边净额（Multilateral Netting）：N 家机构彼此多向往来，CCP 以”每家对 CCP 的单一净头寸”代替两两敞口。例如：

双边净额后每对还剩一条链路。多边净额后：

• A 净付 = (100+80+60) - (70+30+50) = 90
• B 净收 = (70+60+40) - (100+40+90) = -60（即 B 净付 60）
• C 净付 = (30+60+80) - (80+40+90) = -40（C 净收 40）
• D 净收 = (50+40+90) - (60+50+80) = -10（D 净收 10）

→ 实际资金流只有 150（= 90+60 付入 CCP，40+10 付出 CCP）。

压缩比常见在 95%~99%。2023 年 NSCC 压缩统计：原始 $2.47 万亿日均名义资金流，净额后实际现金结算约 $700 亿，压缩比约 97%。

6.2 简化版多边净额 Go 实现

package clearing

import (
    "sort"
)

type Trade struct {
    ID       string
    Buyer    string // clearing member
    Seller   string
    ISIN     string
    Qty      int64      // 正数，手数/股数
    PriceCTS int64      // 整数分，避免浮点
}

type NetResult struct {
    Member string
    ISIN   string
    NetQty int64  // >0 应收券, <0 应付券
    NetCTS int64  // >0 应收资金, <0 应付资金
}

// MultilateralNet 对一批已 Novated 的 trade，按(member, ISIN) 聚合多边净额
func MultilateralNet(trades []Trade) []NetResult {
    type key struct {
        Member string
        ISIN   string
    }
    cashKey := func(m string) key { return key{Member: m, ISIN: "__CASH__"} }

    secAgg := map[key]int64{}
    cashAgg := map[key]int64{}

    for _, t := range trades {
        sKey := key{Member: t.Seller, ISIN: t.ISIN}
        bKey := key{Member: t.Buyer, ISIN: t.ISIN}
        secAgg[sKey] -= t.Qty
        secAgg[bKey] += t.Qty

        notional := t.Qty * t.PriceCTS
        cashAgg[cashKey(t.Buyer)]  -= notional
        cashAgg[cashKey(t.Seller)] += notional
    }

    out := []NetResult{}
    for k, q := range secAgg {
        out = append(out, NetResult{Member: k.Member, ISIN: k.ISIN, NetQty: q})
    }
    for k, c := range cashAgg {
        out = append(out, NetResult{Member: k.Member, ISIN: k.ISIN, NetCTS: c})
    }
    sort.Slice(out, func(i, j int) bool {
        if out[i].Member != out[j].Member {
            return out[i].Member < out[j].Member
        }
        return out[i].ISIN < out[j].ISIN
    })
    return out
}

真实 CCP 的净额引擎还要处理：待结算失败转移到次日、公司行为冻结、拒结算（Reject）的追溯冲销、净额轧差后的保证金重算。但骨架就是这段代码。

6.3 净额结算的细节陷阱

真实世界的多边净额还要处理以下场景：

(1) CNS（Continuous Net Settlement）的”结转”机制

NSCC 用的 CNS 不是”每日独立净额”，而是一个滚动头寸池。如果会员今日应交付 1000 股 AAPL 但只能交付 800 股，200 股的缺口结转到次日，与次日的净头寸再次净额。

T 日 Net obligation: deliver 1000 AAPL
T 日 actual delivery: 800 AAPL
T 日 fail: 200 AAPL (carried forward)

T+1 日 new net: receive 500 AAPL
T+1 日 adjusted:
    200 carried fail (deliver)
    - 500 new receive
    = 300 net receive (fail cleared + 300 new receive)

这种”失败自动对冲”的设计把 fail 率大大降低，但同时也让会员的头寸日日滚动，暴露窗口延长。

(2) 保留指令（Hold-and-Release）

并非所有成交都要立刻进入净额。为应对临时流动性紧张、法律冻结、客户指令延期等情况，CSD 允许”持有指令（On Hold）“，手动释放时才并入净额批次。T2S 的 Hold/Release 机制是典型设计：HOLD → PART（Partially Matched）→ MATCH → SETTLE。

(3) 部分结算（Partial Settlement）

当卖方只有 8000 股、需要交付 10000 股时，某些 CSD 允许部分结算：立即交付 8000 股并收对应比例资金，剩余 2000 股变为新指令滚动到次日。T2S 支持 Partial Settlement 并以 10% 粒度为阈值。中证登目前不支持部分结算，整笔 fail。

(4) 背对背（Back-to-Back）链

机构客户 → 券商 A → 券商 B → 最终卖方的链式交易中，中间节点的券款全部来自上游。一环 fail 则整条链 fail。CSD 支持 Linked Settlement（SSE/BSE/DTC 都有）——整条链作为一个原子包一起结或一起失败。

七、一个简化的 DvP 结算引擎（Go）

下面给一个原子 DvP 的最小可运行示意——买卖双方在单机内完成”券与钱同时易手或同时不动”。真实世界的 DvP 要跨越两个独立系统（CSD 与央行支付系统），必须用两阶段提交或排队持有（Queue-Hold-Release）机制。

package dvp

import (
    "errors"
    "sync"
)

type Ledger struct {
    mu      sync.Mutex
    Cash    map[string]int64              // member -> cents
    Secs    map[string]map[string]int64   // member -> ISIN -> qty
}

func NewLedger() *Ledger {
    return &Ledger{
        Cash: map[string]int64{},
        Secs: map[string]map[string]int64{},
    }
}

func (l *Ledger) pos(m, isin string) int64 {
    if _, ok := l.Secs[m]; !ok { return 0 }
    return l.Secs[m][isin]
}

func (l *Ledger) addSec(m, isin string, d int64) {
    if _, ok := l.Secs[m]; !ok { l.Secs[m] = map[string]int64{} }
    l.Secs[m][isin] += d
}

// SettleDvP 对单笔净额指令执行原子 DvP：
//  - seller 账上扣券、收钱
//  - buyer 账上加券、付钱
//  - 任一前置检查失败，整笔回滚（此处用 defer + panic/recover 避免部分写入）
func (l *Ledger) SettleDvP(buyer, seller, isin string, qty int64, amountCTS int64) error {
    if qty <= 0 || amountCTS <= 0 {
        return errors.New("invalid qty or amount")
    }
    l.mu.Lock()
    defer l.mu.Unlock()

    if l.pos(seller, isin) < qty {
        return errors.New("seller position insufficient")
    }
    if l.Cash[buyer] < amountCTS {
        return errors.New("buyer cash insufficient")
    }

    // 原子应用：map 操作不会部分失败（均在同一把锁内）
    l.addSec(seller, isin, -qty)
    l.addSec(buyer,  isin, +qty)
    l.Cash[buyer]  -= amountCTS
    l.Cash[seller] += amountCTS
    return nil
}

要变成能跑在多系统间的”真 DvP”，需要：

1. 队列持有：买方资金划到 CSM 托管账户冻结，卖方证券在 CSD 冻结；
2. 双边准备：两侧都 READY 才进下一阶段；
3. 原子释放：CSM 同时签发资金 Debit Credit 与证券过户记账；
4. Terminal Finality：一旦成功，不可撤销（Settlement Finality Directive 2002/47/EC）。

T2S（TARGET2-Securities）的实现是典型的 Model 1：证券在 T2S 平台上实时逐笔过户，资金腿直接命中 TARGET2（央行 RTGS）的专用现金账户（DCA），两腿通过”会计 hook”原子化。欧元区的”央行钱 + 央行券平台”由此合为一体。

7.1 状态机视角

结算指令的生命周期可以看成一个 10 状态的有限状态机：

stateDiagram-v2
    [*] --> Received: 指令入库
    Received --> Validated: 静态校验通过
    Received --> Rejected: 校验失败
    Validated --> Matched: 双边匹配成功
    Validated --> Unmatched: 超时未匹配
    Unmatched --> Matched: 对手补报
    Unmatched --> Cancelled: 取消
    Matched --> OnHold: 持有指令
    OnHold --> Matched: 释放
    Matched --> Pending: 等待结算日
    Pending --> Settled: 券款齐备, 结算成功
    Pending --> Failed: 结算日券/钱不足
    Failed --> Pending: 次日继续尝试
    Failed --> BuyIn: 触发强制买入
    Settled --> [*]
    BuyIn --> Settled
    Cancelled --> [*]
    Rejected --> [*]

每个迁移都需要持久化（至少 WAL + 快照）以应对故障恢复——Settlement Finality 一旦写入不可逆，回滚会导致系统性监管问题。

7.2 DvP 引擎的工业实现要点

下面的简化代码只展示”单机原子”，工业实现还要处理：

// 工业级 DvP 引擎的组件栈 —— 伪代码注释
// ┌────────────────────────────────────────────────┐
// │ 1. 指令接收层 (sese.023 / MT 541 parser)        │
// │ 2. 校验层 (静态: ISIN, BIC, account, quantity) │
// │ 3. 匹配引擎 (双边 matching tolerance)          │
// │ 4. 净额引擎 (multilateral netting)             │
// │ 5. 流动性检查 (collateral, queue prioritize)   │
// │ 6. 结算核心 (atomic book-transfer, WAL)        │
// │ 7. 与央行支付系统对接 (TARGET2/Fedwire/HVPS)   │
// │ 8. 失败与重试 (fails management, buy-in)       │
// │ 9. 确认与通知 (sese.025 / MT 544)              │
// 10. 审计日志 (WORM, 监管上报)                   │
// └────────────────────────────────────────────────┘

下面的代码是最小原子 DvP（见上一节 Go 示例），真实实现还需额外几万行支持 WAL、消息网关、协议解析、监管上报。

七补、结算报文：ISO 15022 与 ISO 20022

撮合成交后的后台交互基本上都是标准化报文。理解这些报文，比看任何架构图都更能看清结算系统。

7B.1 证券后台报文家族

SWIFT ISO 15022（MT 系列）与 ISO 20022（MX/XML 系列）并存，后者逐步取代前者。核心报文：

7B.2 一个 MT 541 的骨架

:16R:GENL
:20C::SEME//REF123456789
:23G:NEWM
:16S:GENL
:16R:TRADDET
:98A::SETT//20260423
:98A::TRAD//20260422
:90B::DEAL//ACTU/USD1450,25
:35B:ISIN US0378331005
     APPLE INC
:16S:TRADDET
:16R:FIAC
:36B::SETT//UNIT/100,
:97A::SAFE//1234567890
:16S:FIAC
:16R:SETDET
:22F::SETR//TRAD
:16R:SETPRTY
:95P::DEAG//CHASUS33
:16S:SETPRTY
:16R:SETPRTY
:95P::SELL//BBHIUS33
:16S:SETPRTY
:16R:AMT
:19A::SETT//USD145025,00
:16S:AMT
:16S:SETDET

字段语义：:23G:NEWM 新建指令，:98A::SETT 结算日，:35B ISIN，:36B 数量，:19A:SETT 对价金额。对应的 ISO 20022 是 sese.023.001.xx XML，语义一致但层级结构化。

7B.3 Matching 与 Affirmation

跨对手的两条结算指令必须双向匹配才能进入 CSD 队列（Matched Queue）。传统上由 CSD 内部匹配，现代大型跨境市场用独立的后台匹配平台：

• DTCC CTM（Central Trade Manager）：全球买方 vs 卖方 allocation 与 confirmation 匹配，T+1 后日内 affirmation 的主要承载平台；
• Omgeo ALERT：SSI 全球数据库，避免每次发送重复的结算账户信息；
• Euroclear EasyWay / Clearstream Xact：本地 CSD 提供的投资者指令入口。

匹配关键字（Matching Tolerance）：交易日、结算日、ISIN、数量、金额（允许小额差异，如 €25）、买卖方向、双方 BIC、SSI 账户。任一不一致即 Unmatched，告警给人工。

八、跨境结算：ICSD、ADR、GDR、互联互通

8.1 ICSD 的角色

欧元债券（Eurobond）是 1960 年代起绕开美国利息平衡税（IET）发行的美元债券，没有任何单一国家的 CSD 可承担跨国登记，Euroclear（1968 年由摩根担保信托创立） 和 Clearstream（1970 年的 Cedel） 因此诞生。ICSD 的关键能力：

• 多币种、多时区结算；
• 与各国 CSD 建立”Account at Custodian”通道（Bridge）；
• Euroclear–Clearstream 之间的 Bridge Settlement 每晚 6~8 轮批处理。

8.2 ADR / GDR：同一只券的”跨境复制”

ADR（American Depositary Receipt）是美国投资者持有非美证券的工具：

Company (e.g., 台积电)
   ↓ 发行本地股票
Local CSD（台湾集保）
   ↓ Custodian 冻结一定数量股票
Depositary Bank（如 Citibank, JPM）
   ↓ 签发 ADR
DTC 登记，美国投资者买卖 ADR

1 ADR 对应 N 股底层股票（比值公开），当美股市场 ADR 需求增大时，AP 会买底层股票、交付给 Depositary Bank、铸造新的 ADR；反之则”赎回”——这条”铸造/赎回”通道是 ADR 与底层股票价格收敛的套利机制。

GDR（Global Depositary Receipt）与 ADR 同源，通常在伦敦或卢森堡挂牌，沪伦通、瑞士 GDR 就是这种结构。

8.3 沪深港通：互联互通的结算

沪深港通（Stock Connect，2014 起）的结算路径是一套”本地 CSD 为主、对方 CSD 做 nominee”的混合架构：

flowchart LR
    HKInv[香港投资者] --> HKBroker[港股券商]
    HKBroker --> HKEX[港交所]
    HKEX --> SSEConn[上交所 Northbound 通道]
    SSEConn --> CSDC[中证登]
    CSDC --> HKSCCNom[HKSCC Nominee 综合账户]
    HKSCCNom --> HKSCC[HKSCC<br/>香港结算]
    HKSCC --> HKInv

关键点：沪港两地的 CSD 互为 nominee。香港投资者买的 A 股在中证登账上登记在 HKSCC 名义账户下，实际投资者权益由 HKSCC 向下维护；反向同理。这套结构的妙处是投资者账户不跨境——监管、AML、税收都在本地闭环。代价是公司行为派发、投票权行使要走 HKSCC-CSDC 之间的信息接口，延迟约 1–2 日。

九、中国的特殊架构：CSD+CCP 合一

9.1 中证登（CSDC）

中证登成立于 2001 年 3 月，合并了上海、深圳两家证券登记公司，同时承担：

1. CSD 职能：沪深 A 股、B 股、基金、公募债的登记托管；
2. CCP 职能：现货交易的净额与担保交收；
3. CSM 职能：DCSS（Depository Clearing Settlement System）系统统一指挥；
4. 账户直连个人：直接持有模式下每位投资者的唯一账户。

9.2 中证金融与融资融券清算

中证金融（China Securities Finance Corp, CSF）不是 CSD，而是 A 股融资融券与转融通市场的”央行 + CCP”：

• 转融资：面向券商出借资金；
• 转融券：面向券商出借证券（资产来自公募、保险、战略配售解禁等）；
• 2015 年股灾期间，中证金融作为”国家队”通过直接买入 ETF 维稳。

9.3 上海清算所（SHCH）

上清所 2009 年成立，主要覆盖：

• 人民币外汇衍生品（Forward、Swap、Option）；
• 人民币利率互换、标准债券远期；
• 大宗商品现货与衍生品；
• 信用风险缓释凭证（CRMW）、债券通北向/南向的部分清算。

它是中国 OTC 衍生品 CCP 集中清算改革的核心执行者，架构上对标 LCH。

9.4 债券市场多 CSD 并存

不同于股票市场的单一 CSD，中国债券市场长期是”多个 CSD + 多交易场所”的格局：

这种”分账户制”历史上造成同一只国债在两个 CSD 间转托管周期超过 T+1，是近年”债券市场基础设施互联互通”改革的核心痛点。

十、公司行为（Corporate Action）

结算系统不止是”券进钱出”，还要处理发行人对持有人的单向动作：

几个关键日期：

• Announcement Date：公告日；
• Ex-Date：除权/除息日，当日买入者不享有；
• Record Date：权益登记日；
• Payment Date：支付日。

工程陷阱最多的地方是跨越 Record Date 的在途交易：如果交易在 T 日成交、但 T+1 才交收，买方是否享有分红？规则是”以 Record Date 持有人为准”，因此美股 T+2 时期曾规定 “Ex-Date = Record Date - 1 business day”，T+1 切换后改为 “Ex-Date = Record Date”。任何 CSD 系统的公司行为引擎都必须能动态重算 record date 名册。

十一、失败交易与 CSDR 处罚

11.1 结算失败（Settlement Fails）的原因

1. 证券不足（Short Fail）：卖方 T 日卖出但未能在结算日交付证券——最常见原因是融券未归还。
2. 资金不足（Cash Fail）：买方交收账户余额不足。
3. 指令不匹配（Mismatch）：SSI（Standard Settlement Instructions）买卖双方不一致。
4. 系统问题：CSD/CSM 宕机（罕见但发生过，如 2020 年 ASX 澳交所 CHESS 故障）。

NSCC 长期公开的 CNS Fails-to-Deliver 数据显示，美股 Fails 规模在 $100 亿~$500 亿美元量级浮动，占日均成交 1–5%。

11.2 强制买入（Buy-in）

当卖方多日未能交付，CCP 或买方有权触发 Buy-in：从市场替卖方买入等量证券交付给买方，差价由卖方承担。欧盟 CSDR（Central Securities Depositories Regulation）的强制 Buy-in 条款争议极大，2022 年后一度推迟实施。

11.3 CSDR 现金处罚机制（Cash Penalties）

2022 年 2 月 1 日起在欧盟 CSD 生效的Settlement Discipline Regime：每笔 fail 每天按标的价值的 BPS 收取罚金，由 CSD 自动计算并从违约方扣收、支付给无辜方：

设计初衷是把”慢结算”从行业文化变成直接的经济痛点。上线第一年欧盟 CSD 总共自动计提处罚超过 €3 亿，机构后台被迫投入匹配与 affirmation 自动化——本质上是用罚款推动 STP（Straight-Through Processing）。

十二、DLT 与证券代币化

12.1 为什么后台特别被 DLT 盯上

证券后台的几个性质让它成为区块链的天然目标：

1. 多方共享账本：CSD / CCP / Custodian / Broker / Issuer 都要看同一本账；
2. 结算慢：T+1 已经很努力了，链上天然 T+0；
3. 对账昂贵：目前全球后台对账人力与系统成本每年数百亿美元；
4. DvP 天然契合：智能合约可以”原子交换”券与钱。

12.2 主要试点与生产项目

12.3 代币化证券的技术栈

• ERC-20：早期天真尝试，缺身份与限制；
• ERC-1400 / ERC-1404：加入转账限制（Whitelist、合规检查）；
• ERC-3643（T-REX）：受监管代币化证券事实标准，强制 ONCHAINID（链上身份），转账前需 Compliance 模块校验；
• Canton Network（Digital Asset）：DAML 智能合约，子网隐私 + 全局原子性，被 DTCC、HKMA Ensemble、Broadridge DLR 采用；
• Fnality / Partior：面向央行钱的批发 CBDC / 商业银行钱代币化，解决 DvP 的”钱腿”。

12.4 证券代币化的工程难点

1. 法律终局性（Legal Finality）：链上”转账确认”是否等同于《Settlement Finality Directive》意义上的 Finality？多数司法区尚未完全承认；
2. 身份（ONCHAINID）与隐私：监管要求 KYC、AML 但链上信息又公开可见，需要 ZKP 或许可链；
3. 央行钱的链上化：没有 wCBDC（Wholesale CBDC），DvP 仍要跨系统；
4. 公司行为链上化：把分红、投票等映射为智能合约事件是大工程；
5. 互操作性：DTCC 链、JPM 链、SIX 链互不通，仍需传统 CSD 做 bridge。

12.5 真实落地例子

• 世界银行 2018 年 Bond-i：澳大利亚政府以太币私有链发行 1.1 亿澳元债券，全生命周期链上；
• 欧洲投资银行 2021/2022 数字债券：以太坊 + Goldman Sachs Digital Asset Platform，€1 亿、€5000 万；
• SDX CHF 2 亿债券（2023）：首个公开上市的”完全链上清结算”公共债券；
• Hamilton Lane 私募基金代币化：ERC-3643 在 Polygon 上，最低认购门槛从 $100 万降到 $10 万；
• 中国工商银行数字债券（2024 试点）：基于长安链的场外数字债券簿记建档。

十三、工程坑点清单

1. 直接 vs 间接持有混用：跨境经纪商在本国看到”个人”账户、在对手国看到”综合 nominee”，账户对账口径要分层。
2. 时区与 Cut-off：美股 T+1 下，亚洲 OMS 必须能在美东 16:00 之前完成 Affirmation，意味着北京时间凌晨四点前的自动化。
3. 公司行为日历 DST 切换：Ex-Date 计算踩过夏令时切换会错位，需统一用交易所本地日历而非 UTC。
4. 买入回转禁令：A 股 T+1 不能当日回转卖出——风控系统要在”可卖头寸”口径上严格区分 T 日新买入（不可用）与历史头寸。
5. 多边净额的拒结算传染：一个会员 fail 可能让多个净额输出同时重算，引擎必须支持日内增量重算。
6. 保证金计算的端口：HVaR 1000 日历史在新券上缺数据，需 Proxy 相关券或保守系数。
7. 质押冻结与交收冲突：融资融券质押券被冻结时仍被卖出指令命中，必须在委托阶段拦截。
8. SWIFT MT vs ISO 20022 并存：全球大部分 Custodian 2025 年底前完成 MT→ISO 20022（MX）迁移，旧 MT540–MT548 报文正在退网，转换层是长期坑。
9. T+0 DLT 与 T+1 传统的并行：同一只券在 DTCC Ion 与 NSCC 同时存在的阶段，要防止”同一份券双向卖出”。
10. Fails 的跨日累积效应：单日 fail 扩展到连续 5 日 fail 时，Buy-in 流程启动，OMS 必须能追溯原始交易。
11. 税务代扣（WHT）与公司行为：跨境分红在 record date 后 record 是 beneficial owner 可能与 nominee 不一致，FATCA/CRS 报送需在 CSD 层穿透。
12. 中央银行假期：央行支付系统关门的日子（如美国 Juneteenth）CSD 仍交易时，DvP 变 DvP-lag，需特殊日历。

十四、选型建议 / 落地清单

对交易所 / 集团化后台：

• 单一市场选集中式 CSD+CCP 合并（中证登范式），多市场联合结算考虑 DTCC 集团式；
• 保证金引擎优先 HVaR + Stress，不要试图自造轮子；
• Settlement 核心系统走”会计分录 + 状态机”双层架构，不要混入业务规则。

对券商 / 托管行：

• OMS/IMS 与 Post-Trade 必须解耦，Affirmation/Matching（如 DTCC CTM）单独部署；
• 建立 Fails Dashboard 与自动 Buy-in 脚本；
• 公司行为系统优先支持 SWIFT ISO 15022 / ISO 20022（CA 报文族）；
• 对接代币化平台时坚持”链下会计为主账本”，链上只是状态副本。

对新兴市场 CSD：

• 若仍是 Model 2，可优先过渡到 Model 1 Securities + 日终净额 Cash（即 “Model 2 变形”），而非直接跃进 Model 3；
• DvP RTGS 的流动性成本评估要联合央行 LSF（Liquidity Saving Feature）设计；
• 提前铺设 DLT 试点沙箱，避免在代币化浪潮中被动接入。

对 DLT 证券工程：

• 选许可链而非公链；
• 代币标准 ERC-3643 优先；
• 身份与合规模块与代币合约解耦；
• 优先解决钱腿（wCBDC 或代币化存款），没有钱腿的”代币化证券”只是半个 DvP。

十五、与本系列的交叉引用

• 后台资金归集与净额逻辑延伸自 《清算 vs 结算 vs 资金归集》；
• 央行支付系统是 DvP 的资金腿，见 《央行支付系统》；
• 跨境结算与代理行账户参阅 《跨境支付工程》；
• 代币化证券的”钱腿”与 wCBDC 见 《数字人民币、稳定币与 CBDC》；
• 交易所撮合侧与本篇形成前后台全景，见 《交易所核心系统架构》 与 《撮合引擎实现》；
• 行情层数据是结算账簿的影子，见 《行情分发》；
• 保证金与 CCP 风险场景与下一篇 《实时风控引擎》 联动。

十六、参考资料

1. CPMI-IOSCO. Principles for Financial Market Infrastructures (PFMI). 2012. https://www.bis.org/cpmi/publ/d101.htm
2. BIS CPSS. Delivery versus Payment in Securities Settlement Systems. 1992. https://www.bis.org/cpmi/publ/d06.htm
3. DTCC. Accelerating Settlement to T+1: Industry Impact Assessment and Implementation Guide. 2023. https://www.dtcc.com/ust1
4. ESMA. Shortening the Settlement Cycle in the EU. Final Report, Nov 2024. https://www.esma.europa.eu
5. SEC. Final Rule: Shortening the Securities Transaction Settlement Cycle. Release No. 34-96930, Feb 2023. https://www.sec.gov/rules/2023/02/shortening-securities-transaction-settlement-cycle
6. European Union. Central Securities Depositories Regulation (CSDR), Regulation (EU) No 909/2014.
7. LCH. Default Management Process. https://www.lch.com/risk-collateral-management
8. 中国证券登记结算公司.《中国结算业务规则》. http://www.chinaclear.cn/
9. 中国人民银行.《人民币跨境支付系统业务运营规则》与《中国支付体系发展报告》. http://www.pbc.gov.cn/
10. 上海清算所.《上海清算所中央对手清算业务规则》. https://www.shclearing.com.cn/
11. DTCC. Project Ion Platform Overview. https://www.dtcc.com/digital-assets
12. Euroclear. D-FMI / Digital Securities Platform White Paper. 2023.
13. ECB. Exploratory work on new technologies for wholesale central bank money settlement. 2024. https://www.ecb.europa.eu/paym/intro/news
14. HKMA. Project Ensemble Sandbox. 2024–2025. https://www.hkma.gov.hk
15. ERC-3643 Association. T-REX Protocol Specification. https://erc3643.org
16. ISO 20022 Payments & Securities Messaging. https://www.iso20022.org

上一篇：《行情分发：MBP/MBO、快照+增量、组播/TCP、FIX/ITCH》

下一篇：《实时风控引擎：规则、特征、模型、决策流、Flink/Spark》