【金融科技工程】央行支付系统：CNAPS、CIPS、Fedwire、TARGET2、SWIFT gpi

引入：央行为什么要自己跑一套支付系统

在本系列第 11 篇《清算 vs 结算 vs 资金归集》中，我们把 “净额（Netting）— 清算（Clearing）— 结算（Settlement）” 这三层拆开看。一个很自然的问题是：最终结算到底发生在哪里？

答案是：央行的账本。

无论是支付宝一次扫码、Fedwire 一笔十亿美金汇款、SEPA 里欧元的跨境直接借记，最终 “钱从 A 银行流到 B 银行” 都必须落在央行为各商业银行开立的备付金账户（Reserve Account）之间。这件事之所以严肃，是因为央行是 唯一不会破产的对手方——它发行本币，没有信用风险（当然有主权风险，但那是另一个话题）。

本篇的读者画像：

• 支付工程师：你写的 API 最终会命中一条 CNAPS 报文或一条 SWIFT MT103，想知道自己发的字段最终跑去了哪里；
• 跨境 / 结算方向：你要接入 CIPS 或 TARGET2，需要搞清楚 “直接参与者” 和 “间接参与者” 的区别；
• 架构师：你要设计一个多币种支付网关，需要理解 RTGS（实时全额）和 DNS（延迟净额）的取舍。

本文不是法规手册，我们关心 报文怎么走、时间窗口怎么卡、参与者怎么接入、典型故障长什么样。

一、央行支付系统的基本术语与分类

1.1 RTGS、DNS、FPS 三种清算模式

• RTGS（Real-Time Gross Settlement，实时全额结算）：逐笔发送、逐笔结算，不做净额轧差。典型：中国 HVPS、美国 Fedwire、欧洲 TARGET2、日本 BOJ-NET。特点是 终局性强（settlement finality），一笔即结，但对参与者流动性要求高。
• DNS（Deferred Net Settlement，延迟净额结算）：白天先撮合轧差，日终或窗口时刻把净头寸送到 RTGS 结算。典型：中国 BEPS（小额批量）、美国 CHIPS、SEPA SCT。省流动性，但有系统性风险——未结算前任一参与者违约，净额需要重算（unwind）。
• FPS / IP（Fast Payment System，快速支付 / Instant Payment）：面向零售的 24×7 实时到账，多数情况下结算落在央行日间账户。典型：中国网联（IBPS）、美国 FedNow、英国 FPS、欧元区 TIPS、印度 UPI、巴西 PIX。技术上是 RTGS 或 “预存准备金 + 净额结算” 的混合。

1.2 大额 vs 小额的分水岭

几乎所有国家的央行支付系统都刻意做了 大额 / 小额 两条线：

小额 24×7 化是过去十年最大的变化——网联、FedNow、TIPS、UPI、PIX 本质上都在把 RTGS 的 “实时终局” 延展到 C 端零售。

1.3 结算终局性（Settlement Finality）

这是央行系统的核心卖点。当一笔结算在央行账户上完成借贷记，就不可逆转——即使发起方之后破产、被撤销授权、被司法冻结，结算本身不回滚。这是各国央行法赋予的强制力（如中国《支付结算办法》、欧盟 Settlement Finality Directive 98/26/EC、美国 Regulation J）。对工程师的意义是：央行回执是业务层 “到账” 状态机的终点，后续的任何差错处理只能通过新开一笔反向交易。

1.4 参与者、账户、报文三元组

理解任何一个央行系统，只需要抓三件事：

• 参与者（Participant）：谁可以发起报文、谁持有央行账户；
• 账户（Account）：准备金账户、结算账户、流动性账户，是否生息，是否可透支；
• 报文（Message）：报文集、字段字典、时间戳语义、签名要求。

下面讲每个系统都会围绕这三元组展开。一个 “接入央行系统” 的项目 60% 工作量花在报文，20% 花在账户对账，10% 花在合规与审计，10% 花在运营窗口适配——这是一个经验性的经验分布。

1.5 一个反复会出现的模式：双层账户

几乎所有央行零售实时支付系统（FedNow、TIPS、网联）都采用 “母账户 + 子账户” 的双层模型：

• 母账户（Master Account）：参与者在央行的传统清算账户；
• 子账户（Subaccount / Liquidity Account）：专供该零售支付系统使用；
• 日间从母账户划拨到子账户，日终结余回划。

这样做的原因是：24×7 实时结算不能在母账户上做（母账户仍按工作日运行），只能在 “实时结算专用账户” 上做；同时又要让这部分资金与母账户的流动性管理联动。工程上这种双层模型需要额外维护账户余额镜像、双向同步、流动性预警告。

二、中国：CNAPS、网联、银联、CIPS

中国人民银行主导的清算基础设施，可以看成四层叠加：

flowchart TB
    subgraph PBOC["中国人民银行 清算总中心 PCCC"]
        HVPS["HVPS<br/>大额实时<br/>RTGS"]
        BEPS["BEPS<br/>小额批量<br/>DNS"]
        IBPS["IBPS<br/>网上支付跨行清算<br/>(超级网银)"]
        ACH["ACS<br/>支票影像<br/>ECDS"]
    end
    subgraph NUCC["网联清算 NetsUnion"]
        NL["IBPS 网联平台<br/>扫码 / APP 支付"]
    end
    subgraph UP["银联 UnionPay / CUP"]
        UPC["银行卡跨行<br/>(BIN 62)"]
    end
    CIPS["CIPS<br/>人民币跨境"]

    Banks[("商业银行")] -- "RTGS 直连" --> HVPS
    Banks -- "批量文件" --> BEPS
    Banks -- "实时小额" --> IBPS
    Banks -- "Pay 厂商" --> NL
    NL -- "资金清算" --> HVPS
    UPC -- "资金清算" --> HVPS
    CIPS -- "本币最终结算" --> HVPS

上图可以这样读：最底层的终局结算永远发生在 HVPS——它是人民币境内的 “最后一站”。网联、银联、CIPS 都是上层的 “专线清算组织”，它们把自己成员之间的债权债务算清楚，再在 HVPS 上做资金头寸的划转。

2.1 CNAPS：大额 HVPS + 小额 BEPS

CNAPS（Chinese National Advanced Payment System，中国现代化支付系统） 是人民银行自建的一、二代系统统称。一代 CNAPS-1 于 2002 年、2005 年相继投产 HVPS 和 BEPS；二代 CNAPS-2 于 2013 年上线，在一代基础上引入了更强的报文、业务处理与直接参与者灵活接入。

• HVPS（High Value Payment System，大额实时支付系统）：RTGS 模式，逐笔发送、逐笔结算。业务单笔不设上限（>5 万元通常走 HVPS，<5 万也可以走），运行时间 2008 年起延伸至每工作日 8:30–17:15，后又扩展延长。结算落在参与者（商业银行法人）在人民银行的清算账户。
• BEPS（Bulk Electronic Payment System，小额批量支付系统）：DNS + 7×24 小时运行（2006 年起）。单笔金额 ≤ 5 万元（实名支付限额可调整）。白天累积，日间若干结算窗口把净额发到 HVPS。

直接参与者主要是全国性商业银行的总行法人、政策性银行、部分外资银行分行；城商行、农信社、村镇银行通过 间接参与者 方式通过直接参与者代理接入 CNAPS。这意味着一家小银行若要自己发起 HVPS 报文，路径是 “小银行 → 代理总行 → HVPS”。

2.1.1 CNAPS 报文与 SAPS

CNAPS 的报文格式最初基于 MT 格式 改造（如 CBS103 对应 MT103 客户汇款、CBS202 对应 MT202 机构汇款），后逐步向 ISO 20022 靠拢。人民银行清算总中心（PCCC）还运营 同城票据交换系统 与 支票影像系统（ECDS，Electronic Commercial Draft System 之前的前身），形成了中国特有的 电子商业汇票（ECDS / 承兑汇票） 清算生态。

一笔典型的 HVPS 报文包含：发起行、代理行链、收款行、金额、币种（只有人民币）、汇款用途（结构化 + 自由文本）、交易时间戳、业务种类码。报文经过 PCCC 校验后由 PCCC 发送给收款行、并在人民银行账户上同步借贷记。

2.1.2 停运与灾备

HVPS 的停机窗口主要在夜间维护（具体窗口随监管公告），工作日早盘 8:30 前需完成启动。对接入方而言，必须维护 两地三中心（北京、上海、异地），任一中心故障不影响对接。实际上 2020 年人民银行完成了清算中心南北双活，参与者同步需要支持双活切换与同城异步复制。

2.2 IBPS：网上支付跨行清算系统（俗称 “超级网银”）

IBPS（Internet Banking Payment System）是 CNAPS 家族中面向互联网银行的跨行实时清算，2010 年上线，俗称 超级网银。它支持 7×24 实时到账，单笔上限起初是 5 万、后放开。IBPS 在 2017 年后被 “扩展” 为网联的承接底座——实质上网联的清算底是架在 IBPS 之上的。

2.3 网联：2017 年 “断直连” 的技术落地

在 2017 年之前，第三方支付机构（支付宝、财付通等）直接与数百家银行一对一对接，每家银行开一个备付金账户，清算在支付机构的账本内部完成。这带来了两个问题：

1. 资金池不透明：监管不知道备付金的实际流向；
2. 系统性风险：支付机构成为事实上的 “影子清算组织”。

人民银行 2017 年 8 月推出 网联清算有限公司（NUCC，NetsUnion Clearing Corporation），强制要求所有非银支付机构的网络支付业务（扫码、APP 内、H5 等）从 2018 年 6 月 30 日起 “断直连”，通过网联统一清算。

实际数据流（以扫码付为例）：

sequenceDiagram
    autonumber
    participant User as 用户
    participant Mer as 商户 APP
    participant PayApp as 支付宝 / 微信支付
    participant NL as 网联 / 银联（路由）
    participant IssB as 发卡行 A
    participant AcqB as 收单行 B
    participant HVPS as HVPS
    User->>Mer: 扫码金额 100 元
    Mer->>PayApp: 支付请求
    PayApp->>IssB: 冻结 / 扣款 (经网联转发)
    PayApp->>NL: 清算报文
    NL->>IssB: 借记指令
    NL->>AcqB: 贷记指令（T+1 或实时）
    NL-->>HVPS: 日终净额结算
    HVPS-->>IssB: 备付金扣减
    HVPS-->>AcqB: 备付金增加
    PayApp-->>User: 支付成功

自网联运行以来，日均处理笔数在 2024 年已稳定超过 20 亿笔、峰值日（“双 11”）接近百亿笔——是世界上日吞吐最大的零售清算系统之一。

网联的几个工程细节：

1. 报文异构适配：网联需要同时对接各家银行（核心系统千差万别）和各家支付机构，报文采用 ISO 8583 和 ISO 20022 两套并存，由网联侧做报文转换；
2. 备付金集中存管：2019 年起非银支付机构的客户备付金 100% 集中存管于人民银行的专户，网联代理清算结果直接贷记/借记该集中存管账户；
3. 两地三中心：网联采用 “上海 + 深圳” 两地三中心架构，RTO < 30 秒，RPO = 0；
4. 双四活架构：应用侧单元化分区部署，每个区独立处理一部分支付机构 + 一部分银行，支持秒级故障切换。

2.3.1 网联对支付机构的对账差异

对支付机构（比如一家 PSP）来说，接入网联后的对账流程与 2017 前有两个明显区别：

• 与银行直接对账已不存在——所有资金都经过网联，支付机构拿的是网联的清算对账文件；
• T+1 结算净头寸——即便用户侧是实时的，机构侧仍要等网联 T+1 清结算清单再与自己账本核对。

工程上这意味着支付机构的 “对账系统” 从 “N 家银行 × N 份文件” 简化为 “网联 + 银联 × 2 份文件”，但解析标准更严格。

2.4 银联：卡组织 + 跨境受理

银联（UnionPay / CUP，中国银联股份有限公司） 是 2002 年成立的国内银行卡组织，BIN 以 62 开头。它承担两块业务：

1. 境内银行卡跨行交换：ATM、POS、线上卡支付的报文交换与清算；跑的是 ISO 8583 的国标改造版；资金最终在 HVPS 结算；
2. 国际受理网络（UPI，UnionPay International）：全球 180+ 国家和地区的 ATM / POS 受理、境外发卡合作。这部分和 Visa、Mastercard 争夺市场，在东南亚、俄罗斯、中亚占有率较高。

银联 vs 网联的一句话分工：“卡走银联，码走网联”。刷卡（含云闪付扫静态码走卡 Token 的情形）走银联的交换与清算，二维码 / APP 内的扫码支付走网联。两者不重合，但都在人民银行监管下、最终结算落在 HVPS。

2.5 CIPS：人民币跨境支付系统

CIPS（Cross-border Interbank Payment System，人民币跨境支付系统） 由人民银行发起、2015 年上线一期、2018 年上线二期，运营主体是 跨境银行间支付清算（上海）有限责任公司。

• 一期（2015）：RTGS 模式、白天运行、结算落在 HVPS；定位是 “为境外人民币业务提供高效通道”。
• 二期（2018）：扩展为 5×24 小时（周一 08:00 到周日 20:00，覆盖亚欧美三时区的工作日重叠）；引入 DVP 机制支持证券、引入额外的批量报文；开始使用 ISO 20022 报文（pacs.008、pacs.009、camt.054 等），是人民银行最早全面原生 ISO 20022 的系统之一。

参与者结构：

• 直接参与者（Direct Participant）：在 CIPS 开立账户，报文直连。截至 2024 年底，约 160+ 家，含境内大型商业银行、外资在华分行、部分境外清算行（如中银香港、工银新加坡）；
• 间接参与者（Indirect Participant）：通过直接参与者转接，截至 2024 年底约 1400+ 家，覆盖 110+ 个国家和地区。

CIPS 与 SWIFT 的关系（最常见误解）：

2024 年数据：CIPS 全年处理业务约 820 万笔、175 万亿元人民币（CIPS 官方年报），同比增长约 43%，其中 RCEP 区域占比快速提升。俄乌冲突后部分俄罗斯银行被 SWIFT 制裁，俄方银行使用 CIPS 的报道增多，但 CIPS 官方口径一直强调其是 人民币结算系统、非替代 SWIFT 的政治工具。

2.5.1 CIPS 的两类接入模式

直接参与者可以选择两种连接方式：

• 标准方式：通过 CIPS 专线（SFNET）直连 CIPS 清算中心，报文走 CIPS 自研消息格式（基于 ISO 20022）；
• SWIFT 通道方式：通过 SWIFTNet 承载 CIPS 报文（SWIFT 为 CIPS 专门分配了 FINplus 服务），这对已经接入 SWIFT 的境外银行更友好——它们不需要新拉专线、也不需要改造报文；

间接参与者则通过直接参与者的代理服务接入。工程上，选哪种方式主要看：是否境外、是否已有 SWIFT 基础设施、业务量是否够大以摊销专线成本。

2.5.2 CIPS 与 HVPS 的流动性联动

CIPS 直接参与者在 CIPS 开立的资金账户不是 “独立账户”，而是 HVPS 账户的一个子账户。日间 CIPS 处理的报文最终在 HVPS 上做头寸划转：

flowchart LR
    DP1["境内直参<br/>(工行总行)"] --"pacs.008"--> CIPS
    DP2["境外直参<br/>(工银新加坡)"] --"pacs.008"--> CIPS
    CIPS --"头寸通知<br/>MT202 / pacs.009"--> HVPS
    HVPS --"借贷记<br/>央行准备金账户"--> Reserve[("人民银行准备金账户")]

如果一家直参境外行流动性不足，它需要通过本行的境内总行（或一家代理直参）向 CIPS 账户注资——这与欧元区 T2 CLM 的 “流动性池” 逻辑相似。

三、美国：Fedwire、FedNow、CHIPS

美国支付系统的一个特点是 公私并存：美联储运营 Fedwire 和 FedNow，清算所银行同业（TCH，The Clearing House）运营 CHIPS 和 RTP。

3.1 Fedwire Funds Service：大额 RTGS 鼻祖

Fedwire 是美联储运营的 RTGS 系统，前身是 1918 年的 莫尔斯码电报转账网络（用于一战期间财政部跨行转账），1970 年代电子化。今天它由两部分构成：

• Fedwire Funds Service：美元大额实时结算。日均处理约 80 万笔、4 万亿美元（2024 年，Fed H.4.1 报表）。单笔平均约 500 万美元。
• Fedwire Securities Service：美国国债、机构债、MBS 的簿记式托管与结算；DVP（Delivery versus Payment）模式，和 Funds 打通。

Fedwire 的参与者是 存款机构（Depository Institution），必须在美联储开立准备金账户。截至 2024 年约有 9800+ 家参与者。

1985 年 BNY 事故：1985 年 11 月 21 日，纽约梅隆银行（Bank of New York）用于处理 Fedwire 收付的软件出现文件指针故障，导致其在无法入账美国国债 Fedwire Securities 交易的情况下继续向交易对手支付资金，当日透支美联储贴现窗口高达 237 亿美元，需要以所有美国国债为抵押、按当晚联邦基金利率计息借入。这是支付系统工程史上最著名的单点故障之一，催生了后来对参与者透支上限（Net Debit Cap）、流动性保障与软件变更审计的严监管。

3.2 FedNow：2023 上线的小额实时

FedNow 于 2023 年 7 月 20 日正式启动，是美联储运营的 7×24 小时、365 天的即时支付系统。

• 单笔上限：默认 10 万美元，参与行可自设到 50 万美元；
• 结算模式：每笔在美联储主账户（Master Account）的影子子账户上即时轧差、终局结算；
• 报文：ISO 20022 原生（pacs.008 / pacs.002）；
• 参与者：2024 年底已超过 1000 家 存款机构加入。

FedNow 与私营的 TCH RTP（The Clearing House Real-Time Payments，2017 上线）形成竞合关系。RTP 由大行共同出资，覆盖面商业化扩展快但对小银行的接入成本高；FedNow 依赖美联储的既有接入通道（FedLine），小银行可以复用现有连接，因此 FedNow 的市场策略是 “长尾银行优先”。

3.3 CHIPS：私营的大额净额系统

CHIPS（Clearing House Interbank Payments System）1970 上线，是美国大额支付的另一条腿——纯私营、DNS 模式。它只有约 40+ 家 直接参与者（基本是大型国际银行），但承担了全球美元跨境清算的主要份额：日均约 1.8 万亿美元、50 万笔（TCH 2024 年报）。CHIPS 的一大特色是 “算法多边净额”（bilateral/multilateral netting algorithms），在一天中不断尝试用最少流动性完成最多结算。最终残余净额日终在 Fedwire 上结算。

工程含义：跨境一笔美元从东京到芝加哥，最常见路径是 SWIFT MT103 → 东京代理行 → CHIPS → 芝加哥代理行 → Fedwire（最终结算）。CHIPS 是代理行网络的 “大动脉”。

3.4 Fedwire 的 “Daylight Overdraft”（日间透支）

Fedwire 有一个与中国 HVPS 显著不同的设计：允许参与者日间透支准备金账户。美联储按透支金额、按秒计费（Daylight Overdraft Fee），年化约 50 bps 左右（具体费率定期调整）。这对工程的含义：

• 商业银行可以在资金未到账前就发出下一笔，提升流动性效率；
• 但透支有上限（Net Debit Cap），由美联储根据该行的资本与风险评级设定；
• 上限触达后，后续报文会被 FIFO 排队，日终再处理。

1985 年的 BNY 事故就是透支上限机制的 “反向案例”——当时的 Fedwire Securities 还没有对证券交易实施严格的透支限制，导致一夜透支 237 亿美元。事故后美联储引入了对证券交易的 Net Debit Cap、以及 抵押品要求（collateralized daylight overdraft）。

3.5 一次 Fedwire 大额电汇的账务

以一笔 5 亿美元并购款为例，关键时序：

sequenceDiagram
    autonumber
    participant Buyer as 买方
    participant BuyerB as 买方银行 A
    participant Fed as 美联储 Fedwire
    participant SellerB as 卖方银行 B
    participant Seller as 卖方
    Buyer->>BuyerB: 电汇指令 USD 500M
    BuyerB->>Fed: pacs.009 / MT202
    Fed->>Fed: 借 A 准备金 / 贷 B 准备金<br/>(结算终局生效)
    Fed-->>BuyerB: ACK + 结算确认
    Fed-->>SellerB: Credit 通知
    SellerB->>Seller: 入账到商业账户
    Note over Fed: 全流程通常 < 30 秒，<br/>单笔无金额上限

注意 Fedwire 一旦 ACK，不可撤销——即使买方发现转错账户，也只能让卖方银行配合 “原路退汇”，而这需要卖方同意。这是工程层面的 “不可逆” 设计。

四、欧元区：TARGET2、T2、T2S、SEPA、TIPS

欧元区的支付基础设施由 欧洲央行（ECB）+ 国家央行体系（Eurosystem） 共同运营。2022–2023 年完成了一次大整合。

4.1 TARGET2 → T2：2023 年的大改造

TARGET2（Trans-European Automated Real-time Gross settlement Express Transfer system）2007 年上线，取代一代 TARGET，是欧元大额 RTGS。

2023 年 3 月 20 日，Eurosystem 完成 “T2 Consolidation”（T2 合并迁移），把 TARGET2 和证券结算的 TARGET2-Securities（T2S） 统一到同一技术平台 T2，并引入 CLM（Central Liquidity Management） 和 RTGS 服务两个分层：

• CLM：商业银行在各国央行的准备金账户、流动性分配、准备金、贴现操作；
• RTGS：具体支付报文的处理。

同时，这次改造 把所有内部报文迁移到 ISO 20022（原本用 SWIFT FIN MT），并采用 SWIFT 的 MX 报文（pacs / camt / admi）。对工程师来说，最大的变化是：T2 参与者必须在 2023-03 前完成报文改造，这是欧元区最大规模的一次 ISO 20022 原生切换。

T2 日均约 40 万笔、2.2 万亿欧元（ECB 2024 年度统计）。

4.2 T2S：证券 DVP 结算平台

T2S（TARGET2-Securities） 2015–2017 分批上线，是一个 泛欧证券结算 CSD 整合平台。它不是 CSD 本身（CSD 仍是各国的如德国 Clearstream、法国 Euroclear France），而是把各国 CSD 的 “证券账户” 和央行的 “现金账户” 接入同一结算引擎，实现真正的 DVP（Delivery versus Payment）。

参与 T2S 的 CSD 约 20+ 家，覆盖多数欧元区市场。对撮合-结算链路的意义是：一笔跨境证券交易的 DVP 可以在 T2S 上一步完成，不需要像过去那样跨多个 CSD 做代理行对接。

4.3 SEPA：SCT、SDD、SCT Inst

SEPA（Single Euro Payments Area，单一欧元支付区） 是另一个层面的制度安排——让欧元区内部的跨国欧元支付 “像国内支付一样便宜快捷”。SEPA 本身不是一个系统，而是一套 规则 + 报文标准 + 参与者框架，由欧洲支付理事会（EPC）制定。具体清算可以跑在多个清算基础设施（CSM）上，如 EBA Clearing 的 STEP2、各国本地 ACH 等。

SEPA 三大支付工具：

• SCT（SEPA Credit Transfer）：跨行贷记转账，T+1 到账，ISO 20022 pain.001 / pacs.008；
• SDD（SEPA Direct Debit）：直接借记，分 Core（零售）和 B2B 两类；需要 Mandate 授权；
• SCT Inst（SEPA Instant Credit Transfer）：2017 上线的实时版本，10 秒到账、365×24 运行、单笔上限 2024 起从 10 万提至 不设上限（Instant Payments Regulation 要求，2024-08 生效）。

4.4 TIPS：欧元区 “FedNow”

TIPS（TARGET Instant Payment Settlement） 由 ECB 运营、2018 年上线，是 SCT Inst 的央行清算底。参与行在 TIPS 预留流动性账户（由 T2 CLM 划拨），逐笔实时结算。TIPS 同时支持瑞典克朗（SEK）、丹麦克朗（DKK）接入——这是欧洲把支付基础设施 “外币化” 的一次尝试。

Instant Payments Regulation（IPR，2024-03 通过） 强制要求所有欧元区银行在 2025 年 1 月前 能接收 SCT Inst、2025 年 10 月前 能发送。这将把 SCT Inst 从 “可选” 变成 “默认”——零售跨境 24×7 实时成为标配。

4.5 T2 整合后的账户层次

T2 整合以后，一家欧元区商业银行在 Eurosystem 的账户体系大致如下：

flowchart TB
    MCA["MCA<br/>Main Cash Account<br/>(准备金、央行操作)"]
    DCA_RTGS["DCA (RTGS)<br/>Dedicated Cash Account<br/>支付用"]
    DCA_T2S["DCA (T2S)<br/>证券结算用"]
    DCA_TIPS["DCA (TIPS)<br/>即时支付用"]
    MCA <--"Liquidity Transfer"--> DCA_RTGS
    MCA <--"Liquidity Transfer"--> DCA_T2S
    MCA <--"Liquidity Transfer"--> DCA_TIPS

一家银行可以根据业务动态从 MCA 划拨流动性到不同 DCA。CLM（Central Liquidity Management）服务就是负责这些划拨的管理层。工程上这意味着：

• 流动性监控需要聚合四个账户的余额；
• 跨账户划拨本身也是报文（camt.050），要监控耗时与失败；
• 晨起预划拨、日终回收 是一个固定仪式，需要自动化脚本 + 人工复核。

4.6 EBA Clearing 的 STEP2 与 RT1

除了 ECB 自己运营的 T2 / TIPS，欧元区还有一家私营清算组织 EBA Clearing（European Banking Authority Clearing，私营，不是监管机构）。它运营：

• STEP2：SEPA SCT / SDD 的主要 CSM，日均数千万笔；
• RT1：SEPA SCT Inst 的私营清算底，与 TIPS 互操作；
• EURO1：大额净额系统（历史上 MT / 现已 ISO 20022）。

一家欧洲的银行通常会同时接 STEP2（批量）和 TIPS（实时），报文均为 ISO 20022。

五、SWIFT：不是清算系统，是报文网络

5.1 SWIFT 做什么

SWIFT（Society for Worldwide Interbank Financial Telecommunication） 成立于 1973 年，总部设在比利时 La Hulpe，是一家合作社性质的报文网络提供商，不承担结算、不持有资金、不是银行。它提供的是：

• SWIFTNet：专网，保证可达、可审计、高可用；
• 报文格式：MT（传统文本，ISO 15022）、MX（XML，ISO 20022）；
• 附加服务：gpi（全球支付创新）、KYC Registry、合规工具、Sanctions Screening 等。

一次典型跨境汇款（MT103），SWIFT 的角色是把这条结构化报文从 A 行送到 B 行。真正的清算落在 CIPS、Fedwire、CHIPS、TARGET2 等 底层清算系统。SWIFT 是 “信封”，清算系统才是 “邮递员的腿”。

5.2 MT → MX 迁移（ISO 20022）

2025 年 11 月 22 日 是 SWIFT 社区计划的 MT/MX 共存期（Coexistence Period）结束日。之后，跨境支付类 MT 报文（MT1xx、MT2xx、MT9xx 等）将被 下线，全面迁移到 MX（ISO 20022）：

• MT103 → pacs.008（客户贷记转账）
• MT202 → pacs.009（金融机构贷记转账）
• MT202COV → pacs.009 COV
• MT900/910 → camt.054（借/贷记通知）
• MT940/950 → camt.053（账户对账单）

MX 带来的工程好处：

1. 结构化 - 收款人、中间行、费用、合规字段从自由文本变为明确字段，合规筛查准确率提升；
2. 字段更长 - 地址、原因、汇款用途可承载远超 MT 的 4×35 字符限制；
3. 长链条可追踪 - UETR（Unique End-to-End Transaction Reference）贯穿全链路；
4. 兼容本币 RTGS - T2、CIPS、FedNow、TARGET2-Securities 全部原生 ISO 20022，MX 可以 “一个格式用到底”。

5.3 SWIFT gpi：透明化跨境汇款

SWIFT gpi（global payments innovation） 2017 年推出，解决传统 MT103 “汇出后失联” 的老问题。核心机制：

• UETR：36 字符 UUID，在 MT103 的 Block 3 {121:} 字段声明，全链路保持；
• Tracker：中间行每次处理都回传 gpi Tracker 一条 confirm 报文，汇款人实时查询；
• SLA：加入 gpi 的银行承诺 50% 的跨境支付在 30 分钟内到账、几乎 100% 在 24 小时内到账；
• gCCT、gCOV、gFIT 等分类。

gpi 的效果（SWIFT 2024 年数据）：约 90% 的跨境支付在一小时内入账至收款行，其中过半数在 5 分钟内。对比 2016 年前 “三五个工作日到账” 的常态，这是代理行模式数字化的最大一次提速。

5.4 真实事件：SWIFT 对俄制裁

2022 年 3 月起，欧盟决议要求 SWIFT 断开俄罗斯七家银行（Sberbank、VTB 等）的 SWIFTNet 接入；后续又追加。被断开意味着这些银行无法通过 SWIFT 发/收报文——但 不代表不能做跨境支付，它们仍可以通过代理行、CIPS、俄罗斯本土的 SPFS 或 Telex、邮政等方式继续业务，只是成本和速度显著恶化。这个事件反过来让全球主要经济体重新审视 “支付基础设施的主权”——CIPS、SPFS、印度 SFMS、BRICS Pay 的讨论都由此升温。

5.5 SWIFT 安全事件：2016 孟加拉央行盗案

2016 年 2 月 5 日，孟加拉国央行储备在纽联储的账户被通过 SWIFT 发送的 35 笔伪造 MT103 报文骗取了约 1.01 亿美元（其中 8100 万美元最终未被追回）。攻击者在孟加拉央行的 SWIFT 终端植入恶意软件，篡改了本地的 SWIFT Alliance Access 日志与打印机输出以掩盖痕迹。

这个事件对全球 SWIFT 用户的直接影响是：

1. Customer Security Programme（CSP）：SWIFT 随即推出强制性的 24 项安全控制（Customer Security Controls Framework，CSCF），所有 SWIFT 用户必须年度自证 / 独立审计；
2. Relationship Management Application（RMA）：对手行必须双向授权才能收发报文，关闭不必要的通道；
3. Daily Validation Reports：央行级别用户收到额外的逐日对账报告；
4. 签名与 HSM：本地终端对所有外发报文必须 HSM 签名，日志不可本地删除。

对工程师的实操影响：接入 SWIFT 的内网终端一定要做 网络分区 + 终端审计 + HSM 签名 + 双人复核，这已成行业最低线。

六、印度 UPI 与巴西 PIX：公共基础设施的逆袭

如果说网联、FedNow、TIPS 是 “现有央行系统 + 零售化”，那么 UPI 和 PIX 则是 “直接从零售起步、顺手把卡组织和钱包也替代了” 的另一条路径。

6.1 印度 UPI

UPI（Unified Payments Interface） 由 NPCI（National Payments Corporation of India，印度储备银行和银行业联合成立的非营利机构）2016 年上线。关键设计：

• 虚拟支付地址（VPA，如 user@bank）：支付身份与账号解耦；
• P2P / P2M 合一：同一套 API，个人转账和商户收款走一条路；
• 零 MDR：对 P2M 小额商户不收 MDR（Merchant Discount Rate），由政府财政补贴给 PSP；
• 开放给所有 PSP：Google Pay、PhonePe、Paytm 都是 UPI 的上层应用，底层统一。

截至 2024 年 12 月，UPI 日均处理 5 亿+ 笔，年处理约 1700 亿笔，已超过全球 Visa + Mastercard 的合计笔数——是全球最大的零售即时支付网络。清算底由 NPCI 的 NFS、IMPS 系统承接，最终落在 RBI（印度央行）的 RTGS 账户。

6.2 巴西 PIX

PIX 由巴西中央银行（BCB）2020 年 11 月上线，是央行亲自运营的 24×7 即时支付系统。一些关键设计：

• Pix Key：手机号、邮箱、CPF（身份证号）、随机字符串都可作为收款别名；
• 强制参与：300 万以上活跃客户的银行、支付机构 必须加入；
• 免费 C2C：P2P 对个人完全免费；P2B 费率极低；
• QR Code 标准：Brcode 开放标准；
• 中央对账单：BCB 集中管理别名目录（DICT）。

上线四年，PIX 已覆盖巴西 90%+ 成年人口，日均 2 亿+ 笔，彻底颠覆了 Visa/Mastercard 在巴西的小额支付地位，也让巴西的 “无现金化” 速度超越北美。

6.3 共性：央行作为平台提供者

UPI 和 PIX 给工程师的启发不是技术——技术其实并不新鲜（报文、清算、别名目录都是成熟技术）——而是 制度设计：

1. 央行 / 监管出面 解决多方博弈（银行不愿互通）；
2. API 开放 + 标准统一 让市场主体在标准之上创新；
3. 零或极低费率 撬动规模，再用规模压死传统卡组织的刷卡费模型。

对比之下，网联更像 “公私合营 + 行政推动”，而 FedNow 则是 “央行做基础设施、商业市场自发扩展” 的中间形态。

6.4 其他国家的 FPS 速览

这些系统的共同特征：都采用 ISO 20022 或其本地化版本，都有 别名 / 电话号码支付，都强调 7×24。差异在于是否央行直接运营、是否强制参与、费率模型如何。

七、完整案例：一笔 “中国出口商收欧元” 的路径

我们把本篇涉及的系统串起来。场景：德国一家汽车零部件进口商向中国出口商支付 100 万欧元 货款。

sequenceDiagram
    autonumber
    participant Imp as 德国进口商
    participant ImpB as 进口商开户行<br/>(德商行, Frankfurt)
    participant T2 as T2 (RTGS)
    participant Corr as 中间代理行<br/>(Deutsche Bank 亚洲区)
    participant CBoC_HK as 中国银行 香港<br/>(欧元清算行)
    participant SWIFT as SWIFT (报文)
    participant CIPS as CIPS (若需人币)
    participant ExpB as 中国出口商开户行<br/>(工行上海)
    participant Exp as 中国出口商

    Imp->>ImpB: 汇款指令 EUR 1,000,000
    ImpB->>SWIFT: pacs.008 (UETR 声明)
    SWIFT-->>Corr: 报文到达
    ImpB->>T2: 资金划转至 Deutsche Bank<br/>账户 (欧元终局结算)
    Corr->>SWIFT: pacs.008 转发
    SWIFT-->>CBoC_HK: 报文到达
    Corr->>CBoC_HK: 欧元 via 代理 (CBoC HK 在 DB 的 nostro 账户)
    CBoC_HK->>SWIFT: pacs.008 送工行
    SWIFT-->>ExpB: 到达工行上海
    Note over CBoC_HK,ExpB: 若收款人要求兑换人民币，<br/>CBoC HK 做 FX，再通过 CIPS 发 pacs.008 RMB
    CBoC_HK->>CIPS: pacs.008 RMB
    CIPS->>ExpB: 清算 + HVPS 结算
    ExpB->>Exp: 入账 (RMB or EUR)
    Note over SWIFT: gpi Tracker 全程跟踪 UETR

几个关键观察：

1. T2 承担的是 “欧元终局”：只要资金从 Commerzbank 到 Deutsche Bank 这一步在 T2 完成，欧元的结算终局就落下了；后面的代理行转账是 nostro/vostro 账户的余额调整，不再是央行账面上的真实欧元流动（下一篇《跨境支付工程》会细讲）；
2. CIPS 承担 “人民币终局”：如果收款人要求人民币，则需要一次 FX 和一笔 CIPS 清算，终局在 HVPS；
3. SWIFT 从头到尾只是信封；
4. UETR 使得出口商在 30 分钟后打电话问 “钱到了吗” 时，出口商开户行能回答出具体节点。

八、工程者视角：如何接入这些系统

8.1 接入身份

不管哪一家央行系统，对商业机构的身份大致分三档：

工程师要先搞清楚自家业务在对方系统里处在哪一档，这决定了你要对接的是 央行的接入网关 还是 代理行的 API。

8.2 接入一家直接参与者的典型工作

以接入 CIPS 直接参与者为例，简化清单：

1. 业务资格：境内持牌银行；按 CIPS 要求完成尽调、签订参与协议；
2. 专线：两条物理冗余专线接入 CIPS 运营场地（上海）；自建 DR 灾备站点；
3. 报文实现：pacs.008（客户贷记）、pacs.009（机构贷记）、pacs.004（退汇）、camt.054（通知）、camt.029（调查回复）等；
4. 证书 / 签名：CIPS 专用 PKI 证书、HSM 存储、报文签名；
5. 对账：日终 camt.053 与本系统账务核对；
6. 灾备演练：双活或切换演练，RTO / RPO 达标；
7. 合规：反洗钱、制裁名单筛查、可疑交易上报。

接入 T2、Fedwire、FedNow 的流程大同小异，差别在报文字典、运行时窗口、流动性管理工具（CLM、Fedwire throughput cap）。

8.3 接入一家间接参与者的路径

如果只是接入小额、局部业务，更常见的是找一家代理行（往往是自家业务上的开户总行），让它帮你：

• 代理发报文：你通过私有 API 把支付请求给到代理行，它转换为 CIPS/SWIFT/Fedwire 报文；
• 代理结算：你在代理行开清算账户，资金在代理行账面轧差；
• 代理对账：代理行提供 camt.053 或私有格式的对账单。

这是绝大多数中小银行、跨境支付 PSP（如 Wise、Airwallex）的真实姿态。

8.4 报文协议：ISO 20022 为什么赢

截至 2026 年，全球主流央行清算系统已经全面以 ISO 20022 为主：

ISO 20022 在工程上的好处（对比 ISO 15022 / MT）：

• XML / JSON 双表达：报文可被主流 XML 工具链直接处理；
• 业务域明确：pacs（payment clearing & settlement）、pain（payment initiation）、camt（cash management）、admi（administration）分区清晰；
• 扩展性：可加本地扩展字段但不破坏核心字典；
• 与 HSM、数字证书体系的自然结合；
• 数据字段富化：便于 AI 合规筛查、反欺诈特征工程。

一个 pacs.008（客户贷记）核心片段（简化）：

<FIToFICstmrCdtTrf>
  <GrpHdr>
    <MsgId>MSGID20260422-0001</MsgId>
    <CreDtTm>2026-04-22T10:15:30+08:00</CreDtTm>
    <NbOfTxs>1</NbOfTxs>
    <SttlmInf><SttlmMtd>CLRG</SttlmMtd>
      <ClrSys><Cd>CIPS</Cd></ClrSys></SttlmInf>
  </GrpHdr>
  <CdtTrfTxInf>
    <PmtId>
      <EndToEndId>E2E-2026042200001</EndToEndId>
      <TxId>TXN-2026042200001</TxId>
      <UETR>a3f1c2b4-5e6d-47a8-9b1c-1234567890ab</UETR>
    </PmtId>
    <IntrBkSttlmAmt Ccy="CNY">1000000.00</IntrBkSttlmAmt>
    <ChrgBr>SHAR</ChrgBr>
    <Dbtr><Nm>Commerzbank AG</Nm></Dbtr>
    <DbtrAgt><FinInstnId><BICFI>COBADEFFXXX</BICFI></FinInstnId></DbtrAgt>
    <CdtrAgt><FinInstnId><BICFI>ICBKCNBJXXX</BICFI></FinInstnId></CdtrAgt>
    <Cdtr><Nm>Shanghai Exporter Co., Ltd.</Nm></Cdtr>
    <CdtrAcct><Id><Othr><Id>6222020200112345678</Id></Othr></Id></CdtrAcct>
    <RmtInf><Ustrd>INV2026-001 Auto parts</Ustrd></RmtInf>
  </CdtTrfTxInf>
</FIToFICstmrCdtTrf>

这条报文对 CIPS 的直接参与者是 “原生可理解” 的，CIPS 侧的校验器会检查 UETR 合规、BICFI 存在、金额十进制位、字符集等。

8.5 关键 SQL：支付网关侧的 “清算路由” 决策表

支付网关在接收到一笔跨境或跨行支付请求时，通常需要根据币种、金额、对端 BIC、时间窗口来决策走哪条清算通道。一个简化的路由决策表：

CREATE TABLE clearing_route (
  route_id        BIGINT PRIMARY KEY,
  currency        CHAR(3)      NOT NULL,     -- CNY, USD, EUR ...
  amount_min      DECIMAL(20,4) NOT NULL DEFAULT 0,
  amount_max      DECIMAL(20,4) NOT NULL,    -- 本通道允许的上限
  cross_border    BOOLEAN       NOT NULL,    -- 是否跨境
  counter_bic     VARCHAR(11),               -- 对端 BIC，可模糊
  channel         VARCHAR(16)  NOT NULL,     -- HVPS / BEPS / IBPS / CIPS / FEDWIRE / T2 / SWIFT
  priority        INT          NOT NULL,     -- 同条件下的优先级
  cutoff_time     TIME,                      -- 截止发起时间
  service_window  VARCHAR(64),               -- "MON-FRI 08:30-17:15" 等
  active          BOOLEAN       NOT NULL DEFAULT TRUE
);

-- 示例：
INSERT INTO clearing_route VALUES
  (1, 'CNY', 50000.01,   999999999, FALSE, NULL,         'HVPS',    10, '17:00', 'MON-FRI 08:30-17:15', TRUE),
  (2, 'CNY', 0,              50000, FALSE, NULL,         'BEPS',    10, NULL,    '24x7',                TRUE),
  (3, 'CNY', 0,              50000, FALSE, NULL,         'IBPS',    20, NULL,    '24x7',                TRUE),
  (4, 'CNY', 0,          999999999, TRUE,  NULL,         'CIPS',    10, NULL,    'MON 08:00 -> SUN 20:00', TRUE),
  (5, 'USD', 0,          999999999, TRUE,  NULL,         'SWIFT',   10, NULL,    '24x7 报文',           TRUE),
  (6, 'EUR', 0,          999999999, TRUE,  NULL,         'SWIFT',   10, NULL,    '24x7 报文',           TRUE);

真实系统会把 channel 拆成 “主通道 + 备通道 + 费用等级”，并额外维护 对手行可达性矩阵（某个 BIC 是否加入 CIPS、是否支持 gpi、是否开通 FedNow 等）。

8.6 状态机：一笔跨境支付的全生命周期

下图是一笔跨境支付在支付网关侧的状态机，覆盖了与央行系统交互时最常见的状态迁移：

stateDiagram-v2
    [*] --> Created
    Created --> Validated: 基础校验通过
    Validated --> Screening: 制裁名单筛查
    Screening --> Held: 命中名单 (人工复核)
    Screening --> Sent: 筛查通过, 报文发出
    Held --> Sent: 人工放行
    Held --> Rejected: 合规拒绝
    Sent --> Acked: 清算网关 ACK
    Acked --> Settled: 对端回执 (pacs.002 ACSC)
    Acked --> Returned: pacs.004 退汇
    Acked --> Investigated: camt.029 调查
    Investigated --> Settled: 调查后放行
    Investigated --> Returned: 调查后退汇
    Settled --> [*]
    Returned --> [*]
    Rejected --> [*]

几个关键点：

1. Acked ≠ Settled：很多工程师把 “清算网关回执” 当作到账，这是错的。Fedwire、T2 的 Acked 等价于结算完成；但 SWIFT 的 Acked 只代表 “报文已进入下一跳”，远未到账；
2. Investigated 状态可能反复：RFI 可能被链上多家中间行各发一次；
3. Returned 的退汇要走新的状态机：退汇本身是一笔新的 pacs.004 / MT103 RETN，需要新的 UETR。

8.7 一个 camt.053（账户对账单）的实例

对账单报文 camt.053 是支付工程师每天必打交道的对象。简化示例：

<BkToCstmrStmt>
  <GrpHdr>
    <MsgId>STMT20260422-ICBK-0001</MsgId>
    <CreDtTm>2026-04-22T23:59:59+08:00</CreDtTm>
  </GrpHdr>
  <Stmt>
    <Id>20260422-001</Id>
    <CreDtTm>2026-04-22T23:59:59+08:00</CreDtTm>
    <Acct>
      <Id><Othr><Id>CIPS-ICBKCNBJ-CNY-0001</Id></Othr></Id>
      <Ccy>CNY</Ccy>
    </Acct>
    <Bal>
      <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
      <Amt Ccy="CNY">12345678.90</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Dt><Dt>2026-04-22</Dt></Dt>
    </Bal>
    <Bal>
      <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
      <Amt Ccy="CNY">13456789.01</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Dt><Dt>2026-04-22</Dt></Dt>
    </Bal>
    <Ntry>
      <Amt Ccy="CNY">1000000.00</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Sts><Cd>BOOK</Cd></Sts>
      <BookgDt><Dt>2026-04-22</Dt></BookgDt>
      <NtryDtls>
        <TxDtls>
          <Refs>
            <EndToEndId>E2E-2026042200001</EndToEndId>
            <UETR>a3f1c2b4-5e6d-47a8-9b1c-1234567890ab</UETR>
          </Refs>
        </TxDtls>
      </NtryDtls>
    </Ntry>
  </Stmt>
</BkToCstmrStmt>

对账系统的工作就是把 UETR 或 EndToEndId 与自家账本的业务流水对齐。ISO 20022 的好处在这里非常直观：所有字段结构化、可程序化解析。

九、工程坑点

9.1 时间窗口与截止时间

每个央行系统都有自己的运行时窗口。一个支付网关只要覆盖 CNY + USD + EUR 三种币种，实际上需要维护 6–10 套截止时间表（跨 CNAPS、CIPS、Fedwire、T2、SWIFT gpi Tracker 等）。新手最常见的坑是：

• 只根据北京时间排程，忘了 T2 的 CET 18:00 截止；
• 以为 CIPS 是 7×24，实际上是 周一 08:00 至周日 20:00 的 5×24；
• 周末和节假日叠加问题：美国 MLK Day、中国春节、欧盟 TARGET closing days（2026 例如 Good Friday、Christmas、New Year 等）。

9.2 参与者可达性

不是每家对端银行都能接收某通道的报文。例子：

• 一家美国的州立小信用社可能只加入了 FedLine，不接入 RTP，那么一笔 RTP 就做不了；
• 一家非洲的代理行可能还在 MT MX 共存期继续发 MT103，你要做好双态兼容；
• 一家境外人民币清算行可能只是 CIPS 间接参与者，通过 ICBC 或 BOC 转发。

这是为什么支付网关一定要维护 “对手可达矩阵”，并用外部数据（SWIFT BIC Directory、SWIFTRef、CIPS 参与者列表、Fed FedACH directory）定期刷新。

9.3 费用分摊（Charge Bearer）

ISO 20022 的 ChrgBr 有 DEBT（付款人承担全部）、CRED（收款人承担）、SHAR（分担）、SLEV（按服务级别）。历史 MT103 的 :71A: 字段也是类似三选。坑点：

• SHAR 下的代理行费在跨链长链条时层层扣减，导致收款人实收 “不够整数”，出口商抱怨；
• OUR（DEBT） 下 MT103 要求付款人补贴所有中间费，但并非所有中间行都执行；
• 迁到 ISO 20022 后，建议业务合同明确 “保底到账金额” 并在汇款时用 SLEV 指定。

9.4 退汇与调查

任何一笔跨境汇款都可能被某中间行 RFI（Request for Information，合规调查），退汇通过 pacs.004（原 MT103 退汇 → MT103 REJT，或 MT202 原路返回）。工程坑：

• 原路返回：中间行可能自行兑换汇率，造成汇损；
• 部分退汇：费用扣除后只退部分，账务如何做；
• 调查报文（camt.029 / MT196/199） 与业务工单的联动。

9.5 制裁名单与合规筛查

报文一旦进入 SWIFT / T2 / CIPS / Fedwire 的网关，会被各方合规系统反复筛查（OFAC、EU、HMT、UN、央行名单）。假阳性是日常问题。工程建议：

• 地址规范化：ISO 20022 有结构化地址字段，务必用结构化字段而不是自由文本；
• 名称规范化：拼音 / 罗马转写按 ICAO、IATA 约定；
• 重试策略：被 RFI 命中时不自动重发，等待合规放行。

9.6 流动性管理

RTGS 系统对参与者的流动性非常挑剔。大行会在 T2 CLM、HVPS 早盘往自己的账户注入备付金；流动性不足时：

• FIFO 排队：CIPS、HVPS 都有报文队列，排队久了会超时；
• 取消重发：业务层要区分 “未结算超时” 和 “已结算但回执迟到”，避免重复发起；
• 日终结算失败：DNS 系统（BEPS、CHIPS）有净额结算失败的应急预案（unwind / liquidity arrangement），支付网关要能感知并切换通道。

9.7 UETR 重复与 Idempotency

UETR 按规范是 全链路唯一。但实践中常见两类问题：

• 内部重试导致 UETR 复用：网关对同一业务订单重试时必须复用 UETR，不能每次重新生成，否则对手行看到两笔报文；
• UETR 冲突：极小概率但非零，需要在网关侧建唯一索引并在冲突时报警；
• UETR 跨系统映射：CIPS pacs.008 里的 UETR 与 SWIFT gpi 的 UETR 实际上是同一个——工程上不要再各自生成一份。

9.8 “静默失败”——最可怕的一类故障

Fedwire、HVPS 的报文经过网关发出，若 30 秒内未收到 ACK，工程团队倾向 “重发”。这是经典坑：

• 可能 ACK 在路上延迟，重发后产生 重复结算；
• 可能网关本地落库成功但转发失败，重发安全；
• 可能央行侧已结算但回执网络故障。

工业界的做法是 “只查询、不重发”——超时后主动查询央行侧的状态（camt.056 / MT192 / CIPS 查询报文），确认后再做补偿。支付网关必须实现 “补发查询” 机制，而不是 “无条件重发”。

9.9 2018 印度 PNB Nirav Modi 事件

2018 年印度国家银行（PNB）被发现通过 SWIFT 向境外开立的 150+ 份未入账 LOU（Letter of Undertaking，相当于信用证），总金额约 18 亿美元，所有报文直接从 SWIFT 终端发出但未录入 PNB 的核心系统，造成央行与核心系统严重不一致。根源是 PNB 的 SWIFT 终端没有与核心账务系统联动——只要员工有 SWIFT 发文权限，就能绕过账务发报。

对工程师的教训：SWIFT 终端必须与核心账务强耦合，禁止任何 “脱机报文”。这是 2018 年后印度央行对所有银行的强制要求，也是 CSCF 2.x 的重点控制项之一。

十、选型与落地清单

10.1 场景 → 通道选型

10.2 工程落地清单

• 对手可达矩阵：每个 BIC / 开户行对应支持的清算通道、费率、SLA；
• 报文路由器：按币种、金额、时间、对手三段条件决策；
• 时钟与时间窗口：统一按 UTC 存储，按各清算系统本地时间排程；
• ISO 20022 SDK：推荐基于 camt / pacs / pain 生成与校验的开源工具（如 prowide-iso20022）；
• UETR 端到端：从下游业务系统开始生成 UETR，所有日志可查；
• 清算对账：T+0 对账 + T+1 复核，与 camt.053 / camt.054 对齐；
• 合规前置：在发出报文前做本地制裁筛查，降低 RFI 命中率；
• 灾备演练：主从演练、切换演练、对接行联演；
• 监控看板：按通道显示排队笔数、平均处理时长、成功率、净头寸；
• 退汇 / 调查处理工单化：接入 CRM / 客服工单。

10.3 全景对比表

把本文涉及的系统做一个总览：

10.4 未来展望

2026 年之后，几个可预见的趋势：

1. ISO 20022 成为默认：SWIFT MT/MX 共存期 2025-11 结束，此后新上线的清算系统几乎没有人会考虑 MT；
2. 24×7 化：HVPS、Fedwire、T2 都在讨论延长运行时间（Fedwire 已经宣布 2027 扩展至 22 小时），长远看大额也将 24×7；
3. 跨境零售实时：BIS Nexus 项目（UPI + PayNow + PromptPay + PIX + FedNow 互联）试运行；
4. CBDC 与现有系统并存：数字人民币、欧元数字货币等的零售落地会与 CIPS、TIPS 并存很多年，不是替代（下一篇和第 14 篇细讲）；
5. AI 合规筛查：ISO 20022 的结构化字段让大模型做语义合规（“汇款用途” 风险分类）成为可能，但监管侧会倒逼可解释性。

10.5 多币种支付网关：一个参考架构

把本篇内容落到一张工程架构图，一个支持 CNY / USD / EUR 的多币种支付网关大致长这样：

flowchart TB
    subgraph App["上层业务"]
        Biz["交易中心 / 商户平台"]
    end
    subgraph GW["支付网关 (PG)"]
        API["对外 API\n(RESTful / gRPC)"]
        Router["清算路由器\n(币种+金额+对手+时间)"]
        Compliance["合规引擎\n(制裁 / 反欺诈)"]
        MsgFactory["ISO 20022 报文工厂"]
        StateSM["支付状态机"]
        Ledger["子账 / 流水"]
    end
    subgraph Conn["清算通道适配器"]
        HVPSc["CNAPS Connector\n(HVPS/BEPS/IBPS)"]
        CIPSc["CIPS Connector\nFINplus / 专线"]
        SWIFTc["SWIFT Alliance\nMT/MX"]
        Fedc["Fedwire / FedNow\nFedLine"]
        T2c["T2 / TIPS\nESMIG"]
    end
    subgraph Ops["运营 / 运维"]
        Reco["对账系统 (camt.053/054)"]
        Dash["监控看板"]
        DR["灾备 / 演练"]
    end

    Biz --> API
    API --> Compliance --> Router
    Router --> MsgFactory --> StateSM
    StateSM --> HVPSc
    StateSM --> CIPSc
    StateSM --> SWIFTc
    StateSM --> Fedc
    StateSM --> T2c
    HVPSc --> Ledger
    CIPSc --> Ledger
    SWIFTc --> Ledger
    Fedc --> Ledger
    T2c --> Ledger
    Ledger --> Reco
    Reco --> Dash
    StateSM --> Dash

关键设计原则：

1. Connector 层按清算系统隔离：每个 Connector 独立部署，配额、限流、灰度独立；
2. 报文工厂按 schema 版本管理：ISO 20022 每年发布一次 Release（如 2024 CR、2025 CR），不同对端可能在不同版本，需要按对端动态选择 schema；
3. 状态机中心化：无论走哪条 Connector，状态机统一，便于运营看板聚合；
4. 对账异步化：T+0 对账不阻塞实时支付，T+1 人工复核；
5. 合规前置：制裁筛查在生成报文前完成，以避免出境报文被退回；
6. 灰度与演练：每一条 Connector 都要能够在 5 分钟内切换到备用通道或备用代理行。

10.6 给跨境 PSP 的最小可行接入

如果你在做一家跨境 PSP（比如支持跨境电商收款），最小可行的接入顺序是：

1. 第一阶段：只接 SWIFT（通过服务商如 Currencycloud、Nium、连连国际），拿到基本可达性；
2. 第二阶段：加一家 CIPS 间接参与者（或直接成为间接参与者），降低人民币跨境成本；
3. 第三阶段：加 SEPA SCT Inst（通过欧洲持牌 EMI）、加 Fedwire / FedNow（通过美国持牌银行）；
4. 第四阶段：自己成为 CIPS / T2 的间接 / 直接参与者。

每一步都涉及 6–12 个月的接入项目，技术之外还有牌照、资本金、合规审计的门槛。

10.7 成本与流动性的量级感

给工程师一个粗略的 “量级直觉”（以单笔支付为单位，不构成投资建议）：

• 一笔境内 HVPS 大额：央行收费极低（按笔费 < 1 元），主要成本是接入方自持的流动性；
• 一笔 CIPS 跨境：直参按笔费约几元人民币，间参经代理行后约几十元；
• 一笔 SWIFT 跨境美元：代理行链条累计 $15–$50 费用 + 汇差点差；
• 一笔 SEPA SCT Inst：0–0.2 欧元，几乎免费；
• 一笔 FedNow：发起方由参与行自定价，交互费（interbank fee）极低（美联储侧收费低于 5 美分）；
• 一笔 UPI / PIX：零售 P2P 免费。

这也解释了为什么出海跨境电商的毛利对 “选哪条通道” 极度敏感——1% 的成本差就能决定一个 PSP 的生死。

十一、小结

央行支付系统是金融基础设施里最 “底座” 的一层，但对工程师来说并不神秘——它无非是 一套报文 + 一套参与者清单 + 一个央行账簿。本篇我们看到：

• 中国已经形成 HVPS（大额）+ BEPS（小额）+ IBPS/网联（零售实时）+ CIPS（跨境）+ 银联（卡） 的完整体系；
• 美国维持 Fedwire + FedNow（央行）+ CHIPS + RTP（私营） 的公私并存；
• 欧元区完成了 T2 整合、SEPA SCT Inst 强制化、TIPS 外币化；
• SWIFT 是 “信封”，清算系统才是 “腿”；
• UPI、PIX 用公共基础设施颠覆了卡组织，给后来者提供了一条新路径。

工程师需要记住的三句话：

1. 最终结算一定落在央行账户——任何绕开央行的 “到账” 都是借条，不是货币；
2. RTGS 求确定性、DNS 求效率、FPS 求实时——没有银弹，选型看场景；
3. ISO 20022 是唯一的跨越方言的通用语——MT 已进入倒计时，新系统不应再以 MT 为第一格式。

在下一篇《跨境支付工程：代理行、nostro/vostro、汇率锁定、对手方风险》中，我们会从 跨境单一一笔交易的账务视角 出发，把本篇涉及的 SWIFT、CIPS、T2、Fedwire 四条腿在代理行账本上的具体落账讲透。

参考资料

1. 中国人民银行《中国支付清算体系发展报告》（年度）
2. CIPS 官网统计与年报：https://www.cips.com.cn/
3. 网联清算公司年报：https://www.nucc.com/
4. 中国银联年报：https://cn.unionpay.com/
5. Federal Reserve《Services - Fedwire Funds Service》：https://www.frbservices.org/
6. Federal Reserve FedNow Service：https://www.frbservices.org/financial-services/fednow
7. The Clearing House CHIPS / RTP：https://www.theclearinghouse.org/
8. European Central Bank TARGET Services：https://www.ecb.europa.eu/paym/target/html/index.en.html
9. European Payments Council SEPA Rulebooks：https://www.europeanpaymentscouncil.eu/
10. SWIFT gpi / ISO 20022 Migration：https://www.swift.com/standards/iso-20022-migration
11. NPCI UPI Product Overview：https://www.npci.org.in/
12. Banco Central do Brasil PIX：https://www.bcb.gov.br/en/financialstability/pix_en
13. BIS CPMI《Red Book》各国支付清算体系国别报告：https://www.bis.org/cpmi/publ/d172.htm
14. 《Bank of New York 1985 Fedwire Incident》公开调查报告（Federal Reserve Bulletin）

上一篇：《清算 vs 结算 vs 资金归集：T+0/T+1、NDS、PvP/DvP》

下一篇：《跨境支付工程：代理行、nostro/vostro、汇率锁定、对手方风险》