土法炼钢兴趣小组的算法知识备份

【金融科技工程】13 跨境支付工程：代理行、nostro/vostro、汇率锁定、对手方风险

2026-04-22 · architecture · fintech · #cross-border #correspondent-banking #swift-gpi #fx #nostro #wise #airwallex #stablecoin #mbridge #aml

文章导航

分类入口
architecturefintech
标签入口
#cross-border#correspondent-banking#swift-gpi#fx#nostro#wise#airwallex#stablecoin#mbridge#aml

目录

引子

如果把境内支付比作”在自家小区骑自行车”，跨境支付就更像是”自驾穿越七个国家、每个国家都要换车、换油、换驾照、还要报税”。

境内转账慢一点、错一笔都算事故，但在跨境语境下，一笔汇款从纽约发到越南胡志明市，经过三家代理行、三天到账、收款方收到的金额比应收少了 48 美元、没有人能准确告诉你这 48 美元扣在谁头上——这是 2025 年仍然每天在全球上演的常态。

更戏剧性的是，这个”三天 48 美元”的局面，过去二十年几乎没有被颠覆——直到 Wise 在 2010 年代开始撕开口子，直到稳定币在 2020 年代提供了”无代理行”的备选路径，直到 CBDC 桥在 2024 年之后把”多央行直结算”推上桌面。但即便如此，代理行链路仍然占全球跨境清算金额的大部分，它不是一个要被消灭的对象，而是一个要被理解、包装、旁路、再和新通道并存的遗产基础设施。

跨境支付难，难在它不是”一个系统”而是”一串系统”：

本文的目标读者是在做出海业务、跨境电商、国际汇款、全球财资、稳定币支付的工程师与产品。我们不做金融学科普，而是把跨境支付拆到能写代码的颗粒度：

  1. 三大主链路：代理行、卡组织、钱包/账户类；
  2. Nostro/Vostro/Loro 的资金流建模；
  3. SWIFT MT103 的”黑盒”问题与 SWIFT gpi 的工程解法；
  4. 外汇（FX）工程：点差、中间价、汇率锁定、报价引擎；
  5. 实时跨境的未来：稳定币、mBridge、UPI-PayNow 互联；
  6. AML、制裁名单、FATCA/CRS 的工程落地；
  7. 中国出海商户从”收款”到”结汇落地”的全链路；
  8. Wise、Airwallex、Stripe 的架构拆解；
  9. 工程踩坑与选型建议。

写作上的一个约定：跨境支付的概念链非常长，任何一处展开都能写成一本书。本文选择以工程流程为主线——从一笔汇款发起到最终到账，中间的每一个环节都落到”谁的账本、什么报文、多少延迟、多少费用、谁来合规”这五个维度。读到困惑时，可以随时回到第一节的那张参与方图去对应位置。

与本系列的关系：前序第 11、12 篇铺垫了境内清算结算与央行基础设施，本文是”跨境版”；后续第 14 篇会深入数字货币视角的跨境结算（稳定币、CBDC）；第 21 篇会把本文中的 AML/KYC 展开到独立章节；第 23 篇会把 Nostro 对账这种”对账之王”单独讨论。因此本文会在每个交叉点留一个钩子，但不展开到下一篇会覆盖的深度。

一、跨境支付的参与方图谱

1.1 一笔汇款至少经过多少个节点

来一张最基础的图，把参与方先摆出来。

flowchart LR
    Sender([汇款人<br/>US]) --> OB[汇款行<br/>Originating Bank]
    OB --> CB1[中转行 1<br/>Correspondent]
    CB1 --> CB2[中转行 2<br/>Correspondent]
    CB2 --> BB[收款行<br/>Beneficiary Bank]
    BB --> Receiver([收款人<br/>VN])

    subgraph SWIFT网络
      OB -. MT103 .-> CB1
      CB1 -. MT103 .-> CB2
      CB2 -. MT103 .-> BB
    end

    subgraph 清算网络[本地清算/RTGS]
      OB -. Fedwire USD .-> CB1
      CB2 -. 本地 RTGS VND .-> BB
    end

几个工程上要立刻意识到的点：

1.2 三大主链路一览

链路 代表 报文标准 资金载体 典型到账时间 典型成本
代理行（Correspondent Banking） 花旗、汇丰、摩根大通、中行 SWIFT MT103、ISO 20022 pacs.008 Nostro/Vostro 账户 + 各国 RTGS T+1 ～ T+3 15～50 USD/笔 + FX 点差
卡组织跨境 Visa、Mastercard、银联国际、Discover、Amex Visa BASE II、Mastercard GCMS、ISO 8583、银联 CUPS 卡组织自有清算 + 成员行 settlement 授权实时、清算 T+1～T+2 1%～3% MDR + 跨境附加费 0.6%～1.2%
钱包/账户类 Wise、PayPal、Airwallex、PingPong、连连、Payoneer、Revolut 私有 API + 本地清算接入 多币种池子 + 本地备付金账户 实时～数小时 0.35%～2% FX + 极低固定费

三条链路在底层并不互斥：Wise 的一笔本地不通的汇款最终也可能回落到代理行；Visa 做跨境收单，资金最后也要进入代理行；Airwallex 的本地账户背后是在 HSBC、Citi 等代理行开的 Nostro。

1.3 一笔汇款涉及的几种费

为了让后文讨论扣费有共同语言，先把跨境支付里能出现的费种一次列清：

费种 收费方 典型金额 何时扣
电汇手续费（Wire Fee） 汇款行 15–50 USD 发起时
中转行扣费（Lifting Charge） 每个中转行 5–30 USD/家 过账时从本金截留
收款行手续费 收款行 0–15 USD 入账时
FX 点差 换汇方 交易金额 0.5%–3% 换汇瞬间嵌入汇率
跨境附加费（Cross-border Assessment） 卡组织 0.6%–1.2% 每笔授权
平台佣金 Amazon/Shopee 等 8%–15% 订单成交
提现费 第三方支付 0–0.3% 提现到银行时
监管报送成本 持牌机构 摊入整体费率 持续

工程产品设计里一个非常常见的错误：只展示”汇款手续费”。用户看到 “15 USD fee”，却在到账时发现少了 80 USD，就会投诉。透明度是工程+产品的共同责任：把上面的每一项拆开，或者合并成单一 “Total Cost to Recipient” 指标。

1.4 持牌角色速查

缩写 全称 代表国家 能做什么
MSB Money Services Business 美国 汇款、兑换、预付卡（FinCEN 注册）
MTL Money Transmitter License 美国各州 跨州汇款（各州独立发）
EMI Electronic Money Institution 欧盟、英国 发行电子货币、提供支付账户
PI Payment Institution 欧盟 支付服务（不可发行电子货币）
PSP Payment Service Provider 全球 笼统称呼
MPI/SPI Major/Standard Payment Institution 新加坡 MAS PS Act 下的牌照
SVF Stored Value Facility 香港 多用途储值卡/钱包（HKMA）
支付业务许可证 —— 中国 央行发放，分为预付卡、网络支付、银行卡收单等

Wise 的全球合规体系，公开资料显示其至少持有：英国 EMI、美国 40+ 州 MTL、澳洲 AFSL、新加坡 MPI、加拿大 MSB、日本第二种资金移动业、香港 MSO 等几十张牌照。这就是跨境支付的”合规税”。

二、Nostro / Vostro / Loro：资金账户是怎么记的

2.1 三个词其实是同一个账户的三种视角

在跨境语境下，你会反复看到 Nostro、Vostro、Loro 三个意大利词。它们描述的是同一类账户——代理行互相给对方开的账户——只是看账人不同。

术语 字面意思 视角 例子
Nostro our（我们的） 我方银行看”我在你那里的账户” 中行在花旗纽约开的 USD 账户，中行账上叫 Nostro
Vostro your（你们的） 我方银行看”你在我这里开的账户” 花旗纽约看自己账上的那个中行账户，叫 Vostro
Loro their（他们的） 第三方视角：“他们在另一家的账户” 较少单独使用

关键：同一笔美元，在中行账上记为 Nostro 资产（“我在花旗有 1 亿 USD”），在花旗账上记为 Vostro 负债（“我欠中行 1 亿 USD”）。这是典型的镜像复式记账。

2.2 一笔代理行汇款的记账流

看一笔具体例子：纽约的 Alice 通过 JPM 汇 10,000 USD 给深圳的 Bob（中行账户）。假设 JPM 与中行有直接代理行关系：JPM 在中行开了 USD Vostro 账户（中行视角的 Nostro 就是中行在 JPM 开的 USD 账户）。

# JPM 账本（简化）
Dr  Alice 活期存款        10,000  # 扣 Alice
Cr  Nostro@CitiNY (USD)   10,000  # JPM 用它在 Citi 的 USD Nostro 对外支付
# 如果这笔是通过 Fedwire 直接走 JPM→BOC US 分行：
Dr  Alice 活期存款        10,000
Cr  应付 BOC US 分行      10,000  # Fedwire 清算

# BOC 美国分行账本
Dr  应收 JPM              10,000
Cr  应付总行（Head Office）10,000

# BOC 总行账本（深圳）
Dr  Nostro@BOC US (USD)   10,000  # 美元资产在美国分行
Cr  Bob USD 活期（或人民币结汇后）  约 72,000 CNY
# 若即时结汇：再做一笔 FX 分录

要把这个流程写到代码里，最容易踩的坑是：Nostro 账户余额是 T+N 到账的，而客户的 USD 账户是 T+0 记账的。这意味着银行内部在客户账上先记了钱，但 Nostro 实际余额要等清算网络结算完才到。于是需要一个”在途（In Transit）“科目：

-- 中行核心账户表（示例）
CREATE TABLE ledger_entries (
  entry_id       BIGINT PRIMARY KEY,
  txn_id         VARCHAR(64),
  account_id     VARCHAR(64),
  account_type   ENUM('CUSTOMER','NOSTRO','VOSTRO','IN_TRANSIT','FX_POSITION','FEE'),
  currency       CHAR(3),
  amount         DECIMAL(22,4),
  direction      ENUM('DR','CR'),
  value_date     DATE,       -- 价值日（资金真正到账日）
  booking_date   DATE,       -- 记账日
  status         ENUM('PENDING','SETTLED','REVERSED'),
  created_at     TIMESTAMP
);

每笔跨境入账都至少跨两个”日期”概念：booking date（记账日）与 value date（价值日）。这两个日期的错位就是”T+N”这三个字在账务系统里的落脚点。

为了更直观，把这笔分录用一张”穿过三家银行的账本”可视化：

sequenceDiagram
    autonumber
    participant Alice
    participant JPM as JPMorgan<br/>(汇款行)
    participant Fedwire
    participant BOCUS as BOC US Branch<br/>(美国分行)
    participant BOCHO as BOC HO<br/>(总行)
    participant Bob
    Alice->>JPM: 发起汇款 10,000 USD
    JPM->>JPM: Dr 客户存款 / Cr 应付清算 10,000
    JPM->>Fedwire: Fedwire 指令 10,000 USD → BOC US
    Fedwire->>BOCUS: 资金结算到 BOC US 储备账户
    BOCUS->>BOCHO: 内部划转：增加对总行的应付
    BOCHO->>BOCHO: Dr Nostro@NY 10,000 USD / Cr Bob USD 账户
    BOCHO->>Bob: 通知到账

这张图把”资金链”和”记账链”画在一条时间线上：资金通过 Fedwire 真实流转，账务在每一跳都产生镜像分录。

2.3 Nostro 余额管理：一个独立的工程问题

Nostro 管理在大型跨境银行里是一个专门岗位：Nostro Reconciliation Team。他们每天要干的事：

  1. 从 SWIFT 拉 MT940（日结账单）、MT950（对账单）、MT942（日内动态）；
  2. 与本行内部账上的 Nostro 镜像分录逐笔对账；
  3. 处理未匹配项：预付（银行先记了客户钱但 Nostro 没进）、预收（Nostro 进了但没找到客户）、金额不符、币种错配；
  4. 调仓：如果某个币种的 Nostro 余额过高（机会成本高）或过低（付不出款），要通过 FX Swap 或同业拆借调节。
# 简化的 Nostro 对账核心
def reconcile_nostro(internal_entries, swift_mt940_lines):
    # key = (value_date, amount, currency, ref)
    internal_map = {(e.value_date, e.amount, e.ccy, e.ref): e for e in internal_entries}
    unmatched_external = []
    for line in swift_mt940_lines:
        k = (line.value_date, line.amount, line.ccy, line.ref)
        if k in internal_map:
            internal_map[k].status = 'MATCHED'
        else:
            # 尝试模糊匹配：金额容差、日期 ±1、ref 子串
            m = fuzzy_match(line, internal_map)
            if m: m.status = 'FUZZY_MATCHED'
            else: unmatched_external.append(line)
    unmatched_internal = [e for e in internal_entries if e.status != 'MATCHED']
    return unmatched_internal, unmatched_external

这套逻辑看似简单，现实中会被以下因素打乱：

三、SWIFT MT103 的黑盒与 SWIFT gpi 的工程解法

3.1 MT103 到底长什么样

MT103 是”单笔客户汇款”的 SWIFT 报文，核心字段：

{1:F01ABCDUS33AXXX0000000000}
{2:I103EFGHSGSGXXXXN}
{3:{108:MYREFERENCE001}}
{4:
:20:TXN20260422001                     <- 发送方参考号
:23B:CRED                              <- 银行业务码
:32A:260422USD10000,00                 <- 价值日 + 币种 + 金额
:33B:USD10000,00                       <- 指示金额
:50K:/1234567890
ALICE SMITH
123 MAIN ST NEW YORK NY 10001 US
:52A:ABCDUS33                          <- 下单行 BIC
:53A:CITIUS33                          <- 付款行（Nostro 代理行）
:57A:HSBCSGSG                          <- 收款行
:59:/SG1234567890
BOB TAN
456 ORCHARD ROAD SINGAPORE
:70:/INV/20260422-998/                 <- 汇款备注
:71A:SHA                               <- 费用承担：OUR/BEN/SHA
-}

几个必考字段：

3.2 SWIFT gpi 解决了什么

SWIFT gpi（Global Payments Innovation，2017 年推出）不是一个新网络，而是在 MT103 上附加了一个 UETR（Unique End-to-end Transaction Reference）和一套成员行 SLA。关键工程改进：

  1. UETR（36 位 UUID v4） 随报文穿透所有中转行，任何一跳都能用 UETR 查”钱到哪一步了”；
  2. Tracker API：汇款行可通过 SWIFT Tracker 查询中间行的状态、扣费、到账时间；
  3. SLA：gpi 成员承诺同日到账（跨时区下实际是 24 小时内），扣费透明；
  4. gCCT / gCOV / gSRP：客户汇款、机构头寸划转、追加/退汇流程标准化；
  5. gpi Instant：接入本地实时支付网络后可做到”秒级到账”。

2023 年 SWIFT 数据：gpi 覆盖 150+ 币种走廊，50% 以上的 gpi 汇款在 30 分钟内到账，基本解决了”黑盒”问题——只是它不降低费用，降费是钱包类玩家（Wise/Airwallex）的事。

3.3 MT → ISO 20022 迁移

2025–2027 年全球在做 MT 到 ISO 20022 的切换。MT103 对应 pacs.008（FI to FI Customer Credit Transfer）。pacs.008 是 XML，字段更丰富、编码是 UTF-8（终于支持中文地址！）、汇款目的编码标准化（Purpose Code，如 GDDS 商品买卖、SALA 工资）。工程影响：

四、外汇（FX）工程

FX 是跨境支付里技术含量最高、也最容易让业务亏钱的环节。

4.0 一组基本事实

这几条事实解释了为什么”USD 中间跳”是常态，为什么”某些长尾走廊手续费要 5% 起”。

4.1 基础概念

4.2 报价引擎的工程架构

一个钱包类玩家的 FX 报价引擎长这样：

flowchart TB
    LP1[LP: Citi Velocity] --> Agg[聚合报价]
    LP2[LP: XTX Markets]  --> Agg
    LP3[LP: Goldman MarketHub] --> Agg
    LP4[LP: 本地银行 LP] --> Agg
    Agg --> Rule[分发策略<br/>加点差、限额、风控]
    Rule --> Cache[报价缓存<br/>30s~5min TTL]
    Cache --> API[对外 GetRate / Quote API]
    API --> LockStore[(Rate Lock 存储<br/>quote_id, expiry)]
    Order[客户下单] --> LockStore
    LockStore --> Hedge[对冲执行<br/>向 LP 反向平盘]

核心设计点：

  1. Quote（报价）与 Lock（锁定）分离：先给一个用户可看的 quote，用户点”确认换汇”那一刻才生成 quote_id 锁住汇率；锁定时长是风险，典型 30 秒 ～ 数分钟。
  2. 对冲（Hedging）：客户锁定之后，钱包在 LP 反向成交相同金额，把汇率风险转嫁。没来得及对冲 = 敞口（Open Position），行情跳动会直接吃利润。
  3. 跨币种路径（Cross Pair）：USD/VND 市场深度差，工程上走 USD→SGD→VND 两段来拼；每段都有点差。
  4. 流动性层级：活跃时段 LP 报价紧、点差小；节假日/亚洲深夜，点差会显著扩大。

4.3 汇率锁定与再报价

从产品视角看，“锁汇”有几种形态：

形态 时长 风险承担方 典型场景
Quote（即时询价） 几秒 ～ 1 分钟 无锁定，报完即过期 展示页
Rate Lock（短锁） 30 秒 ～ 5 分钟 钱包承担 用户点”确认换汇”
Guaranteed Rate 数小时 ～ 24 小时 钱包承担（需购买期权/远期对冲） Wise 的”锁定汇率 48 小时”功能
Forward Contract 数天 ～ 12 个月 双方锁 B2B 财资、企业海外采购

Wise 的官方文档披露：Guaranteed Rate 不是免费的，背后是 Wise 用远期合约对冲成本，多出的成本嵌入到显性手续费里。

4.4 FX 提供方比较

类型 代表 特点
Tier-1 银行 JPM、Citi、HSBC、Goldman 深度好、走廊多；点差中等；API 需白名单
非银 LP XTX、Jump、Virtu 算法做市、主流货币对点差极小（<0.5 pip）；长尾币种差
本地 LP 越南本地银行、印尼 Bank Mandiri 本地深度好、合规入口；跨境接入贵
P2P 撮合 Wise（内部）、Remitly（部分） 同一条走廊两端客户互补，走本地收本地付，不跨境搬钱
中介钱包 Revolut、Airwallex 聚合前三类，面向零售与 SMB

4.5 多币种账户 vs 换汇 vs 合约

这是 B2B 跨境产品经理必须理解的三条路径：

4.6 报价引擎的代码轮廓

核心 API 三件套：/fx/rate（询价）、/fx/quote（锁价）、/fx/execute（执行）。

# 询价（无锁）
GET /fx/rate?from=USD&to=CNY&amount=10000
-> {"mid": 7.2015, "bid": 7.1900, "ask": 7.2130, "ts": "2026-04-22T08:15:00Z"}

# 锁价（生成 quote_id）
POST /fx/quote
{"from": "USD", "to": "CNY", "amount": 10000, "side": "SELL_USD"}
-> {"quote_id": "Q-20260422-abc", "rate": 7.2030, "expires_at": "...+60s"}

# 执行（凭 quote_id）
POST /fx/execute
{"quote_id": "Q-20260422-abc", "settlement_date": "2026-04-24"}
-> {"deal_id": "D-...", "bought": 72030.00 CNY, "sold": 10000.00 USD}

服务内部要做的事：

  1. 校验 quote_id 存在、未过期、未被使用（幂等）；
  2. 从 Rate Lock 存储里拿出锁定汇率（Redis + 持久化 WAL）；
  3. 向对冲队列投递一笔反向订单（执行层可异步，但要在风控允许的敞口窗口内成交）；
  4. 记账：客户账户 DR USD / CR CNY；FX 头寸账 CR USD / DR CNY；
  5. 返回成交回执。

生产系统还要处理：撤销未执行的 quote 释放风控敞口、批量锁汇（Bulk Quote，多笔组合询价）、Streaming Rate（对高频客户开 WebSocket 推流报价）。

五、实时跨境：稳定币、CBDC、互联实时支付

代理行链路是”慢而贵”的代名词。2020 年以后三股力量在同时尝试”让跨境变快变便宜”。

5.1 稳定币跨境

USDC / USDT / PYUSD / EURC 等美元稳定币已经事实上承担了一部分跨境支付职能，尤其在 B2B、加密原生、新兴市场外汇管制国家的灰色/白色使用。工程上的结构：

flowchart LR
    Payer[付款方<br/>US USD] -->|1.入金| Minter[发行商<br/>Circle/Tether]
    Minter -->|2.铸造 USDC| Wallet1[付款方链上钱包]
    Wallet1 -->|3.链上转账<br/>Ethereum/Solana/Tron| Wallet2[收款方链上钱包]
    Wallet2 -->|4.赎回| Local[本地兑换商/OTC]
    Local -->|5.本地币种到账| Receiver[收款方<br/>NG NGN]

工程上的关键点：

5.2 CBDC 跨境：mBridge、Dunbar、Agorá

工程上 CBDC 跨境要解决的核心问题：PvP（Payment vs Payment）原子性——同一个 DLT 平台上，两种 CBDC 的换手通过智能合约一次性原子交付，避免 Herstatt 风险（一方已付另一方未付）。

不建新网络，把各国已有的实时支付系统互联：

对工程侧意味着：跨境不再是 MT103 三天，而是 20 秒，但可控的仅限 C2C 小额、多限额限币种。

六、合规：AML、制裁、FATCA/CRS 的工程落地

6.1 AML 与制裁筛查嵌在哪里

一笔跨境汇款在工程管线上至少要过四道合规关卡：

flowchart TB
    Init[客户发起] --> KYC{KYC 已完成?}
    KYC -->|否| Reject1[拒绝/补录]
    KYC -->|是| Sanction1[付款方<br/>制裁筛查]
    Sanction1 -->|命中| Hold1[冻结/上报 SAR]
    Sanction1 -->|未命中| AML[AML 交易监测<br/>规则 + 模型]
    AML -->|可疑| Hold2[冻结/上报]
    AML -->|通过| Sanction2[收款方<br/>制裁筛查]
    Sanction2 -->|命中| Hold3[冻结]
    Sanction2 -->|未命中| Send[SWIFT/本地发送]
    Send --> Inbound[中转行再筛]

制裁名单来源至少包括：

名单 发布方 刷新频率 覆盖
SDN（Specially Designated Nationals） 美国 OFAC 每日 被美国制裁的个人/实体
UN Consolidated List 联合国 不定期 联合国安理会决议
EU Consolidated List 欧盟 每日 欧盟制裁
HMT 英国 每日 英国金融制裁
央行通知 各国央行/外管局 不定期 本国特殊要求

工程实现要点：

6.2 SWIFT 制裁

SWIFT 本身不是监管机构，但它的”制裁”最具杀伤力——2022 年部分俄罗斯银行被 SWIFT 断开，意味着这些银行无法收发国际汇款报文，尽管它们账上的 Nostro 还在。工程上，SWIFT 断连等同于”账户存在但无法指挥资金”。

6.3 FATCA 与 CRS

对跨境支付工程的直接影响：

6.4 Travel Rule（FATF R.16）

FATF 建议 16 要求：当一笔汇款超过阈值（通常 1000 USD/EUR）时，发起机构必须把付款方与收款方的完整信息一并传递给收款机构。对 SWIFT 电汇这是天然满足的（MT103 字段已包含），但对虚拟资产服务提供商（VASP）（交易所、钱包商）同样适用，2019 年起 FATF 将其扩展至加密货币。

工程落地：

六·续、制裁与 AML 的落地细节

def sanctions_screen(party: Party) -> ScreenResult:
    hits = []
    # 1. 精确匹配：护照号/身份证/BIC
    if exact_match(party.id_number, sdn_index_id):
        hits.append(Hit('ID_EXACT', score=1.0))
    # 2. 模糊匹配姓名 + DOB + 国籍
    for cand in fuzzy_name_search(party.name, threshold=0.85):
        score = combine(
            jaro_winkler(party.name, cand.name),
            dob_match(party.dob, cand.dob),
            country_match(party.country, cand.countries),
        )
        if score > 0.92:
            hits.append(Hit('NAME_FUZZY', score=score, ref=cand.id))
    # 3. 地址关键词（如"Crimea", "North Korea"）
    if any(kw in party.address.upper() for kw in SANCTION_GEO_KEYWORDS):
        hits.append(Hit('GEO_KEYWORD', score=0.7))
    return ScreenResult(hits=hits, decision=decide(hits))

工程上最重要的是决策矩阵（Hit → 自动放行 / 转人工 / 自动冻结），而不是模型本身。一张典型的决策矩阵：

最高 Hit 分数 Hit 类型 金额阈值 客户等级 决策
≥ 0.98 ID 精确 任意 任意 自动冻结 + 立即上报
0.92–0.98 姓名 + DOB + 国籍 任意 任意 转人工复核（4 小时 SLA）
0.85–0.92 姓名模糊 < 1000 USD 老客户 自动放行 + 日志
0.85–0.92 姓名模糊 ≥ 1000 USD 或新客户 任意 转人工复核
< 0.85 —— —— —— 自动放行

真实系统的矩阵会有几十列条件，往往由合规官逐条签署，受审计严格约束。更新矩阵必须走变更审批 + 影子测试 + 审计日志，不能像改业务代码一样随意发布。

6.5 在哪里放合规检查（架构层面）

工程上一个反复出现的讨论：制裁筛查、AML 规则放在哪一层？几种常见布局：

大型银行通常采用第四种。工程上要特别留意筛查系统的可用性是支付的硬依赖——筛查挂了就不能发支付，设计时要有降级策略（如”离线名单快照 + 事后回补”），并接受降级期间假阴性的合规风险。

七、中国跨境支付工程拆解

7.1 四条主干道

场景 主要通道 持牌/监管
企业大额贸易/投资 银行电汇（SWIFT + 代理行）、CIPS 外管局、人民银行
个人小额汇款 银联国际、Wise/Remitly 等境外钱包（通过本地银行入金）、境外华人银行电汇 外管局年度 5 万美元便利化额度
跨境收款（出海卖家） 第三方持牌机构：连连、PingPong、Airwallex、万里汇（WorldFirst）、空中云汇 央行支付业务许可证（跨境外汇支付试点）
数字人民币跨境 mBridge、港澳版 e-CNY、试点走廊 人民银行数研所

7.2 CIPS（人民币跨境支付系统）

CIPS 是人民银行于 2015 年推出的人民币跨境清算基础设施，目的是不依赖 SWIFT + 代理行完成 CNY 的跨境清算：

工程意义：CNY 跨境不必穿越美元中转，中国银行直接在 CIPS 上与新加坡银行对汇人民币。2023 年底 CIPS 直接参与者约 140 家，间接参与者 1300+，覆盖 110+ 国家。

7.3 出海电商：一笔美元收款的全链路

这是本文最核心的一张图。场景：深圳卖家在 Amazon US 站收到一笔 100 USD 的订单货款，最终希望变成人民币落到自己境内对公账户。

flowchart TB
    Buyer[美国买家] -->|1. 刷 Visa| AmazonPay[Amazon Pay<br/>收单]
    AmazonPay -->|2. 卡组织清算| Visa[(Visa BASE II)]
    Visa -->|3. T+1 结算| AmazonAcq[Amazon 收单行<br/>JPMorgan Chase]
    AmazonAcq -->|4. Amazon 平台结算<br/>扣佣金/广告费| SellerVA[卖家虚拟账户<br/>@Amazon]
    SellerVA -->|5. 提现指令| PP[第三方跨境支付<br/>PingPong/连连/Airwallex]
    PP -->|6. 本地收款<br/>美国 ACH/Wire| PPUS[PP 在美国<br/>合作银行 USD 账户]
    PPUS -->|7. 内部记账| PPCN[PP 在香港/境内<br/>USD 备付金账户]
    PPCN -->|8. 跨境汇入<br/>SWIFT MT103| SellerBankUSD[卖家境内银行<br/>USD 账户]
    SellerBankUSD -->|9. 结汇<br/>FX Spot| SellerBankCNY[卖家境内银行<br/>CNY 账户]
    SellerBankCNY -.->|10. SAFE 申报<br/>货物贸易真实性| SAFE[国家外汇管理局]

每一跳的工程要点：

  1. 收单（1–3 步）：卡组织跨境收单，商户 MDR 中包含跨境附加费（~1%）；
  2. 平台结算（4 步）：Amazon 扣佣金、广告、FBA 费用之后剩余余额进入虚拟账户；
  3. 提现到第三方（5–7 步）：Amazon 直接打款到 PingPong 在美国的合作银行美元账户。关键：这里仍是境内美国的 ACH 或 Wire，没有”跨境”发生；然后 PingPong 在自己体系内把这笔钱”归集”到可结汇的池子；
  4. 真正的跨境（8 步）：从美国打到卖家境内银行美元账户，一般通过代理行 SWIFT MT103；部分第三方用“本地收本地付”策略（7’ 本地池子内部抵消 + 境内人民币池对付），把这步避开；
  5. 结汇与 SAFE 申报（9–10 步）：卖家拿到 USD 后选择自己结汇，需提交出口报关单/物流单据，走货物贸易外汇管理真实性审核。

7.4 SAFE 的关键规则（工程层关心什么）

7.5 一条踩坑轶事：真实性审核

2022 年一批深圳跨境电商遇到的问题：第三方账户里累积了大量小额 USD 收款，在结汇时因为对应不到报关单而被 SAFE 质询。原因是 Amazon 的订单是 C2C 小包直邮，不走正规报关单（9610 / 9710 模式需要第三方打包报送）。解决方案是走跨境电商综合试验区的 9610（一般出口）、9710（企业对企业）、9810（海外仓出口）专用监管代码，由支付机构按批次向 SAFE 推送订单与物流数据。

工程上这意味着第三方支付要和关务平台、物流数据打通，把订单维度的 order_id → tracking_no → export_customs_no → payment_txn 建立端到端链路。

7.6 人民币跨境的三条路径

企业做跨境收付款时，用 CNY 还是 USD，是一个结构性选择：

  1. CNY 跨境结算（CNY Offshore / CNH）：境内企业开人民币账户，通过 CIPS 直接对境外（主要是香港、新加坡、伦敦、法兰克福、迪拜）结算 CNY/CNH。省掉一次美元中转的点差与费用，但要求交易对手愿意接受人民币。
  2. USD 电汇：走代理行，传统路线；境外成本最高，但覆盖最广。
  3. 自贸区 FT 账户（Free Trade Account）：上海、海南等自贸区允许设立 FT 账户，在账户内做本外币一体化管理，跨境资金流动按自贸区规则。面向大型企业、跨国集团财资中心。

7.7 跨境支付牌照与报送网络示意

flowchart LR
    Merchant[出海商户] -->|交易数据| PP[第三方支付机构]
    PP -->|客户备付金| CustAcc[央行集中存管]
    PP -->|外汇收付数据| SAFE[国家外汇管理局<br/>跨境监测平台]
    PP -->|AML 报送| PBOC[人民银行反洗钱局]
    PP -->|可疑交易报告| CAMLMAC[中国反洗钱监测<br/>分析中心]
    PP -->|税务信息交换| SAT[国家税务总局]

一家跨境第三方的持牌团队大约要同时对接六套以上监管报送系统（SAFE、PBOC、CAMLMAC、SAT、海关、外汇在线），每套都有独立接口与报送节奏。这往往是出海新玩家低估的部分。

八、资金沉淀与 T+N 工程

8.1 客户资金与自有资金必须隔离

跨境钱包/第三方支付机构的一条监管红线：客户资金不得与自有资金混同。工程表现：

-- 粗颗粒的资金账户分类
CREATE TABLE accounts (
  account_id   VARCHAR(32) PRIMARY KEY,
  holder_type  ENUM('CUSTOMER','COMPANY','PARTNER_BANK','REGULATOR'),
  purpose      ENUM('CUSTODY','OWN_OPERATING','FEE','FX_POSITION','SETTLEMENT'),
  currency     CHAR(3),
  bank_ref     VARCHAR(64),      -- 对应的银行账户号
  is_segregated TINYINT,          -- 是否客户隔离账户
  ...
);

8.2 T+N 沉淀的两面

九、真实案例：Wise / Airwallex / Stripe Atlas

9.1 Wise 的”本地收本地付”

Wise 的核心工程 insight：70% 以上的跨境汇款走廊存在双向流量。GBP→EUR 有需求，同时 EUR→GBP 也有需求。Wise 在每个主要国家开本地银行账户，把两边订单在内部撮合：

不平衡的部分（净敞口）Wise 走代理行/FX LP 平盘。公开资料显示 Wise 在 40+ 国家持有 70+ 本地银行账户关系，这是一个可复用的基础设施。

9.2 Airwallex 的 Global Account

Airwallex 的拳头产品”Global Account”允许企业在 60+ 国家开本地收款账号（SWIFT/BSB/SORT/IBAN）：

工程上最难的是全球本地账户的接入与合规——每进一个国家就要新牌照、新银行关系、新 ISO 20022 方言。

9.3 Stripe Atlas / Stripe Global

Stripe Atlas 不是支付本身，而是”一小时帮你开一家美国公司 + 银行账户 + Stripe 收单 + 法务合规”。从跨境工程视角：

这是一种”用美国实体绕开直连跨境”的打法，是独立站、SaaS 创业者最常用的组合。

9.4 一张横向对比表

维度 代理行 SWIFT Wise Airwallex 稳定币（USDC on Tron/Solana）
典型到账 T+1～T+3 秒～小时 秒～小时 秒（链上确认）
典型成本 15–50 USD + 隐性 FX 点差 0.35%–1% 显性 fee，mid-market 0.3%–1% + 本地收款免手续费 链手续费 <1 USD + 入/出金 0.1%–1%
FX 透明度 低（中转行扣费不透明） 高（官网公开 rate card） 高 高（链外兑换商报价）
合规 成熟 多国 EMI/MTL 多国 EMI/MTL/PI 入金/出金环节强监管
走廊覆盖 几乎所有币种 40+ 主要币种 60+ 国本地账户 任意链上钱包；法币出金受限
企业 API 繁琐（host-to-host、FIN Copy） 友好 REST 友好 REST + GraphQL Web3 SDK 为主
适合谁 银行、大额 B2B、不可替代走廊 个人、SMB、跨境工资 SMB、出海卖家、独立站 加密原生、外汇管制国家、OTC

没有哪条路是”最优解”，实战中经常是组合使用：同一家 SaaS 公司，北美收入走 Stripe → Mercury → Wise，东南亚走 Airwallex Global Account，与供应商跨境付走 SWIFT，与加密原生合作伙伴走 USDC。

十、工程踩坑清单

10.1 字符编码

SWIFT_X_SET = set("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/-?:(),.'+ {}")
def validate_swift_x(s: str, max_len: int) -> str:
    if len(s) > max_len:
        raise ValueError(f"Field too long: {len(s)}>{max_len}")
    for c in s:
        if c not in SWIFT_X_SET:
            raise ValueError(f"Illegal SWIFT-X char: {c!r}")
    return s

10.2 BIC 校验

import re
BIC_RE = re.compile(r'^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}(?:[A-Z0-9]{3})?$')

def validate_bic(bic: str, directory) -> bool:
    if not BIC_RE.match(bic):
        return False
    entry = directory.lookup(bic)
    return entry is not None and entry.status == 'ACTIVE' and 'CUST_CRED' in entry.services

10.3 Value Date vs Booking Date

前面提到过，这里再强调一次：跨境账务系统如果把两个日期混用，对账会爆炸。客户看到的”到账时间”要以 value date 为准，会计核算以 booking date 为准。

10.4 扣费模式 OUR/BEN/SHA

10.5 退汇（Return）流程

10.6 截止时间与时区

10.7 对手方风险（Settlement Risk / Herstatt Risk）

10.8 节假日与价值日计算

价值日（Value Date）不是简单的”T+2 日历日”，要跳过：

def value_date(trade_date, ccy_pair, n_days=2, calendars=None):
    d = trade_date
    for _ in range(n_days):
        d += timedelta(days=1)
        while is_weekend(d, ccy_pair) or any(cal.is_holiday(d) for cal in calendars):
            d += timedelta(days=1)
    return d

生产里通常会直接用 FinCal、Bloomberg CDR 等商用日历库，自己维护极易出错。

10.9 名称匹配与金额边界

10.10 二清与通道风险

境内场景：第三方支付若未持牌代理客户资金，属”二清”，央行 2017 年起严打；跨境场景同样存在变形：“某公司用个人账户集中收海外货款再分给卖家”，这是跨境二清典型形态，SAFE 与央行联合打击。

工程上的”红灯”指标：

十一、选型建议

面向不同业务形态的选型清单：

11.1 出海独立站/SaaS（单人或小团队）

11.2 跨境电商卖家（中国主体）

11.3 B2B 大额跨境（外贸制造业）

11.4 金融机构/持牌支付公司

11.5 交叉引用

跨境支付几乎与本系列所有前序章节相关，避免重复，这里只标注关键衔接：

十二、参考资料

十三、尾声：跨境支付未来五年的工程主题

把视角拉远，2026 年往后看五年，跨境支付工程的主要矛盾正在从”让单笔可达”转向”让可达的都高效且合规”。几条结构性趋势值得工程团队持续跟踪：

  1. ISO 20022 全面铺开：2025 年底 SWIFT 完成 MT 到 MX 切换共存期的大部分结构性工作；Purpose Code、结构化地址、LEI（Legal Entity Identifier）全面成为一等字段。工程侧要把自身账务系统从”字符串备注”往”结构化字段”迁移。
  2. 互联即时支付（IPS Interlink）成为小额走廊的主力：BIS Nexus 把五国以上 IPS 用单一路由互联，UPI-PayNow 式双边走廊数量翻番。代理行将继续存在但仅服务大额与长尾币种。
  3. 稳定币合法化与监管化：欧盟 MiCA 2024 年生效、香港 2025 年发牌、美国州层面已落地、联邦层面 GENIUS 类法案推进中。未来稳定币在合规披露、准备金审计、发行商白名单等方面会越来越像”数字美元货币基金”。
  4. CBDC 跨境从试点走向生产：mBridge 在亚太继续推进，Agorá 在欧美主要央行层面探索代币化结算。一旦真实跑量，PvP 原子结算将成为默认选项。
  5. AI 在合规中的广泛应用：制裁筛查的假阳性压缩、AML 的异常交易识别、KYC 文档识别与比对全面 LLM 化；监管沙盒的可解释性要求反过来成为工程难点——“为什么这个客户被 flag 了”必须能复现。
  6. “钱包即中间件”成形：Wise、Airwallex、Revolut、Nubank 等新兴玩家正把自身的”全球账户 + FX + 合规 + 报送”打包成 API，卖给其它 SaaS，让任何公司都能一键”变跨境”。

跨境支付的本质没变——它仍然是”在不同法律、不同币种、不同清算系统之间搬运价值”。只是工程上可以选的轮子多了，选错的代价也同样大：一次跨境退汇的处理成本，往往是境内退款的数十倍。

如果让我用一句话概括整篇文章的工程主张，那就是——把架构画清楚、把合规嵌进数据模型、把对账跑在关键路径、把汇率敞口量化可见。这四件事做好，跨境支付工程就不再是玄学，而是一门可以被教、被学、被工业化的手艺。

十四、一个最小可跑通的跨境支付骨架伪码

收尾放一段”麻雀虽小五脏俱全”的服务伪码，把前文的概念串起来，方便读者拿去启发自己系统的框架。

class CrossBorderPaymentService:
    def __init__(self, fx, sanctions, ledger, swift, router, safe):
        self.fx, self.sanctions, self.ledger = fx, sanctions, ledger
        self.swift, self.router, self.safe = swift, router, safe

    def send(self, req: PayRequest) -> PayResult:
        # 1. 基础校验：BIC、SWIFT-X 字符、地址长度、币种白名单
        validate_bic(req.beneficiary_bic, self.router.bic_dir)
        validate_swift_x(req.beneficiary_name, 35)
        validate_swift_x(req.beneficiary_addr, 35 * 4)

        # 2. 合规：双向制裁筛查 + AML 交易监测
        for party in (req.payer, req.beneficiary):
            r = self.sanctions.screen(party)
            if r.decision == 'BLOCK':
                raise SanctionHit(r)
        if self.sanctions.aml_check(req).suspicious:
            return PayResult.held('AML_REVIEW')

        # 3. 报价与锁汇（若跨币种）
        quote = None
        if req.send_ccy != req.recv_ccy:
            quote = self.fx.lock(req.send_ccy, req.recv_ccy,
                                 req.amount, side='SELL_' + req.send_ccy)

        # 4. 路由：选代理行 / 本地走廊 / 稳定币通道
        route = self.router.choose(req, quote)
        # route.kind ∈ {CORRESPONDENT, LOCAL_RAIL, STABLECOIN, IPS}

        # 5. 记账：客户 DR / 在途 CR / FX 头寸 / 费用
        entries = self.ledger.build_entries(req, quote, route)
        self.ledger.post(entries, value_date=route.value_date)

        # 6. 发送：MT103 / pacs.008 / 本地 API / 链上交易
        uetr = uuid4_hex()
        if route.kind == 'CORRESPONDENT':
            self.swift.send_mt103(req, route, uetr)
        elif route.kind == 'LOCAL_RAIL':
            route.rail.send(req)
        elif route.kind == 'STABLECOIN':
            route.chain.transfer(req, stable=route.stable_asset)
        elif route.kind == 'IPS':
            route.ips.send(req)

        # 7. SAFE / 监管报送（异步）
        if req.is_china_outbound_or_inbound():
            self.safe.report_async(req, route)

        return PayResult.sent(uetr=uetr, eta=route.eta, quote=quote)

    def on_gpi_tracker_update(self, event):
        # gpi Tracker 回调：更新状态、扣费明细、实际到账金额
        self.ledger.update_in_transit(event.uetr, event)
        if event.status == 'RJCT':
            self.ledger.reverse(event.uetr)

这段伪码被真正写进生产系统后，代码行数通常会膨胀 50 倍以上：每一步都会被合规评审、SLA 要求、错误路径、审计日志等需求进一步拉伸。但骨架仍然是这七步。记住它，你就有了一个”跨境支付工程师”的思维模板。

跨境支付工程是一门”工程能力 + 金融基础设施知识 + 合规敏感度”的综合学问。它不追求极致的低延迟、不追求极致的 TPS，却追求每一分钱都能在任何时刻说清楚它在哪、归谁、为什么、下一步去哪。当你回到自己的业务需求，无论是出海 SaaS 的月度订阅、跨境电商的每日打款、企业财资的全球归集、还是稳定币的链上链下互通，都可以用本文提供的参与方、账户、FX、合规、报送五层模型去对号入座。

下一篇我们将进入数字货币的世界——数字人民币、稳定币、CBDC。跨境支付讲到这里为止还是”账户 → 账户”的游戏；而到了数字货币，游戏的基本原语开始发生变化：从”账户”走向”代币”，从”中心化清算”走向”原子结算”，从”可对账”走向”可编程”。

从某种意义上说，第 14 篇是本篇的”另一种可能的未来”：当”价值”本身可以在链上以代币形式原子转移，本文花了大量篇幅描述的代理行、Nostro、MT103 都可能逐步被重写成智能合约调用。但在那之前，我们仍将和本文描述的这套”慢而稳”的基础设施共处很长时间。

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

下一篇：《数字人民币、稳定币与 CBDC：双层运营、离线支付、链上/链下清算》

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / fintech

金融科技工程

面向中国工程团队的金融科技系列。从账务底盘、支付、清结算、交易所、风控合规到可靠性与灾备，中国与全球视角并举，讲清楚金融系统在工程落地中的真实挑战。

By .