【金融科技工程】11 清算 vs 结算 vs 资金归集：T+0/T+1、Netting、PvP/DvP

引子

写支付系统写到第 11 篇，我越来越发现一个现象：每个工程师都说”我在做清结算”，但没有两个工程师口中的”清结算”是同一件事。

• 做聚合支付的说”清算系统”，指的是按商户、按渠道、按日把流水捞出来算手续费；
• 做银行核心的说”清算”,指的是人行大小额支付系统里的头寸轧差；
• 做 SaaS 平台的说”清算”，指的是每月给上游 ISV 分润结算单；
• 做证券的说”清算”，指的是中证登把买卖双方的证券和资金轧差净额；
• 做企业财资的说”清结算”，其实讲的是集团资金归集与下拨。

这五件事在英文里分别是 Clearing / Netting / Reconciliation + Payout / DvP Clearing / Cash Pooling，在中文里全部挤在”清结算”这三个字里。再加上”结算”这个词，在口语里既可以指”资金真实打到账上”（真正的 Settlement），也可以指”记一笔应收应付账”（其实是会计确认，Accounting），混乱程度再上一个台阶。

本文的目标，就是把这三个高度混淆的概念——清算（Clearing）、结算（Settlement）、资金归集（Cash Pooling）——做一次工程视角的严格区分，并落到真实系统里：

1. 三者在金融基础设施中的边界在哪里；
2. RTGS / DNS / 混合 DNS 三种清算范式的取舍；
3. PvP、DvP 如何用”同时性”消除对手方风险；
4. 商户扫码付款到 T+1 到账的完整资金生命周期；
5. 清分引擎如何实现：“一笔钱进来，拆成商户本金 + 平台抽成 + 服务商返佣 + 税费”；
6. 数据模型：从 transactions 到 payout_orders 的四层流转；
7. 实时清算（网联 IBPS、UPI、PIX、FedNow）在打破 T+1 批处理时，工程上要重做哪些地方。

读者画像：支付平台、清分平台、聚合支付、交易所、财资系统（TMS）、跨境结算等方向的后端工程师与架构师。前置知识建议读过本系列 《支付系统全景》 与 《复式记账工程化》。

一、三个词的工程定义

1.1 先给三个精确定义

三者的关系：Clearing 是”算账”，Settlement 是”付钱”，Cash Pooling 是”搬家”。

举一个商户扫码场景的例子：

1. 消费者付 100 元给商户，微信支付先从消费者零钱扣 100，记到微信商户备付金账户（这是”收款”）；
2. 清算（Clearing）：次日 T+1，微信清分引擎算出”商户 A 本日应收 100 元 − 手续费 0.6 元 = 净额 99.4 元”；
3. 结算（Settlement）：微信通过备付金托管行向商户对公账户发起一笔网银跨行转账，99.4 元真实到账；
4. 资金归集（Cash Pooling）：商户公司财务把旗下 500 个门店对公账户余额，每天 23 点归集到总部主账户做统一现金管理。

步骤 2 只是算，不碰钱；步骤 3 才是真的钱动；步骤 4 与前面完全解耦，是企业集团内部的现金管理动作。

1.2 为什么容易混

历史原因。在纸票时代，清算所（Clearing House）既做轧差计算又做资金划拨，所以两件事放在一个机构、一个批次里做，很多老系统把这两步合在一张表、一个流程里。直到电子化、RTGS 出现以后，两者才需要被明确分开：

• 大额实时支付（RTGS）里，清算和结算是同一刻发生（每笔实时轧一次 = 不轧差，逐笔结算）；
• 小额净额支付（DNS）里，清算与结算是两个不同的时间点（白天收指令，晚上统一轧差，第二天统一结算）。

这篇文章大部分篇幅都在讲 DNS 模式，因为它决定了”为什么商户收款是 T+1 到账”。

1.3 术语地图

二、Gross vs Net：两种清算范式

2.0 最小例子：为什么要轧差

考虑三家银行 A、B、C 之间一日内的跨行支付（单位：亿元）：

A → B  30       B → A  25       C → A  10
A → C  15       B → C  20       C → B   5

不轧差（Gross）：总共 6 条指令，总划转 105 亿，每家都要备足流动性。

双边轧差（Bilateral Netting）：

• A↔︎B：A 付 B 30，B 付 A 25 → A 净付 B 5；
• A↔︎C：A 付 C 15，C 付 A 10 → A 净付 C 5；
• B↔︎C：B 付 C 20，C 付 B 5 → B 净付 C 15。
• 合计 3 条、25 亿。

多边轧差（Multilateral Netting）：

• A：净付 10（付 B 5 + 付 C 5）；
• B：净应收 0（收 A 5，付 C 15，净付 10）；错——重算：B 收 A 5、付 C 15，净付 10；
• C：净应收 20。

最终只需要央行账户做 “A→清算所 10、B→清算所 10、清算所→C 20” 三笔记账，流动性占用从 105 亿降到 20 亿。这就是 DNS 的核心价值。

2.1 RTGS：实时全额结算

RTGS（Real-Time Gross Settlement）：每笔指令独立处理，实时、全额、终局性结算。全球主流大额支付系统都采用 RTGS：

特点：

• 没有清算所的信用风险：每笔都由央行账户实时结算，不存在”中午收了指令，下午清算所倒闭”的情况；
• 流动性占用大：每笔都要求发起行准备足额头寸；
• 吞吐量要求相对低：大额支付笔数少、金额大，RTGS 扛得住。

2.2 DNS：延迟净额结算

DNS（Deferred Net Settlement）：白天累积指令，按约定时点做多边轧差，只结一次净额。小额零售支付系统都采用 DNS：

特点：

• 流动性效率高：1000 笔 A→B、1100 笔 B→A，轧差后只需结 100 笔的差额；
• 有净额头寸风险：从指令确认到净额结算的窗口期内，参与方可能倒闭；
• 配套机制：保证金、信用上限（net debit cap）、损失共担协议（loss-sharing rules）。

2.3 混合：Delayed Net Settlement 的现代形态

RTGS 吞吐低、DNS 有风险，所以现代系统走向”高频小额多边轧差 + 接近终局性”的混合路线：

• LSM（Liquidity Savings Mechanism）：RTGS 里加入节流队列，定时对队列中的指令做多边轧差、一次性结算（如 TARGET2 的 bilateral/multilateral offsetting）；
• Prefunded DNS：参与方先充值保证金到结算账户，保证”最终结不出来”不会出现；CLS 外汇结算、网联都采用这个模型；
• 分钟级轧差：CNAPS BEPS 原本是日终轧差，后续演进为每 30 分钟一次；网联进一步做到逐笔准实时。

工程上记住一条：轧差频率越高 → 越像 RTGS；越低 → 越省流动性但风险越大。这是个光谱，不是二元选择。

三、PvP 与 DvP：同时性消除对手方风险

Clearing 解决”算多少钱”，Settlement 解决”把钱打过去”，但还有一类经典风险：一方已付、另一方未交付（赫斯塔特风险，Herstatt Risk）。解决方式是让两笔资产”同时”易手。

3.1 PvP（Payment versus Payment）：外汇交易

典型代表：CLS（Continuous Linked Settlement），全球最主要的外汇 PvP 机构。流程：

1. 参与行 A（卖 USD 买 EUR）、B（卖 EUR 买 USD）分别把 USD/EUR 存入 CLS 在美联储/ECB 的账户；
2. CLS 同时借记 A 的 USD 子账户、贷记 B 的 USD 子账户；同时借记 B 的 EUR、贷记 A 的 EUR；
3. 如果任何一腿失败，整笔交易回滚。

效果：不存在”A 付了美元、B 没付欧元”的中间状态。CLS 上线前，赫斯塔特风险是外汇市场的核心系统性风险；上线后，这个风险被极大消除。

3.2 DvP（Delivery versus Payment）：证券交易

BIS 定义了三种 DvP 模型：

中国 A 股 T+1 结算是典型的 DvP-3：日终由中证登做多边净额轧差，证券和资金同时过户。这篇不展开，《证券登记结算》 会专门讲。

3.3 工程启示

PvP/DvP 对支付工程师的启示不是让你去实现一个 CLS，而是：当你设计任何”两方换资产”的场景时，要想到如何保证同时性。对应到 SaaS 场景：

• 账户 A 给账户 B 转账：单边系统，用数据库事务就够；
• 跨系统换资产（如积分换优惠券、稳定币换法币）：必须设计类似 PvP 的原子结算机制，本质是 《幂等、事务与一致性》 里讲的 SAGA/TCC 在结算场景的应用。

四、清算周期：T+N 的来龙去脉

4.1 T+N 的定义

T 指交易日（Trade Date），T+N 指交易日后第 N 个工作日资金到账。T+0 当日到账，T+1 次工作日到账，T+2 两个工作日后到账。注意两点：

• N 指工作日：周五 T+1 = 下周一；周五 T+2 = 下周二；
• “到账”指”可用”：银行系统可能早早就记账了，但只有清算结束后才真正可支配。

4.2 T+N 越来越短

历史趋势：

推动力：资本效率、降低对手方风险、技术进步。工程成本：清算窗口从”一天”压缩到”几分钟”，所有原本跑在晚上的批任务都要重写成准实时流。

4.3 商户结算的 T+N 生态

T+N 的本质是风险冻结期：留出时间应对退款、拒付（chargeback）、反欺诈复核；周期越短，平台风险越高，手续费越贵。

五、商户结算的资金流

5.1 备付金账户与二清红线

先看一张典型聚合支付的资金路径：

flowchart LR
    U[消费者账户] -->|1. 支付| C[收单行/支付机构备付金账户]
    C -->|2. 日终清算| N[清算机构<br>网联/CUP]
    N -->|3. 跨行净额结算| B[备付金托管行]
    B -->|4. T+1 结算| M[商户对公账户]
    AGG[聚合支付服务商] -.只做技术对接.-> C
    style AGG stroke-dasharray: 5 5

关键词：

• 备付金（Reserve）：支付机构代客户保管的待结算资金，必须 100% 集中存管于人行指定的托管行，不得挪用、不得沉淀；
• 二清：资金没有经过持牌机构直接结算到商户，而是在某个中间主体（通常是没牌照的聚合服务商）的自有账户里过了一道——这是监管明令禁止的；
• 合规的聚合支付：只做技术聚合（路由、对账、SDK），资金流必须是持牌机构直接清算到商户对公账户；
• 分账（Split）：一笔交易按规则拆给多方（商户本金、平台抽成、ISV 返佣），是持牌支付机构提供的功能（例如微信分账、支付宝分账），不得由聚合商自己在中间”分”。

5.2 一笔扫码的完整生命周期

sequenceDiagram
    autonumber
    participant C as 消费者
    participant WX as 微信支付
    participant 备付 as 备付金托管行
    participant 清算 as 网联 IBPS
    participant 商行 as 商户开户行
    participant M as 商户
    Note over C,M: T 日 14:30 消费者扫码付 100 元
    C->>WX: 扫码授权 100 元
    WX->>WX: 风控、扣消费者零钱
    WX->>备付: 记入商户 A 可结算余额<br>（应收 100，手续费 0.6）
    WX-->>C: 支付成功
    WX-->>M: 商户通知：收款 100 元（可结算 99.4）
    Note over WX,清算: T 日 23:00 日终清分
    WX->>WX: 清分引擎按商户汇总<br>生成结算单
    WX->>清算: T+1 08:00 发起跨行结算指令
    Note over 清算,商行: T+1 上午 多边轧差 + 头寸结算
    清算->>备付: 借记 微信备付金
    清算->>商行: 贷记 商户开户行
    商行->>M: 贷记 商户对公账户 99.4 元
    M-->>M: 收到银行到账短信

对工程师的启示：“商户 T+1 到账”不是一个单体服务能完成的事，它横跨支付机构、清算机构、两家商业银行，每一步都有自己的 SLA 和失败模式。本系列 《对账系统工程》 会专门讲如何对这条链路做端到端对账。

5.3 失败场景

六、清分引擎的工程实现

前面说清算是”算谁欠谁多少”，这里我们把它拆成实际的代码和数据结构。

6.1 输入与输出

输入：
  - 交易流水表（transactions）：当日全量成功交易
  - 清分规则：按商户、按渠道、按 ISV 层级配置
  - 费率模板：固定 + 百分比 + 阶梯
  - 日历：工作日、冻结日
  - 退款、争议：需要从可结算中扣减

输出：
  - 清算记录（clearing_records）：每个参与方每日净额
  - 结算指令（settlement_instructions）：待发送给支付通道的打款包
  - 结算单（statements）：给每个商户/ISV 的对账明细
  - 差错报告（exceptions）：待人工处理

6.2 清分维度：一笔钱怎么拆

一笔 100 元交易，真实拆分可能是：

商户 A 实收本金：     96.00
  - 平台抽成：         3.00 → 平台主体账户
  - ISV 返佣：         0.50 → ISV 分润账户
  - 收单手续费：       0.60 → 支付机构
  - 渠道网络费：       0.06 → 卡组织/清算机构
  - 代扣代缴税费：     0.00 → 税务代收（跨境 VAT/GST 场景）
检查：96.00 + 3.00 + 0.50 + 0.60 + 0.06 = 100.16 ≠ 100 × ? 

实际工程里拆分规则一定要满足守恒（sum = 原始金额），任何四舍五入的余数必须明确归属（通常归平台或商户，配置决定）。本系列 《钱的建模》 详细讨论过 minor unit 与舍入。

6.3 规则 DSL

平台要支持产品同学/BD 自己配置清分规则，工程上通常选其中一种：

方案 A：规则引擎（Drools、Aviator、LiteFlow）。优点灵活，缺点调试难、性能有坑。 方案 B：声明式 DSL + JSON/YAML 配置。推荐给 80% 的中小平台。

# 清分规则示例
rule_id: "merchant_A_default_2026"
merchant_id: "M000001"
effective: "2026-01-01"
splits:
  - name: platform_fee
    recipient: "ACC_PLATFORM"
    formula: "amount * 0.006"          # 千六
    rounding: half_up
    min: 0.01
  - name: isv_rebate
    recipient: "ACC_ISV_{{isv_id}}"
    formula: "amount * 0.001"          # ISV 千一返佣
    condition: "isv_id != null"
  - name: merchant_net
    recipient: "ACC_MERCHANT_{{merchant_id}}"
    formula: "amount - platform_fee - isv_rebate"
    is_primary: true                    # 主商户本金（承担舍入余数）

方案 C：SQL/表达式列。所有规则落成一列表达式，清分时用表达式引擎批量求值——对 BI 和财务最友好。

6.4 批处理还是流式

T+1 场景下的典型批处理：

23:00  冻结当日交易流水快照（从 MySQL/TiDB 抽到数仓）
23:10  按商户分片执行清分规则（Spark/Flink 批）
23:40  生成 clearing_records
23:50  按结算账户汇总 → settlement_instructions
00:00  生成对账单（发邮件/推送）
08:00  下发打款指令到支付通道（银企直连/代付 API）

实时清算（T+0）下改流式：每笔交易成功后立即触发清分（单笔执行一次规则），直接入 clearing_records，定时（分钟级）合并推给支付通道。核心是把清分规则做成纯函数 + 幂等，可批可流。

6.5 差错处理

漏算、重算是清分引擎的日常：

• 漏算：昨日跑批时某笔交易状态未定（支付异步回调迟到），今日补算时从昨日快照拉取 + 今日增量一起跑——切记不能重复算昨日已清分部分，靠 cleared_at 幂等字段控制；
• 重算：因为规则改错要重跑——先 UPDATE ... SET status='voided' 把旧清算记录作废，生成反向记录平账，再跑新规则；
• 隔日补：T+1 未结算成功（银行返错），T+2 补发时要生成新的 settlement_instruction，关联原 clearing_record，保证单一来源。

原则：永远不要在数据库里 DELETE 清算/结算记录，全部走”作废+反向”。这是金融可追溯性的底线。

七、数据模型

四层流转：交易 → 清算 → 结算指令 → 打款单。

-- 1. 原始交易流水（支付系统主表）
CREATE TABLE transactions (
    txn_id          VARCHAR(32) PRIMARY KEY,
    merchant_id     VARCHAR(32) NOT NULL,
    amount          DECIMAL(20,4) NOT NULL,
    currency        CHAR(3) NOT NULL,
    status          VARCHAR(16) NOT NULL,   -- SUCCESS/REFUNDED/...
    channel         VARCHAR(32),             -- WECHAT/ALIPAY/UNIONPAY
    paid_at         TIMESTAMP,
    clearing_status VARCHAR(16) DEFAULT 'PENDING', -- PENDING/CLEARED/VOIDED
    INDEX idx_merchant_paid (merchant_id, paid_at)
);

-- 2. 清算记录（算完的净额，每个参与方一行）
CREATE TABLE clearing_records (
    clearing_id     VARCHAR(32) PRIMARY KEY,
    batch_id        VARCHAR(32) NOT NULL,    -- 清算批次，如 "20260422-T1"
    txn_id          VARCHAR(32) NOT NULL,    -- 对应交易
    recipient_id    VARCHAR(32) NOT NULL,    -- 收款方（商户/平台/ISV）
    recipient_type  VARCHAR(16) NOT NULL,    -- MERCHANT/PLATFORM/ISV/FEE
    amount          DECIMAL(20,4) NOT NULL,  -- 可为负（退款）
    currency        CHAR(3) NOT NULL,
    rule_id         VARCHAR(32),
    cleared_at      TIMESTAMP NOT NULL,
    status          VARCHAR(16) DEFAULT 'ACTIVE', -- ACTIVE/VOIDED
    INDEX idx_batch_recipient (batch_id, recipient_id),
    UNIQUE KEY uk_txn_recipient_type (txn_id, recipient_type, recipient_id)
);

-- 3. 结算指令（按收款方 + 收款账户汇总，一行=一笔打款）
CREATE TABLE settlement_instructions (
    instruction_id   VARCHAR(32) PRIMARY KEY,
    batch_id         VARCHAR(32) NOT NULL,
    recipient_id     VARCHAR(32) NOT NULL,
    recipient_account VARCHAR(64) NOT NULL,  -- 收款银行账户
    recipient_bank   VARCHAR(32) NOT NULL,
    amount           DECIMAL(20,4) NOT NULL, -- 本批净额
    currency         CHAR(3) NOT NULL,
    scheduled_at     TIMESTAMP NOT NULL,     -- 计划发送时间
    status           VARCHAR(16) DEFAULT 'PENDING', -- PENDING/SENT/SUCCESS/FAILED
    INDEX idx_batch (batch_id),
    INDEX idx_scheduled (scheduled_at, status)
);

-- 4. 打款单（真实调用通道后的结果，带通道流水号）
CREATE TABLE payout_orders (
    payout_id        VARCHAR(32) PRIMARY KEY,
    instruction_id   VARCHAR(32) NOT NULL,
    channel          VARCHAR(32) NOT NULL,   -- 银企直连通道
    channel_txn_id   VARCHAR(64),            -- 银行返回流水
    amount           DECIMAL(20,4) NOT NULL,
    status           VARCHAR(16) NOT NULL,   -- INIT/SUBMITTED/SUCCESS/FAILED
    submitted_at     TIMESTAMP,
    confirmed_at     TIMESTAMP,
    error_code       VARCHAR(32),
    error_msg        VARCHAR(255),
    FOREIGN KEY (instruction_id) REFERENCES settlement_instructions(instruction_id),
    INDEX idx_status (status, submitted_at)
);

关键约束：

1. clearing_records 的 (txn_id, recipient_type, recipient_id) 唯一：一笔交易对某方只能清算一次，强幂等；
2. settlement_instructions 是 clearing_records 按 (batch_id, recipient_id) 的 SUM，可以从下游反推上游；
3. payout_orders 与 settlement_instructions 是 1 对多（通道失败重试会产生多条 payout），最终只有一条 SUCCESS 的 payout 生效；
4. 跨四层的核心审计查询：给定一笔 txn，能追出对应的所有 clearing、instruction、payout，反之亦然。

7.1 与账务系统的关系

这里要特别明确一个常见误解：清算 ≠ 记账，结算 ≠ 记账。

清算和结算是业务流程，账务是财务视角的记录。完整的工程做法是：

• 交易成功 → 账务系统记一笔”应收账款”分录（Dr: 客户 Cr: 应付商户）；
• 清算完成 → 账务确认分润/税费分录（Dr: 应付商户 Cr: 平台收入 + 应付 ISV + …）；
• 结算到账 → 账务记一笔”应付商户”核销分录（Dr: 应付商户 Cr: 备付金银行存款）。

前后端分离的意思是：清分引擎不直接动账务表，而是把事件发到账务系统（或输出对账文件），由账务系统按自己的节奏入账。这样规则变更、差错补算不会污染总账。细节见 《复式记账工程化》。

八、资金归集：企业财资的第三件事

8.1 定义

资金归集（Cash Pooling）：集团把下属子公司、门店、项目的分散账户余额，定期集中到总部主账户的动作。对立面是分散账户各管各的现金流。

两种主要模式：

跨境归集还要叠加 CTA（Cross-border Two-way RMB）、FDI/ODI 限额、外管局备案等，复杂度陡增。

8.2 和清结算的边界

为什么把资金归集放在这篇？因为工程语境里有三种”你以为是同一个”的产品，其实都叫 Cash Pooling 系统：

1. 企业 TMS（Treasury Management System）里的归集：服务集团财务，接银企直连拉多账户余额、下发归集指令；
2. 支付平台商户结算里的”归集账户”：把多个门店、多个收单通道的应结余额先归集到商户的一个主账户，再统一打款——这是支付机构提供的功能；
3. 虚拟账户（Virtual Account）产品：银行提供给企业的”一实多虚”账户，虚拟账户收款、物理主账户结算，本质是内建 Cash Pooling。

这三个系统在底层都做同一件事：把离散的账户余额聚合到一个可控主账户。它和 Clearing/Settlement 的区别：Clearing 处理外部对手方的债权债务，Cash Pooling 只处理企业内部账户之间的资金搬家。

8.3 工程要点

• 和商业银行签电子银行协议（企业网银 API / 银企直连），拿到批量查询余额、批量转账的接口；
• 归集指令幂等（银行流水号去重）；
• 多币种归集要考虑汇率损失归属（谁承担汇兑损益）；
• 归集时机避开业务高峰（通常 22:00 之后）；
• 风控：归集金额、对手账户白名单、审批流、双人复核。

九、实时化：T+1 批处理正在消亡

9.1 全球实时支付基建

过去五年，几乎每个主要经济体都上线了自己的 实时零售支付系统（Instant Payment System, IPS）：

这些系统对清结算工程的冲击：

1. 清算频率从日终变成逐笔：原来 T+1 批处理，现在每笔都要算净额/结算；
2. 24×7 运营：传统”日切”（day-cutover）概念被打破——系统没有”停业时间”；
3. 流动性管理 24 小时化：央行对参与方的流动性设计必须支持周末/节假日；
4. 终局性要求秒级：不能再用”白天先算晚上结”的 DNS，而是要接近 RTGS 的实时结算。

9.2 工程侧的改造清单

如果你在做一个老支付系统的 T+0 改造，这些是必改项：

• 去日切：账务、清分、结算都不能依赖”日终批处理”做状态流转；
• 事件驱动清分：交易事件 → 立即清分 → 立即结算指令（而不是 cron 拉全表）；
• 24×7 银行通道：确认上游银行通道是否支持 7×24 结算（如 FedNow、网联）；
• 流动性监控实时化：备付金余额、净头寸指标从日频变成分钟频；
• 退款/撤销模型重写：T+1 下退款就是下一批次扣减，T+0 下是实时反向指令；
• 会计日与自然日解耦：账务日（Accounting Date）仍可以按业务切日，但不再等价于”系统停业”；
• 对账改为流式对账：不再等 T+1 全量文件，改为逐笔/分钟级对账。

参考本系列 《金融级可靠性》 24×7 相关章节。

九·补、清分引擎的工程实现补完

9.补.1 清分核心伪代码

下面是一个可以直接照抄改写的清分主循环（Python 伪代码），覆盖守恒校验、舍入归属、幂等、作废。

from decimal import Decimal, ROUND_HALF_UP
from dataclasses import dataclass
from typing import List

Q4 = Decimal("0.0001")

@dataclass
class Split:
    name: str
    recipient_id: str
    recipient_type: str
    amount: Decimal
    rule_id: str
    is_primary: bool = False

def clear_one_txn(txn, rules) -> List[Split]:
    """对单笔交易应用规则集，返回拆分结果。保证 sum(splits) == txn.amount。"""
    splits: List[Split] = []
    used = Decimal("0")

    # 1. 先算所有非 primary 拆分
    for r in rules:
        if r.is_primary:
            continue
        if not r.match(txn):
            continue
        raw = r.formula(txn)                      # 例如 txn.amount * 0.006
        amt = raw.quantize(Q4, rounding=ROUND_HALF_UP)
        if r.min is not None and amt < r.min:
            amt = r.min
        splits.append(Split(r.name, r.recipient(txn), r.recipient_type,
                            amt, r.rule_id, is_primary=False))
        used += amt

    # 2. 主商户本金 = 原金额 - 其它拆分（承担所有舍入余数）
    primary_rule = next(r for r in rules if r.is_primary)
    primary_amt = (txn.amount - used).quantize(Q4, rounding=ROUND_HALF_UP)
    if primary_amt < 0:
        raise ClearingError(f"negative primary amount for txn={txn.id}")
    splits.append(Split(primary_rule.name, primary_rule.recipient(txn),
                        primary_rule.recipient_type, primary_amt,
                        primary_rule.rule_id, is_primary=True))

    # 3. 守恒校验
    total = sum(s.amount for s in splits)
    if total != txn.amount:
        raise ClearingError(
            f"conservation violated: txn={txn.amount} splits={total}")
    return splits

def persist(txn, splits, batch_id):
    """幂等写入 clearing_records。唯一键 (txn_id, recipient_type, recipient_id)。"""
    with tx_begin():
        existing = db.query(
            "SELECT 1 FROM clearing_records "
            "WHERE txn_id=%s AND status='ACTIVE'", (txn.id,))
        if existing:
            return   # 已清分，天然幂等
        for s in splits:
            db.execute(
                "INSERT INTO clearing_records "
                "(clearing_id, batch_id, txn_id, recipient_id, recipient_type, "
                " amount, currency, rule_id, cleared_at, status) "
                "VALUES (%s,%s,%s,%s,%s,%s,%s,%s,NOW(),'ACTIVE')",
                (uuid(), batch_id, txn.id, s.recipient_id, s.recipient_type,
                 s.amount, txn.currency, s.rule_id))
        db.execute(
            "UPDATE transactions SET clearing_status='CLEARED' "
            "WHERE txn_id=%s AND clearing_status='PENDING'", (txn.id,))

要点：

1. 主（primary）拆分承担舍入余数，避免 “分润 + 本金 ≠ 原交易” 的守恒性 bug；
2. clear_one_txn 是纯函数，批处理 / 流处理共用同一份代码；
3. persist 是幂等入口，唯一键保证重入不会翻倍；
4. 守恒校验作为最后一道闸门，失败直接阻断（而不是记 warning 继续跑，否则差错会被雪藏）。

9.补.2 作废与反向重算

规则变更后必须重算历史数据时，正确姿势：

-- A. 找出需要重算的批次
SELECT DISTINCT batch_id FROM clearing_records
WHERE rule_id = 'merchant_A_default_2025' AND cleared_at >= '2026-04-01';

-- B. 对每个 batch，先作废旧记录
UPDATE clearing_records SET status='VOIDED', voided_at=NOW(),
       voided_reason='rule_v2_recompute'
WHERE batch_id = :b AND rule_id='merchant_A_default_2025';

-- C. 生成反向清算记录（给总账抹平）
INSERT INTO clearing_records (..., amount, ..., status, source_clearing_id)
SELECT clearing_id_new, batch_id, txn_id, recipient_id, recipient_type,
       -amount, currency, 'REVERSAL', NOW(), 'ACTIVE', clearing_id
FROM clearing_records
WHERE batch_id = :b AND status='VOIDED'
  AND voided_reason='rule_v2_recompute';

-- D. 按新规则重新清分
CALL rerun_clearing(:b, 'merchant_A_default_2026');

-- E. 差额结算：如果新净额 > 旧净额 → 补结算；< → 下批次抵扣

关键：A/B/C 三步必须在一个审计批次里完成，否则总账会临时对不上。

9.补.3 结算指令的聚合与拆单

从 clearing_records 到 settlement_instructions 的聚合：

INSERT INTO settlement_instructions
  (instruction_id, batch_id, recipient_id, recipient_account,
   recipient_bank, amount, currency, scheduled_at, status)
SELECT
  UUID(), cr.batch_id, cr.recipient_id,
  acc.account_no, acc.bank_code,
  SUM(cr.amount), cr.currency,
  next_biz_day(cr.batch_id) + INTERVAL 8 HOUR,
  'PENDING'
FROM clearing_records cr
JOIN settlement_accounts acc
  ON acc.recipient_id = cr.recipient_id AND acc.is_default = 1
WHERE cr.batch_id = :b AND cr.status='ACTIVE'
GROUP BY cr.batch_id, cr.recipient_id, acc.account_no,
         acc.bank_code, cr.currency
HAVING SUM(cr.amount) > 0;

坑点：

• HAVING SUM(cr.amount) > 0：净额 ≤ 0 的不生成打款指令（余额会滚到下一批次），但如果是负数（退款>当期收入）则要触发催款流程；
• 单币种聚合：同一 recipient 的 USD/CNY 清算记录不能合成一条指令；
• 单笔打款超限：很多银行单笔代付上限 500 万或 5000 万，超限要自动拆单，拆单后每一子单仍要保留对原 batch_id 的追溯。

补充、清结算状态机与端到端追溯

补.1 交易—清算—结算状态机

一笔交易从”用户扫码”到”商户账户到账”，在平台侧经历多个状态：

stateDiagram-v2
    [*] --> PAYING: 用户发起支付
    PAYING --> PAID: 通道成功
    PAYING --> FAILED: 通道拒绝
    PAID --> CLEARED: 清分引擎批处理完成
    PAID --> REFUNDED: 用户申请退款
    CLEARED --> SETTLING: 下发银行代付指令
    CLEARED --> REFUNDED: 延迟退款（清算后）
    SETTLING --> SETTLED: 银行回执成功
    SETTLING --> SETTLE_FAILED: 银行回执失败
    SETTLE_FAILED --> SETTLING: 重试/改账户
    REFUNDED --> CLEARED: 退款完成后继续参与下期净额
    SETTLED --> [*]
    FAILED --> [*]

每个状态迁移必须有数据库唯一事件记录（who/when/why），以便审计和复现。

补.2 追溯查询：一笔钱的全链路

给业务侧、财务侧、合规侧一个统一的 “透视” SQL 视图：

CREATE VIEW v_money_trace AS
SELECT
    t.txn_id,
    t.merchant_id,
    t.amount        AS txn_amount,
    t.paid_at,
    cr.clearing_id,
    cr.recipient_id AS cr_recipient,
    cr.amount       AS cr_amount,
    cr.status       AS cr_status,
    si.instruction_id,
    si.amount       AS si_amount,
    si.status       AS si_status,
    po.payout_id,
    po.channel,
    po.channel_txn_id,
    po.status       AS po_status,
    po.confirmed_at
FROM transactions t
LEFT JOIN clearing_records cr
    ON cr.txn_id = t.txn_id AND cr.status='ACTIVE'
LEFT JOIN settlement_instructions si
    ON si.batch_id = cr.batch_id AND si.recipient_id = cr.recipient_id
LEFT JOIN payout_orders po
    ON po.instruction_id = si.instruction_id AND po.status='SUCCESS';

这个视图有两个设计哲学：

1. LEFT JOIN：任何一层失败，其它层的数据仍然可见，便于定位断点；
2. 只 JOIN SUCCESS 的 payout：如果一笔 instruction 做过 3 次重试，只展示最终成功那条，避免前端误解。

补.3 每日自检 SQL

给运营团队的每日自检脚本（跑在 T+1 早晨，发邮件）：

-- 1. 有多少 PAID 但未 CLEARED 的交易（可能漏算）
SELECT DATE(paid_at) AS d, COUNT(*), SUM(amount)
FROM transactions
WHERE status='SUCCESS' AND clearing_status='PENDING'
  AND paid_at < CURRENT_DATE - INTERVAL 1 DAY
GROUP BY DATE(paid_at);

-- 2. 有多少 CLEARED 但未生成 instruction 的
SELECT cr.batch_id, COUNT(*) FROM clearing_records cr
LEFT JOIN settlement_instructions si
  ON si.batch_id=cr.batch_id AND si.recipient_id=cr.recipient_id
WHERE cr.status='ACTIVE' AND si.instruction_id IS NULL
  AND cr.cleared_at < CURRENT_DATE - INTERVAL 1 DAY
GROUP BY cr.batch_id;

-- 3. 有多少 instruction 卡在 SENT 超过 12 小时未确认
SELECT COUNT(*) FROM settlement_instructions
WHERE status='SENT' AND scheduled_at < NOW() - INTERVAL 12 HOUR;

-- 4. 当日守恒校验：sum(transactions) 是否等于 sum(clearing_records by batch)
SELECT cr.batch_id, SUM(cr.amount) AS sum_splits,
       (SELECT SUM(amount) FROM transactions
        WHERE txn_id IN (SELECT txn_id FROM clearing_records
                         WHERE batch_id=cr.batch_id AND status='ACTIVE'))
        AS sum_txn
FROM clearing_records cr
WHERE cr.status='ACTIVE' AND cr.batch_id=:today_batch
GROUP BY cr.batch_id
HAVING sum_splits <> sum_txn;

第 4 条必须返回空集。返回非空就是 P0：清分引擎吐出的净额不守恒，必须立即停止下发结算指令。

十、真实案例速览

10.1 支付宝商户结算

• 标准商户默认 T+1 工作日结算到对公账户；
• 开通”极速到账（D+0）“要按笔付费，风控准入严；
• 跨境商户结算 T+2 或 T+3（含外汇结售汇与出口收汇登记）；
• 分账通过”支付宝分账”产品完成，资金不落聚合服务商账户；
• 备付金 100% 存管在人行指定托管行，按季度公布。

10.2 微信支付商户结算

• 小微商户 T+1 到银行卡；
• 服务商模式下，平台商户 + 子商户，分账规则在商户号维度下发；
• 2018 年以后，备付金全额集中交存人民银行（100% 准备金率）；
• 商户结算由合作银行完成最后一公里，微信只下发指令。

10.3 快钱、拉卡拉分账

• 提供”拆分结算”接口，一笔交易按规则拆给多个商户/账户；
• 分账必须持牌：支付机构或银行；聚合商做分账属于二清，违规；
• 2016 年后，银联商务、拉卡拉都合规化为分账服务商，聚合支付只做技术对接。

10.4 Stripe payout

• 默认 2 个工作日（US）或 7 个工作日（国际），新商户会有更长 rolling reserve；
• 面板清晰展示每笔 payout 对应哪些 charges（类似本文 settlement_instruction → clearing_records 的反向穿透）；
• Stripe Connect 的平台模式支持”按交易拆给 connected account + platform fee”，即平台分账。

10.5 Adyen settlement

• 按合同配置的结算周期（T+1 到 monthly 都可）；
• 多币种：Adyen 在一侧收本地币种，另一侧按商户偏好币种结算，汇率锁定逻辑在 settlement 阶段执行；
• 结算报告（Settlement Details Report）给财务做对账，字段粒度细到 scheme fee、interchange、markup。

十一、工程坑点

1. 把清算规则写死在结算服务里——规则变更要改代码，BI 无法复核。务必规则与执行分离，规则独立版本化。
2. 清分幂等靠 INSERT IGNORE——看似工作正常，但改规则重算时静默跳过，数据永远是旧值。正确做法：唯一键 + 显式”作废+重插”流程。
3. 结算金额和清算金额不对齐——分钱分到一半加了一条新规则没同步到主商户本金公式，出现分润合计 ≠ 原金额。必须在清分引擎里加守恒校验，不过就直接失败阻断。
4. T+N 日历没把海外节假日考虑进去——跨境结算 T+2 撞上美国 Memorial Day 直接变 T+4，客户投诉。日历要按币种/清算机构分别维护。
5. 用一个单体结算服务跑所有商户——头部商户一次结算数百万笔，尾部 10 万商户各自几十笔，单体服务做 CPU 分配极难。应按商户/批次分片。
6. 结算下发到银行通道没做限流——银企直连有 QPS 限制，批量下发打爆通道导致部分指令丢失。限流 + 分批 + 断点续传是必须。
7. 退款不从下期结算扣，而是等商户回款——80% 商户余额不够，产生大量呆账。正确做法：退款即刻冻结商户可结算余额，不足再走代偿流程。
8. 二清边界模糊——技术服务费、营销返佣、代收代付全部走了自有账户，一旦被监管盯上直接注销牌照。资金路径必须持牌直通，任何”过个手再分”都要重新审视。
9. 备付金客户出金与支付结算混在一起——支付备付金不是商户可随意划转的资金，商户出金/提现必须独立账户、独立流程。
10. 对账数据来自清分引擎自身——自己对自己，永远对得平。对账源必须是外部的银行流水 / 通道回单，不能用本地表做”假对账”。

十二、落地清单

清结算平台从 0 到 1 的最小可行路径：

1. 把三个词讲清：在架构评审前，先把 Clearing/Settlement/Cash Pooling 的边界在文档里画死，避免跨团队扯皮；
2. 沉淀交易流水表：任何清分的前提是唯一权威的交易流水源；不要让每个业务方自己维护交易表；
3. 规则可配置：从 YAML/DB 配置起步，后续再考虑规则引擎；
4. 四层数据模型：transactions → clearing_records → settlement_instructions → payout_orders 一步到位，不要为了”简单”合并其中两层；
5. 幂等与作废：任何清算/结算记录不删不改，只作废；
6. 守恒校验：清分产出必须通过”sum 原交易 = sum 拆分”的自动校验；
7. 工作日历服务化：独立的 calendar 服务，按币种/清算网络维护；
8. 批与流统一：清分规则写成纯函数，批处理和流处理共用同一份代码，方便后续 T+0 化；
9. 端到端对账：从支付通道对回单 → 清算净额 → 结算指令 → 打款回执，四层都要对；
10. 合规评审：资金路径设计必须过合规评审，二清是生死线；
11. 异常人工台：差错处理界面与工单流，占开发量至少 30%，别省；
12. 灰度发布规则变更：清分规则的灰度方式是”双跑比对”——新规则算一遍不入库，与旧规则结果对比通过后再切。

十三、选型建议

一句话选型：额度大、少量笔、对终局性敏感 → RTGS；小额、海量、能容忍 T+N → DNS；中间地带 → 现代混合 DNS + 逐笔近实时。

参考资料

1. BIS CPMI, “Principles for Financial Market Infrastructures (PFMI)”, 2012. https://www.bis.org/cpmi/publ/d101.htm
2. BIS CPMI, “Delivery versus Payment in Securities Settlement Systems”, 1992. https://www.bis.org/cpmi/publ/d06.htm
3. CLS Bank, “How CLS Settlement Works”. https://www.cls-group.com/
4. 中国人民银行，《中国支付体系发展报告》年度版。http://www.pbc.gov.cn
5. 中国人民银行，《非银行支付机构客户备付金存管办法》。
6. 网联清算公司官网。https://www.nucc.com/
7. U.S. SEC, “Shortening the Securities Transaction Settlement Cycle” Final Rule (T+1), 2023. https://www.sec.gov/rules/final/2023/34-96930.pdf
8. Federal Reserve, “FedNow Service”. https://www.frbservices.org/financial-services/fednow
9. Banco Central do Brasil, “PIX”. https://www.bcb.gov.br/estabilidadefinanceira/pix
10. European Central Bank, “TARGET2 / T2 / TIPS”. https://www.ecb.europa.eu/paym/target/html/index.en.html
11. Stripe Docs, “Payouts”. https://docs.stripe.com/payouts
12. Adyen Docs, “Settlement”. https://docs.adyen.com/reporting/settlement-details-report

十三、补充专题：几个容易被忽视的工程细节

13.1 结算日历服务

每个清算网络都有自己的工作日历，一个跨境平台经常要同时维护十几套：

{
  "calendar_id": "CNY_CNAPS",
  "weekend": ["SAT", "SUN"],
  "holidays_2026": [
    "2026-01-01", "2026-02-16", "2026-02-17", "2026-02-18",
    "2026-04-04", "2026-04-05", "2026-04-06", "2026-05-01",
    "2026-06-19", "2026-10-01", "2026-10-02", "2026-10-03"
  ],
  "half_days": [
    {"date": "2026-12-31", "cutover": "12:00"}
  ]
}

所有涉及”T+N”的地方都必须调用 calendar.add_business_days(trade_date, n, calendar_id)，千万不要用 date + timedelta(days=n)。

13.2 跨币种清算

平台如果同时收 CNY 和 USD，清分引擎的每条规则必须带币种维度，且同一 recipient 在不同币种下可能有不同账户。一条原始交易只能有一种币种；清分输出的拆分必须保持这一币种，绝不允许规则里做”自动换算”——换汇必须是独立的、显式的交易。

13.3 分账”三方约束”与分账服务商

分账的合规基线：分账的每一方都必须是真实服务的提供者。支付机构（如支付宝、微信）的分账产品一般要求：

• 分账的接收方已经完成商户入网（KYB）；
• 每笔分账必须能追溯到一笔真实的底层交易（即分账金额 ≤ 底层交易金额）；
• 分账比例/规则须事先向支付机构备案，不得被任意修改；
• 分账冻结期内可撤销（通常 T+0 内可撤回）。

这些约束决定了你作为平台方，不能把”分账”当万金油用——比如把员工工资、税费代扣都塞到分账里，会被风控拦掉。工资走代付，税费走税务接口。

13.4 日切（Cut-Over）语义

“日切”这个词在传统批处理系统里有明确含义：在某个时刻（如 23:59:59）冻结当日账本、启动清算批、次日开新账本。工程上两个坑：

1. 日切期间系统不可用：老式银行核心在日切 30 分钟内所有查询/交易都失败。现代系统要求日切对用户无感知（通过”会计日”与”自然日”解耦）；
2. T 日交易能不能补录：严格做法是日切后 T 日账本只读，补录走 T+1 调整分录；宽松做法允许日切后短时间内补录 T 日账本，但必须有”追溯修改”审计。

实时清算系统打破日切后，你需要一个”会计日（Accounting Date）“字段挂在每条记录上，这个字段由业务自己打，不由”系统时间”隐式决定。

13.5 争议与 Chargeback 对清算的影响

卡支付特有的 Chargeback（拒付）发生在交易完成后 120/180 天内，一旦发生：

• 平台已经把钱结给商户了（比如 T+1 到账，180 天后才发生拒付）；
• 需要从商户后续结算中扣回，商户余额不足时平台垫付；
• 部分高风险行业（航旅、奢侈品、游戏）要求预留 rolling reserve（5%-20%），即把部分结算金额延迟 30-180 天。

清分引擎要内置”预留冻结”规则：

- name: rolling_reserve
  recipient: "ACC_RESERVE_{{merchant_id}}"
  formula: "amount * 0.05"
  release_after_days: 90
  condition: "merchant.risk_level >= 'HIGH'"

释放机制通过独立的”冻结释放批次”执行，释放时生成一条新的 clearing_record（从冻结账户转出到商户账户）。

十四、总结：把三件事焊在脑子里

设计系统时，先判断你要建的是哪一件——不要建一个”清结算归集中台”试图一次性搞定三件事，一定会变成烂泥潭。真正的中台是账务系统，它是这三件事共同的数据底座；清算、结算、归集分别是三个独立的业务域，各有自己的数据模型、SLA、合规边界。

上一篇：《订阅与计费系统：用量计量、账单、发票、出海 VAT/GST》

下一篇：《央行支付系统：CNAPS、CIPS、Fedwire、TARGET2、SWIFT gpi》