引子

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

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

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

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

• 参与方多：汇款行 → 汇款行的代理行 → 中转行（可能 1～3 家）→ 收款行的代理行 → 收款行；每一跳都会扣费、截留、延迟；
• 币种多：一笔 USD→VND 可能经过 USD→EUR→VND 或 USD→SGD→VND 的隐性换汇；
• 合规多：汇款行要做 AML、中转行要做制裁筛查、收款行要做 FATCA/CRS，任何一方发现可疑就会”截留”资金，资金可能在某个中转行冻结几周；
• 标准多：SWIFT MT（MT103、MT202）、ISO 20022（pacs.008）、卡组织协议（Visa BASE II、Mastercard GCMS）、本地清算协议（CIPS、CHAPS、SEPA）；
• 参与角色多：银行、卡组织、钱包、持牌 MSB/PI/EMI、稳定币发行商、CBDC 桥。

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

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

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

• 报文走 SWIFT，资金走本地清算系统。SWIFT 本身不搬钱，它只搬”指令”；真正的钱在每一跳通过该国/该币种的 RTGS 或代理行间的轧差账户完成交割。
• 中转行的数量不是固定的：如果汇款行在收款币种上没有直接的代理行关系，就要”多跳”；热门走廊（US→UK、US→HK、EU→CN）通常 1～2 跳，冷门走廊（US→某非洲国家小币种）可能 3～4 跳。
• 每一跳都是一个独立结算：前一跳的资金到账后，中转行才向下一跳发 MT103，这就是为什么”3 天到账”是常态。

1.2 三大主链路一览

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

1.3 一笔汇款涉及的几种费

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

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

1.4 持牌角色速查

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

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

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

关键：同一笔美元，在中行账上记为 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

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

• 截留扣费：中转行从本金里扣了 15 USD，金额就不等了；
• 批量合并：中转行把当日多笔合并打一笔进来（netting），根本无法按笔对应；
• 时区：美东 T 日的发送对中国就是 T+1 凌晨；
• 字符集：SWIFT 的参考号 32 字符限制，本行的 64 位 UUID 只能截断。

三、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
-}

几个必考字段：

• :71A: 费用码：OUR（汇款人全付）、BEN（收款人全付）、SHA（共担，默认值）。SHA 是跨境扣费不透明的罪魁：汇款行收了自己那部分，中转行可从本金里扣，收款人收到多少要看天意。
• :50K: / :59: 地址字段每行 35 字符上限，中文地址必须转拼音或英文；
• :70: 备注字段 4×35 字符，多一个字就被截；
• 所有文本必须是 SWIFT-X 字符集：A-Z 0-9 / - ? : ( ) . , ' + { } CR LF SPACE，没有小写字母、没有 @ # $ & *、没有非 ASCII。

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 工资）。工程影响：

• 原来 35 字符的地址限制不再硬卡，但代理行之间 SLA 可能还保留 structured address 要求；
• 汇款用途不再靠备注 :70: 里塞，可用 <Purp><Cd> 结构化字段；
• 附加数据（如合规信息、原始付款方）可以在 <RmtInf> / <UltmtDbtr> 里规范承载；
• SWIFT 提供 MT/MX 互译网关，但有损失性字段问题：MT→MX 再 MX→MT 可能丢字段。

四、外汇（FX）工程

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

4.0 一组基本事实

• 全球 FX 日交易量约 7.5 万亿美元（BIS 2022 Triennial Survey），远超全球股票与债券总和；
• 其中 Spot（即期）只占约 30%，其余是远期、掉期、期权、NDF；
• 前十大货币占 90%+ 交易量；USD 出现在 88% 的交易里（一种货币对必须包含 USD 的概率）；
• 非流动性币种（如 NGN 奈拉、VND 越南盾、UZS 乌兹别克索姆）市场深度差、点差宽、节假日报价时有时无。

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

4.1 基础概念

• Bid / Ask / Mid：银行报的卖出价 Ask > 买入价 Bid，两者之差是点差（Spread）；中间价 Mid = (Bid + Ask) / 2。对客户而言，换汇永远是”买 Ask、卖 Bid”。
• Mid-market rate：路透、彭博、Google 上显示的汇率一般是中间价，不是客户可以实际换到的价。Wise 主打”按 mid-market 换汇，透明手续费”，核心工程就是不从点差里赚钱而是收一笔显式 fee。
• Pip：最小波动单位；主流货币对是小数点后第 4 位，日元对则是第 2 位。
• T+0 / T+2 交割：现汇（Spot）标准是 T+2；同日交割（Same-day）贵一点；远期合约（Forward）T+N 周/月。

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 汇率锁定与再报价

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

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

4.4 FX 提供方比较

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

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

• 多币种账户（Multi-currency Account）：企业在一家钱包里持有 20 种币种的虚拟账户，收进来什么币存什么币，不强制结汇。适合：出海卖家被动收款、灵活付款供应商。
• 即期换汇（Spot FX）：收到立刻按 T+0/T+2 换成本币。适合：现金流压力大、不需要持外币。
• 远期合约（Forward）：锁定未来某日的汇率。适合：未来有已知外汇应付/应收（例如未来 6 个月每月需要支付 100 万美元采购款）。

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]

工程上的关键点：

• 链的选择：Tron（费用极低、拥堵少、南美/东南亚 OTC 主流）、Solana（快、费用低）、Ethereum L2（如 Base、Arbitrum）、Polygon；链决定了手续费、到账速度与兼容钱包生态；
• 合规边界：链上转账本身不受单国央行控制，但入金和出金（fiat on/off ramp）是受牌照监管的环节——这也是 Circle、Coinbase、Binance 的主业；
• 价格稳定：USDC 由 Circle 1:1 储备、月度审计；USDT 的储备构成曾多次争议；对跨境工程而言，“稳”是业务前提；
• Visa 的稳定币试点：2023 年起 Visa 联合 Circle、Worldpay、Nuvei 试点用 USDC 作为 Visa 结算清算资金（Solana、Ethereum），把传统 T+1 结算缩短到分钟级。

5.2 CBDC 跨境：mBridge、Dunbar、Agorá

• Project mBridge（BIS + 中国人民银行数字货币研究所 + 香港金管局 + 泰国央行 + 阿联酋央行）：基于 DLT 的多币种 CBDC 跨境结算平台，2022 年真实场景测试，2024 年 BIS 退出后由中方与港泰等继续推进；
• Project Dunbar（BIS + 新加坡 MAS + 澳央行 + 南非 + 马来央行）：多 CBDC 共用平台的可行性研究，2022 年结束；
• Project Agorá（BIS + 七大央行：Fed、ECB、BOJ、BOE、BOF、SNB、BOK）：2024 年启动，探索代币化商业银行货币 + CBDC在跨境中的统一结算层。

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

5.3 互联实时支付（IPS Interlink）

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

• UPI ↔︎ PayNow（印度-新加坡，2023 上线）：两国零售实时支付直连；
• PIX ↔︎ 其他系统（巴西央行积极推进国际化）；
• BIS Nexus 项目：把 5+ 国家 IPS（如印度 UPI、新加坡 PayNow、马来西亚 DuitNow、泰国 PromptPay、菲律宾 InstaPay）接到一个中央路由，一次对接通所有。

对工程侧意味着：跨境不再是 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[中转行再筛]

制裁名单来源至少包括：

工程实现要点：

• 模糊匹配：姓名/地址有拼写变体，要用 Soundex、Jaro-Winkler、Elasticsearch 的 fuzzy + N-gram；
• 假阳性控制：“Mohammed”、“Wang Wei” 等高频名字每天命中几百万次，一定要做分数阈值、辅助字段（DOB、国籍、护照号）缩小；
• 名单更新：SDN 有 XML/CSV/JSON 格式增量；每次更新要 rerun 存量客户筛查（batch screening）；
• 审计链：每笔筛查的命中结果、分数、人工处置、决策人要存 7～10 年。

6.2 SWIFT 制裁

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

6.3 FATCA 与 CRS

• FATCA（Foreign Account Tax Compliance Act，美国 2010）：美国要求全球金融机构申报美国纳税人账户，否则对其美元收入 30% 预扣税；
• CRS（Common Reporting Standard，OECD 2014）：FATCA 的多边版本，100+ 国家互换税务居民的金融账户信息。

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

• 开户时必须收集税务居民信息（TIN）；
• 账户年底生成报告上报本地税局；
• 系统要有”美国人判定”（US indicia，例如美国出生地、美国地址、美国电话等 7 项）的自动化规则。

6.4 Travel Rule（FATF R.16）

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

工程落地：

• 每笔 VASP 间转账要附带 Originator 与 Beneficiary 信息；
• 行业联盟提出多种标准：TRUST（美国联盟）、OpenVASP、Sygna Bridge、Notabene、Veriscope；
• 稳定币链上转账原生不带这些信息，必须通过链下 API 通道补齐，工程上就是”链上+链下双通道同步”。

六·续、制裁与 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 → 自动放行 / 转人工 / 自动冻结），而不是模型本身。一张典型的决策矩阵：

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

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

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

• 网关前置：所有进入支付核心的请求先过筛查；优点简单，缺点是重复筛（同一客户一天上百笔都会重复调）；
• 核心系统内嵌：在创建支付单的事务里同步调用；优点口径一致，缺点是延迟敏感；
• 事件驱动异步：支付单先落地为 PENDING_SCREENING，筛查结果异步回写；优点解耦，缺点要处理”资金已扣客户但未发送”的中间态；
• 混合：客户首次开户 + 年度周期全量筛查 + 每笔事件触发差量筛查。

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

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

7.1 四条主干道

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

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

• 报文：自研 CIPS 报文标准，兼容 ISO 20022，字段和 pacs.008 高度一致；
• 成员分层：直接参与者（境内外银行直连 CIPS）、间接参与者（通过直接参与者接入）；
• 清算模式：RTGS 实时全额清算；
• 运行时间：5×24 小时（覆盖全球时区，跨境友好）；
• SWIFT 关系：CIPS 可以内嵌在 SWIFT 报文通道里（CIPS Connector），也可以走自有通道。

工程意义：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 的关键规则（工程层关心什么）

• 年度便利化额度 5 万美元（个人）；
• 货物贸易真实性三单匹配：报关单、物流单、资金单要对应（企业贸易项下）；
• 服务贸易：等额/单笔 5 万美元以下免单据，以上需合同+发票；
• 第三方支付机构跨境业务许可证：2013 年试点，限定”货物贸易、服务贸易”等项目，金额有上限，报告 SAFE；
• 申报接口：企业通过 ASOne（原国际收支申报系统）/银行接口报送；第三方机构有专用接口报送交易明细。

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 客户资金与自有资金必须隔离

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

• 在合作银行开客户备付金专户（中国：100% 央行集中存管；香港：SVF 要求信托或独立账户；欧盟：EMI 要求 safeguarding）；
• 账本上严格区分 customer_float 与 own_funds 两类账户；
• 备付金利息归属按牌照规定（中国集中存管后利息归央行 → 后改制为”利息补偿”）。

-- 粗颗粒的资金账户分类
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 沉淀的两面

• 商户视角：资金沉淀越短越好（现金流）；
• 机构视角：法定 T+N 沉淀期间，这笔钱在备付金账户里，不能拿来做自营交易（牌照禁止），但活期利息与存款吸引力是合法收益；
• 监管视角：沉淀期要透明、可追溯，不得”二清”（未持牌机构代持客户资金）。

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

9.1 Wise 的”本地收本地付”

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

• 用户 A 在英国向 Wise 的 GBP 本地账户打 1000 GBP；
• 用户 B 在德国向 Wise 的 EUR 本地账户打 1170 EUR（相当于另一笔 EUR→GBP）；
• Wise 内部撮合：A 的收款人收到 B 打进来的 EUR 里的 1170 EUR；B 的收款人收到 A 打进来的 GBP 里的 1000 GBP；
• 双方都感受到”到账秒级、费率低”，因为没有真实的跨境资金搬运发生。

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

9.2 Airwallex 的 Global Account

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

• 本质：Airwallex 在当地银行开一个”主账户”，客户在其系统里得到一个”虚拟账号”（VNA），底层通过 virtual IBAN / nested account 做隔离；
• 收款：客户的北美买家打到一个美国 ACH/Wire 路由号 + 子账号；
• 资金进入 Airwallex 多币种钱包，客户可以选择换汇、付款给供应商、提现到本国账户；
• 付款：可用 SWIFT、本地 RTGS、卡支付（Issuing）、甚至稳定币（部分币种）发出。

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

9.3 Stripe Atlas / Stripe Global

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

• Atlas 帮非美国创业者搞定 US Delaware LLC/C-Corp 注册、EIN、美国银行（Mercury 等）、Stripe 商户；
• Stripe 收单链路就此打通，全球电商客户的美元收入落入美国公司银行；
• 再通过 Wise、Airwallex、或 SWIFT 把 USD 汇回创业者所在国。

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

9.4 一张横向对比表

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

十、工程踩坑清单

10.1 字符编码

• SWIFT MT 只支持 SWIFT-X 字符集：A-Z 0-9 / - ? : ( ) . , ' + { } 空格；小写字母、中文、@#&* 都会被网关拒收；
• 中文地址/姓名必须英文或汉语拼音转写；
• ISO 20022 pacs.008 支持 UTF-8，但代理行之间的 SLA 可能仍然要求 ASCII 子集；
• 截断规则：地址 :50K: 4 行 × 35 字符，超出被截；开发时务必在发送前做字符集与长度校验。

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 校验

• BIC（SWIFT Code）是 8 或 11 位：AAAABB CC (XXX)：4 银行 + 2 国家 + 2 位置 + 3 分行（可选）；
• 光做格式校验不够，还要查 SWIFTRef 目录是否存在、是否活跃、能否收 MT103；
• BIC 目录每周更新，可订阅 SWIFTRef BIC Plus。

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

• 产品展示的”到账金额”必须明确标记”预计到账”（因为 SHA 下中转行扣费不可预测）；
• 若承诺”到账 100 USD 整”，要选 OUR 并自己承担不确定的中转行费用，在报价里预留 buffer（典型 20～50 USD）；
• gpi 成员行间可提前披露费用，可据此自动路由”最便宜代理行”。

10.5 退汇（Return）流程

• 收款人拒收、信息错误、制裁命中都会触发退汇；
• 退汇走 MT103RET 或 pacs.004；
• 退汇时汇率波动、扣费再叠加，客户拿回的金额往往少于原金额，产品必须明确”原路退回，不保证金额”；
• 部分国家（如印度）退汇流程极慢，可能 30+ 天。

10.6 截止时间与时区

• 每个代理行 / RTGS 有当日 cut-off：超过则进入下一工作日；
• 美东 cut-off vs 北京 cut-off 相差 13 小时，周末+节假日错位尤甚；
• 系统里要维护全球节假日日历 + 各币种 cut-off 时间表（可订阅 Swift Market Infrastructure Calendar 或 FinCal）。

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

• 1974 年德国 Herstatt Bank 在东京时区收了日元后，纽约时区开盘前倒闭，对手方没拿到美元；
• 跨时区 FX 交割是典型 PvP 缺失；
• 解决方案：CLS Bank（Continuous Linked Settlement）对 18 种主要货币做 PvP 原子交割；工程上只需通过结算银行把订单送入 CLS 即可。

10.8 节假日与价值日计算

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

• 汇款国的银行假日；
• 收款国的银行假日；
• 币种主要清算地的假日（USD 看纽约、EUR 看 TARGET 日历、CNY 看北京）；
• 周末（中东的周五/周六、多数国家的周六/周日）。

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 名称匹配与金额边界

• 收款人姓名在 SWIFT 只有 35×4 字符，中间名常被压缩；收款行做 “Confirmation of Payee” 校验时，姓名错一个字母就可能退汇；英国 CoP（Confirmation of Payee）自 2020 年起强制；
• 单笔/日累计金额阈值（如美国 10,000 USD 以上 CTR 报告、欧盟 10,000 EUR 以上 AMLD 报告），工程要按交易 + 客户 + 关联方三维聚合；
• 反拆分（Structuring / Smurfing）检测：同一客户 3 天内 9 笔 9,900 USD 应触发可疑上报。

10.10 二清与通道风险

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

工程上的”红灯”指标：

• 个人账户短期内大量不同对手方入账；
• 资金快进快出（入账 24 小时内即转出）；
• 入账国家集中在高风险地区（根据 FATF 灰名单/黑名单）；
• 币种与企业主营业务不符（例如五金贸易公司频繁收 BTC 场外结算）。

十一、选型建议

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

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

• 收单：Stripe / Paddle（Paddle 是 MoR，VAT/GST 代收）；
• 境外主体：Stripe Atlas / FirstBase；
• 资金回流：Wise Business / Airwallex 多币种账户；
• 不要直接接 SWIFT，做不起。

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

• 收款：PingPong / 连连 / 万里汇 / Airwallex 四选一（看手续费、提现速度、平台合作）；
• 税务：看各平台的 VAT 代扣规则（Amazon UK/EU 已代扣，其他平台自办）；
• 结汇：走机构渠道自动结汇 vs 境内银行手动结汇，视金额与税务成本；
• SAFE 报告：尽量走综试区 9610/9810。

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

• 银行电汇（SWIFT + 代理行）仍是主流；
• 金额大时谈判 FX 点差、不接受银行默认牌价；
• 提前锁汇（远期合约）对冲汇率风险；
• 使用 CIPS 走人民币直连，减少美元中转。

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

• SWIFT gpi 成员资格，接 Tracker API；
• 本地 IPS 互联（UPI/PayNow/PIX/SEPA Instant）减少小额走廊成本；
• 稳定币/CBDC 试点作为储备通道；
• 独立 Nostro 对账团队 + 全球制裁筛查平台（Actimize、Oracle FCCM、或自研）。

11.5 交叉引用

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

• 钱的建模（第 2 篇）：跨境场景同时涉及多币种、小数位数、汇率时点价值，币种字段是一等公民；
• 复式记账（第 3 篇）：Nostro/Vostro 镜像分录是双边记账的跨机构版本；
• 账务数据库（第 4 篇）：跨境账户数少但金额大，Nostro 账户会是热点账户，写入压力巨大；
• 幂等与事务（第 5 篇）：SWIFT 报文级重发 + TCC 补偿是跨境常见事务形态；
• 支付网关（第 9 篇）：跨境的通道编排明显比境内复杂；
• 清算结算（第 11 篇）：跨境的”清算”与”结算”边界更模糊，要格外小心；
• 央行支付系统（第 12 篇）：CIPS、Fedwire、TARGET2 是跨境的”基础设施层”；
• 数字人民币与稳定币（第 14 篇）：本文稳定币章节的进一步展开；
• 对账系统（第 23 篇）：Nostro 对账是”对账之王”，难度最高。

十二、参考资料

• SWIFT 官方文档：MT Category 1（103）、SWIFT gpi Customer Credit Transfer、ISO 20022 Migration Guide（https://www.swift.com）
• BIS CPMI：Cross-border payments: a vision for the future、Project mBridge、Project Agorá（https://www.bis.org/cpmi/）
• Wise Transparency Reports & Engineering Blog（https://wise.com/about）
• Airwallex Engineering Blog、Global Account 白皮书
• Circle USDC Transparency、Visa 稳定币试点新闻稿
• OFAC SDN List、EU Sanctions Map、UN Consolidated List 官方发布页
• 中国人民银行《CIPS 业务规则》、国家外汇管理局《货物贸易外汇管理指引》
• FATF《基于风险的方法指引》、OECD CRS 标准
• Bank for International Settlements, Triennial Central Bank Survey 2022（FX 市场规模）
• FATF Recommendation 16（Travel Rule）与 VASP 指引
• CLS Bank 白皮书（关于 PvP 结算的 Herstatt 风险消除）
• SWIFT gpi Customer Credit Transfer Service Description

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

把视角拉远，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 都可能逐步被重写成智能合约调用。但在那之前，我们仍将和本文描述的这套”慢而稳”的基础设施共处很长时间。

• SWIFT 官方文档：MT Category 1（103）、SWIFT gpi Customer Credit Transfer、ISO 20022 Migration Guide（https://www.swift.com）
• BIS CPMI：Cross-border payments: a vision for the future、Project mBridge、Project Agorá（https://www.bis.org/cpmi/）
• Wise Transparency Reports & Engineering Blog（https://wise.com/about）
• Airwallex Engineering Blog、Global Account 白皮书
• Circle USDC Transparency、Visa 稳定币试点新闻稿
• OFAC SDN List、EU Sanctions Map、UN Consolidated List 官方发布页
• 中国人民银行《CIPS 业务规则》、国家外汇管理局《货物贸易外汇管理指引》
• FATF《基于风险的方法指引》、OECD CRS 标准
• Bank for International Settlements, Triennial Central Bank Survey 2022（FX 市场规模）

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

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