2026-04-22 · architecture / fintech
【金融科技工程】支付系统全景：收单、发卡、聚合、跨境、B2B、C2C
把模糊的"支付"一词拆成可工程化的系统分类——四方参与者、收单发卡双边、卡组织与钱包通道、中国与国际的费率结构、实时支付浪潮、以及一张完整的资金流图。
在本系列第 11 篇《清算 vs 结算 vs 资金归集》中，我们把 “净额（Netting）— 清算（Clearing）— 结算（Settlement）” 这三层拆开看。一个很自然的问题是：最终结算到底发生在哪里？
答案是：央行的账本。
无论是支付宝一次扫码、Fedwire 一笔十亿美金汇款、SEPA 里欧元的跨境直接借记，最终 “钱从 A 银行流到 B 银行” 都必须落在央行为各商业银行开立的备付金账户（Reserve Account）之间。这件事之所以严肃，是因为央行是 唯一不会破产的对手方——它发行本币，没有信用风险（当然有主权风险，但那是另一个话题）。
本篇的读者画像：
本文不是法规手册，我们关心 报文怎么走、时间窗口怎么卡、参与者怎么接入、典型故障长什么样。
几乎所有国家的央行支付系统都刻意做了 大额 / 小额 两条线：
| 维度 | 大额系统（Wholesale） | 小额系统（Retail） |
|---|---|---|
| 典型金额 | 百万 ~ 百亿本币 | < 100 万（多数 < 5 万） |
| 延迟要求 | 秒级（合规要求金融市场交易当日结算） | 通常允许几分钟乃至几小时 |
| 发起方 | 银行同业、大客户 | 个人 / 商户 |
| 报文单笔 | 一笔一报文 | 批量文件 |
| 结算 | RTGS | DNS 或 FPS |
| 停机窗口 | 有（夜间维护） | 越来越要求 24×7 |
小额 24×7 化是过去十年最大的变化——网联、FedNow、TIPS、UPI、PIX 本质上都在把 RTGS 的 “实时终局” 延展到 C 端零售。
这是央行系统的核心卖点。当一笔结算在央行账户上完成借贷记，就不可逆转——即使发起方之后破产、被撤销授权、被司法冻结，结算本身不回滚。这是各国央行法赋予的强制力（如中国《支付结算办法》、欧盟 Settlement Finality Directive 98/26/EC、美国 Regulation J）。对工程师的意义是：央行回执是业务层 “到账” 状态机的终点，后续的任何差错处理只能通过新开一笔反向交易。
理解任何一个央行系统，只需要抓三件事：
下面讲每个系统都会围绕这三元组展开。一个 “接入央行系统” 的项目 60% 工作量花在报文，20% 花在账户对账，10% 花在合规与审计，10% 花在运营窗口适配——这是一个经验性的经验分布。
几乎所有央行零售实时支付系统（FedNow、TIPS、网联）都采用 “母账户 + 子账户” 的双层模型：
这样做的原因是：24×7 实时结算不能在母账户上做（母账户仍按工作日运行），只能在 “实时结算专用账户” 上做；同时又要让这部分资金与母账户的流动性管理联动。工程上这种双层模型需要额外维护账户余额镜像、双向同步、流动性预警告。
中国人民银行主导的清算基础设施，可以看成四层叠加：
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 上做资金头寸的划转。
CNAPS（Chinese National Advanced Payment System，中国现代化支付系统） 是人民银行自建的一、二代系统统称。一代 CNAPS-1 于 2002 年、2005 年相继投产 HVPS 和 BEPS；二代 CNAPS-2 于 2013 年上线，在一代基础上引入了更强的报文、业务处理与直接参与者灵活接入。
直接参与者主要是全国性商业银行的总行法人、政策性银行、部分外资银行分行；城商行、农信社、村镇银行通过 间接参与者 方式通过直接参与者代理接入 CNAPS。这意味着一家小银行若要自己发起 HVPS 报文，路径是 “小银行 → 代理总行 → HVPS”。
CNAPS 的报文格式最初基于 MT 格式 改造（如 CBS103 对应 MT103 客户汇款、CBS202 对应 MT202 机构汇款），后逐步向 ISO 20022 靠拢。人民银行清算总中心（PCCC）还运营 同城票据交换系统 与 支票影像系统（ECDS，Electronic Commercial Draft System 之前的前身），形成了中国特有的 电子商业汇票（ECDS / 承兑汇票） 清算生态。
一笔典型的 HVPS 报文包含：发起行、代理行链、收款行、金额、币种（只有人民币）、汇款用途（结构化 + 自由文本）、交易时间戳、业务种类码。报文经过 PCCC 校验后由 PCCC 发送给收款行、并在人民银行账户上同步借贷记。
HVPS 的停机窗口主要在夜间维护（具体窗口随监管公告），工作日早盘 8:30 前需完成启动。对接入方而言，必须维护 两地三中心（北京、上海、异地），任一中心故障不影响对接。实际上 2020 年人民银行完成了清算中心南北双活，参与者同步需要支持双活切换与同城异步复制。
IBPS（Internet Banking Payment System）是 CNAPS 家族中面向互联网银行的跨行实时清算，2010 年上线，俗称 超级网银。它支持 7×24 实时到账，单笔上限起初是 5 万、后放开。IBPS 在 2017 年后被 “扩展” 为网联的承接底座——实质上网联的清算底是架在 IBPS 之上的。
在 2017 年之前，第三方支付机构（支付宝、财付通等）直接与数百家银行一对一对接，每家银行开一个备付金账户，清算在支付机构的账本内部完成。这带来了两个问题：
人民银行 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”）接近百亿笔——是世界上日吞吐最大的零售清算系统之一。
网联的几个工程细节：
对支付机构（比如一家 PSP）来说，接入网联后的对账流程与 2017 前有两个明显区别：
工程上这意味着支付机构的 “对账系统” 从 “N 家银行 × N 份文件” 简化为 “网联 + 银联 × 2 份文件”，但解析标准更严格。
银联（UnionPay / CUP，中国银联股份有限公司） 是 2002 年成立的国内银行卡组织，BIN 以 62 开头。它承担两块业务：
银联 vs 网联的一句话分工：“卡走银联，码走网联”。刷卡（含云闪付扫静态码走卡 Token 的情形）走银联的交换与清算，二维码 / APP 内的扫码支付走网联。两者不重合，但都在人民银行监管下、最终结算落在 HVPS。
CIPS（Cross-border Interbank Payment System，人民币跨境支付系统） 由人民银行发起、2015 年上线一期、2018 年上线二期，运营主体是 跨境银行间支付清算（上海）有限责任公司。
参与者结构：
CIPS 与 SWIFT 的关系（最常见误解）：
| 维度 | CIPS | SWIFT |
|---|---|---|
| 性质 | 清算组织 + 报文 | 仅报文网络 |
| 承担结算 | 是（人民银行账户） | 否 |
| 覆盖币种 | 人民币 | 200+ 币种报文 |
| 替代关系 | CIPS 可使用 SWIFTNet 通道传报文 | SWIFT 不做清算 |
2024 年数据：CIPS 全年处理业务约 820 万笔、175 万亿元人民币（CIPS 官方年报），同比增长约 43%，其中 RCEP 区域占比快速提升。俄乌冲突后部分俄罗斯银行被 SWIFT 制裁，俄方银行使用 CIPS 的报道增多，但 CIPS 官方口径一直强调其是 人民币结算系统、非替代 SWIFT 的政治工具。
直接参与者可以选择两种连接方式：
间接参与者则通过直接参与者的代理服务接入。工程上，选哪种方式主要看：是否境外、是否已有 SWIFT 基础设施、业务量是否够大以摊销专线成本。
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，清算所银行同业（TCH，The Clearing House）运营 CHIPS 和 RTP。
Fedwire 是美联储运营的 RTGS 系统，前身是 1918 年的 莫尔斯码电报转账网络（用于一战期间财政部跨行转账），1970 年代电子化。今天它由两部分构成：
Fedwire 的参与者是 存款机构（Depository Institution），必须在美联储开立准备金账户。截至 2024 年约有 9800+ 家参与者。
1985 年 BNY 事故：1985 年 11 月 21 日，纽约梅隆银行（Bank of New York）用于处理 Fedwire 收付的软件出现文件指针故障，导致其在无法入账美国国债 Fedwire Securities 交易的情况下继续向交易对手支付资金，当日透支美联储贴现窗口高达 237 亿美元，需要以所有美国国债为抵押、按当晚联邦基金利率计息借入。这是支付系统工程史上最著名的单点故障之一，催生了后来对参与者透支上限（Net Debit Cap）、流动性保障与软件变更审计的严监管。
FedNow 于 2023 年 7 月 20 日正式启动，是美联储运营的 7×24 小时、365 天的即时支付系统。
FedNow 与私营的 TCH RTP（The Clearing House Real-Time Payments，2017 上线）形成竞合关系。RTP 由大行共同出资，覆盖面商业化扩展快但对小银行的接入成本高；FedNow 依赖美联储的既有接入通道（FedLine），小银行可以复用现有连接，因此 FedNow 的市场策略是 “长尾银行优先”。
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 是代理行网络的 “大动脉”。
Fedwire 有一个与中国 HVPS 显著不同的设计：允许参与者日间透支准备金账户。美联储按透支金额、按秒计费（Daylight Overdraft Fee），年化约 50 bps 左右（具体费率定期调整）。这对工程的含义：
1985 年的 BNY 事故就是透支上限机制的 “反向案例”——当时的 Fedwire Securities 还没有对证券交易实施严格的透支限制，导致一夜透支 237 亿美元。事故后美联储引入了对证券交易的 Net Debit Cap、以及 抵押品要求（collateralized daylight overdraft）。
以一笔 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，不可撤销——即使买方发现转错账户，也只能让卖方银行配合 “原路退汇”，而这需要卖方同意。这是工程层面的 “不可逆” 设计。
欧元区的支付基础设施由 欧洲央行（ECB）+ 国家央行体系（Eurosystem） 共同运营。2022–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 服务两个分层：
同时，这次改造 把所有内部报文迁移到 ISO 20022（原本用 SWIFT FIN MT），并采用 SWIFT 的 MX 报文（pacs / camt / admi）。对工程师来说，最大的变化是：T2 参与者必须在 2023-03 前完成报文改造，这是欧元区最大规模的一次 ISO 20022 原生切换。
T2 日均约 40 万笔、2.2 万亿欧元（ECB 2024 年度统计）。
T2S（TARGET2-Securities） 2015–2017 分批上线，是一个 泛欧证券结算 CSD 整合平台。它不是 CSD 本身（CSD 仍是各国的如德国 Clearstream、法国 Euroclear France），而是把各国 CSD 的 “证券账户” 和央行的 “现金账户” 接入同一结算引擎，实现真正的 DVP（Delivery versus Payment）。
参与 T2S 的 CSD 约 20+ 家，覆盖多数欧元区市场。对撮合-结算链路的意义是：一笔跨境证券交易的 DVP 可以在 T2S 上一步完成，不需要像过去那样跨多个 CSD 做代理行对接。
SEPA（Single Euro Payments Area，单一欧元支付区） 是另一个层面的制度安排——让欧元区内部的跨国欧元支付 “像国内支付一样便宜快捷”。SEPA 本身不是一个系统，而是一套 规则 + 报文标准 + 参与者框架，由欧洲支付理事会（EPC）制定。具体清算可以跑在多个清算基础设施（CSM）上，如 EBA Clearing 的 STEP2、各国本地 ACH 等。
SEPA 三大支付工具：
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 实时成为标配。
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）服务就是负责这些划拨的管理层。工程上这意味着：
除了 ECB 自己运营的 T2 / TIPS，欧元区还有一家私营清算组织 EBA Clearing（European Banking Authority Clearing，私营，不是监管机构）。它运营：
一家欧洲的银行通常会同时接 STEP2（批量）和 TIPS（实时），报文均为 ISO 20022。
SWIFT（Society for Worldwide Interbank Financial Telecommunication） 成立于 1973 年，总部设在比利时 La Hulpe，是一家合作社性质的报文网络提供商，不承担结算、不持有资金、不是银行。它提供的是：
一次典型跨境汇款（MT103），SWIFT 的角色是把这条结构化报文从 A 行送到 B 行。真正的清算落在 CIPS、Fedwire、CHIPS、TARGET2 等 底层清算系统。SWIFT 是 “信封”，清算系统才是 “邮递员的腿”。
2025 年 11 月 22 日 是 SWIFT 社区计划的 MT/MX 共存期（Coexistence Period）结束日。之后，跨境支付类 MT 报文（MT1xx、MT2xx、MT9xx 等）将被 下线，全面迁移到 MX（ISO 20022）：
MX 带来的工程好处：
SWIFT gpi（global payments innovation） 2017 年推出，解决传统 MT103 “汇出后失联” 的老问题。核心机制：
{121:} 字段声明，全链路保持；gpi 的效果（SWIFT 2024 年数据）：约 90% 的跨境支付在一小时内入账至收款行，其中过半数在 5 分钟内。对比 2016 年前 “三五个工作日到账” 的常态，这是代理行模式数字化的最大一次提速。
2022 年 3 月起，欧盟决议要求 SWIFT 断开俄罗斯七家银行（Sberbank、VTB 等）的 SWIFTNet 接入；后续又追加。被断开意味着这些银行无法通过 SWIFT 发/收报文——但 不代表不能做跨境支付，它们仍可以通过代理行、CIPS、俄罗斯本土的 SPFS 或 Telex、邮政等方式继续业务，只是成本和速度显著恶化。这个事件反过来让全球主要经济体重新审视 “支付基础设施的主权”——CIPS、SPFS、印度 SFMS、BRICS Pay 的讨论都由此升温。
2016 年 2 月 5 日，孟加拉国央行储备在纽联储的账户被通过 SWIFT 发送的 35 笔伪造 MT103 报文骗取了约 1.01 亿美元（其中 8100 万美元最终未被追回）。攻击者在孟加拉央行的 SWIFT 终端植入恶意软件，篡改了本地的 SWIFT Alliance Access 日志与打印机输出以掩盖痕迹。
这个事件对全球 SWIFT 用户的直接影响是：
对工程师的实操影响：接入 SWIFT 的内网终端一定要做 网络分区 + 终端审计 + HSM 签名 + 双人复核，这已成行业最低线。
如果说网联、FedNow、TIPS 是 “现有央行系统 + 零售化”，那么 UPI 和 PIX 则是 “直接从零售起步、顺手把卡组织和钱包也替代了” 的另一条路径。
UPI（Unified Payments Interface） 由 NPCI（National Payments Corporation of India，印度储备银行和银行业联合成立的非营利机构）2016 年上线。关键设计：
user@bank）：支付身份与账号解耦；截至 2024 年 12 月，UPI 日均处理 5 亿+ 笔，年处理约 1700 亿笔，已超过全球 Visa + Mastercard 的合计笔数——是全球最大的零售即时支付网络。清算底由 NPCI 的 NFS、IMPS 系统承接，最终落在 RBI（印度央行）的 RTGS 账户。
PIX 由巴西中央银行（BCB）2020 年 11 月上线，是央行亲自运营的 24×7 即时支付系统。一些关键设计：
上线四年，PIX 已覆盖巴西 90%+ 成年人口，日均 2 亿+ 笔，彻底颠覆了 Visa/Mastercard 在巴西的小额支付地位，也让巴西的 “无现金化” 速度超越北美。
UPI 和 PIX 给工程师的启发不是技术——技术其实并不新鲜（报文、清算、别名目录都是成熟技术）——而是 制度设计：
对比之下，网联更像 “公私合营 + 行政推动”，而 FedNow 则是 “央行做基础设施、商业市场自发扩展” 的中间形态。
| 国家 / 地区 | 系统名 | 上线 | 日吞吐（2024） | 特点 |
|---|---|---|---|---|
| 英国 | FPS（Faster Payments Service） | 2008 | 约 1200 万笔 | 全球最早的零售 24×7 FPS |
| 新加坡 | FAST / PayNow | 2014 / 2017 | 数百万笔 | 银行间互联，别名支付 |
| 香港 | FPS | 2018 | 数百万笔 | 多币种（HKD、CNY）、扫码互通 |
| 泰国 | PromptPay | 2017 | 数千万笔 | 手机号 / 身份证号别名 |
| 澳大利亚 | NPP（New Payments Platform） | 2018 | 数百万笔 | 支持 Overlay Services（如 PayTo） |
| 日本 | Zengin / 全银 | 1973 | 数千万笔 | 传统批量 + 2018 MORE 全日运营 |
| 俄罗斯 | SBP（Faster Payments System） | 2019 | 数千万笔 | 央行运营，零售主流 |
| 韩国 | KFTC | 1988 / 持续升级 | 数千万笔 | 韩国银行间支付底 |
这些系统的共同特征：都采用 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几个关键观察：
不管哪一家央行系统，对商业机构的身份大致分三档：
| 身份 | 说明 | 工作量 |
|---|---|---|
| 直接参与者 | 自己在央行开清算账户、自己发报文 | 数百人月级别的接入项目，含 ISO 20022 适配、合规、7×24 运维 |
| 间接参与者 | 通过直接参与者代理接入，直接参与者帮你发报文、你拿到回执 | 相对轻量，但要做业务集成 |
| 代理行客户 | 通过一家直接参与者开立结算账户，拿报文结果对账 | 最轻量，类似 “银行的客户” |
工程师要先搞清楚自家业务在对方系统里处在哪一档，这决定了你要对接的是 央行的接入网关 还是 代理行的 API。
以接入 CIPS 直接参与者为例，简化清单：
接入 T2、Fedwire、FedNow 的流程大同小异，差别在报文字典、运行时窗口、流动性管理工具（CLM、Fedwire throughput cap）。
如果只是接入小额、局部业务，更常见的是找一家代理行（往往是自家业务上的开户总行），让它帮你：
这是绝大多数中小银行、跨境支付 PSP（如 Wise、Airwallex）的真实姿态。
截至 2026 年，全球主流央行清算系统已经全面以 ISO 20022 为主：
| 系统 | ISO 20022 状态 |
|---|---|
| CIPS | 2018 二期原生 |
| T2 / TARGET2 | 2023 迁移完成 |
| FedNow | 2023 原生 |
| Fedwire | 2025–2026 迁移中（CHIPS 已迁移） |
| SWIFT 跨境 | 2022 起共存、2025-11 完成 |
| HVPS | 逐步支持 |
| TIPS / SEPA | 原生 |
ISO 20022 在工程上的好处（对比 ISO 15022 / MT）：
一个 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 存在、金额十进制位、字符集等。
支付网关在接收到一笔跨境或跨行支付请求时，通常需要根据币种、金额、对端 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 等）。
下图是一笔跨境支付在支付网关侧的状态机，覆盖了与央行系统交互时最常见的状态迁移：
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 --> [*]几个关键点：
对账单报文 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
的好处在这里非常直观：所有字段结构化、可程序化解析。
每个央行系统都有自己的运行时窗口。一个支付网关只要覆盖 CNY + USD + EUR 三种币种，实际上需要维护 6–10 套截止时间表（跨 CNAPS、CIPS、Fedwire、T2、SWIFT gpi Tracker 等）。新手最常见的坑是：
不是每家对端银行都能接收某通道的报文。例子：
这是为什么支付网关一定要维护 “对手可达矩阵”，并用外部数据（SWIFT BIC Directory、SWIFTRef、CIPS 参与者列表、Fed FedACH directory）定期刷新。
ISO 20022 的 ChrgBr 有
DEBT（付款人承担全部）、CRED（收款人承担）、SHAR（分担）、SLEV（按服务级别）。历史
MT103 的 :71A: 字段也是类似三选。坑点：
SLEV 指定。任何一笔跨境汇款都可能被某中间行 RFI（Request for Information，合规调查），退汇通过 pacs.004（原 MT103 退汇 → MT103 REJT，或 MT202 原路返回）。工程坑：
报文一旦进入 SWIFT / T2 / CIPS / Fedwire 的网关，会被各方合规系统反复筛查（OFAC、EU、HMT、UN、央行名单）。假阳性是日常问题。工程建议：
RTGS 系统对参与者的流动性非常挑剔。大行会在 T2 CLM、HVPS 早盘往自己的账户注入备付金；流动性不足时：
UETR 按规范是 全链路唯一。但实践中常见两类问题：
Fedwire、HVPS 的报文经过网关发出，若 30 秒内未收到 ACK，工程团队倾向 “重发”。这是经典坑：
工业界的做法是 “只查询、不重发”——超时后主动查询央行侧的状态（camt.056 / MT192 / CIPS 查询报文），确认后再做补偿。支付网关必须实现 “补发查询” 机制，而不是 “无条件重发”。
2018 年印度国家银行（PNB）被发现通过 SWIFT 向境外开立的 150+ 份未入账 LOU（Letter of Undertaking，相当于信用证），总金额约 18 亿美元，所有报文直接从 SWIFT 终端发出但未录入 PNB 的核心系统，造成央行与核心系统严重不一致。根源是 PNB 的 SWIFT 终端没有与核心账务系统联动——只要员工有 SWIFT 发文权限，就能绕过账务发报。
对工程师的教训：SWIFT 终端必须与核心账务强耦合，禁止任何 “脱机报文”。这是 2018 年后印度央行对所有银行的强制要求，也是 CSCF 2.x 的重点控制项之一。
| 场景 | 推荐通道 | 理由 |
|---|---|---|
| 境内大额对公 | HVPS（CNAPS） | RTGS、终局强 |
| 境内小额对公 | BEPS | 7×24、成本低 |
| 境内零售 P2P / P2M | IBPS / 网联 | 7×24 实时 |
| 人民币跨境 | CIPS + SWIFT | CIPS 清算 + SWIFT 报文（或 CIPS 报文直连） |
| 美元跨境 | SWIFT + CHIPS / Fedwire | 代理行 + 美元终局 |
| 欧元跨境 | SWIFT + T2 + SEPA SCT Inst | 大小额分治 |
| 美国境内零售实时 | FedNow 或 RTP | 看对手行是否加入 |
| 欧盟零售实时 | SEPA SCT Inst（TIPS） | IPR 强制到位 |
| 印度 / 巴西零售 | UPI / PIX | 本币、公共基础设施 |
把本文涉及的系统做一个总览：
| 系统 | 地域 | 类型 | 模式 | 运行时间 | 报文 | 单笔上限 | 典型日吞吐 |
|---|---|---|---|---|---|---|---|
| HVPS | 中国 | 大额 | RTGS | 工作日 8:30–17:15 延长 | ISO 20022 / 国标 | 无 | ~百万笔 |
| BEPS | 中国 | 小额 | DNS | 7×24 | 国标 | 5 万元 | ~千万笔 |
| IBPS / 网联 | 中国 | 零售 | 实时 | 7×24 | 国标 + ISO 20022 | 无明确 | >20 亿笔 |
| 银联（CUP） | 中国 | 卡 | 净额 | 7×24 | ISO 8583 | 按卡 | 亿笔级 |
| CIPS | 中国 / 跨境 | 跨境 | RTGS | 5×24 | ISO 20022 | 无 | ~3 万笔 |
| Fedwire | 美国 | 大额 | RTGS | 工作日扩展 | MT / MX 迁移中 | 无 | ~80 万笔 |
| FedNow | 美国 | 零售 | 实时 | 7×24 | ISO 20022 | 50 万美元 | 数万笔增长中 |
| CHIPS | 美国 | 大额 | DNS | 工作日 | MX（已迁完） | 无 | ~50 万笔 |
| RTP（TCH） | 美国 | 零售 | 实时 | 7×24 | ISO 20022 | 100 万美元 | 数百万笔 |
| T2 RTGS | 欧元区 | 大额 | RTGS | 工作日扩展 | ISO 20022 | 无 | ~40 万笔 |
| T2S | 欧元区 | 证券 | DVP | 工作日 | ISO 20022 | 无 | 数十万笔 |
| TIPS | 欧元区 | 零售 | 实时 | 7×24 | ISO 20022 | 无（IPR 后） | 数百万笔 |
| STEP2 | 欧元区 | SEPA 批量 | DNS | 多窗口 | ISO 20022 | 无 | 数千万笔 |
| SWIFT | 全球 | 报文 | — | 7×24 | MT / MX | — | ~5000 万报文 |
| UPI | 印度 | 零售 | 实时 | 7×24 | 本地 | 数百万卢比 | >5 亿笔 |
| PIX | 巴西 | 零售 | 实时 | 7×24 | ISO 20022 变体 | 无（可限） | >2 亿笔 |
2026 年之后，几个可预见的趋势：
把本篇内容落到一张工程架构图，一个支持 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关键设计原则：
如果你在做一家跨境 PSP（比如支持跨境电商收款），最小可行的接入顺序是：
每一步都涉及 6–12 个月的接入项目，技术之外还有牌照、资本金、合规审计的门槛。
给工程师一个粗略的 “量级直觉”（以单笔支付为单位，不构成投资建议）：
这也解释了为什么出海跨境电商的毛利对 “选哪条通道” 极度敏感——1% 的成本差就能决定一个 PSP 的生死。
央行支付系统是金融基础设施里最 “底座” 的一层，但对工程师来说并不神秘——它无非是 一套报文 + 一套参与者清单 + 一个央行账簿。本篇我们看到：
工程师需要记住的三句话：
在下一篇《跨境支付工程：代理行、nostro/vostro、汇率锁定、对手方风险》中，我们会从 跨境单一一笔交易的账务视角 出发，把本篇涉及的 SWIFT、CIPS、T2、Fedwire 四条腿在代理行账本上的具体落账讲透。
上一篇：《清算 vs 结算 vs 资金归集：T+0/T+1、NDS、PvP/DvP》
下一篇：《跨境支付工程：代理行、nostro/vostro、汇率锁定、对手方风险》
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / fintech
把模糊的"支付"一词拆成可工程化的系统分类——四方参与者、收单发卡双边、卡组织与钱包通道、中国与国际的费率结构、实时支付浪潮、以及一张完整的资金流图。
2026-04-22 · architecture / fintech
系列收官。从货币形态、即时支付、AI、隐私计算、DeFi、监管科技、云原生、后量子密码八大趋势出发，给出未来 5–10 年的工程判断；再给出从入门到专家的金融科技工程师成长路线，以及书单、论文、开源项目与 25 篇全景索引。
2026-04-22 · architecture / fintech
一笔刷卡交易从 POS/网关到发卡行再到清算的全链路剖析：授权、认证（3DS）、清算、结算、争议与对账；ISO 8583 报文拆解、BIN/PAN/Token、EMV 3DS、PCI DSS 与 HSM；附 Python/Go 构造 0100 报文示例。
2026-04-22 · architecture / fintech
一文讲清 Clearing、Settlement、Cash Pooling 三个最易混淆的金融词汇的工程区分；从 RTGS/DNS 的选型、PvP/DvP 的风险消除机制，到商户清分引擎、T+1 批处理、二清合规边界，再到网联 IBPS、FedNow、PIX 的实时化浪潮。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。