清算与结算是支付系统的资金闭环，是连接交易与最终资金到账的核心环节。简单来说，清算是计算"谁该付给谁多少钱"的过程，结算是实际"把钱从一方账户划到另一方账户"的动作。没有高效的清算结算体系，任何支付系统都只是一堆"显示成功但没有钱到账"的虚拟交易。
理解清算结算，需要先理清它在整个支付链路中的位置：用户发起支付 → 支付网关转接 → 交易授权 → 清算（对账、计算净额） → 结算（资金划拨） → 最终到账。本文将围绕这个闭环，系统化讲解清算结算的全部关键知识点。
很多从业者将"清算"和"结算"混用，但在专业语境下二者有严格区分。
| 概念 | 英文 | 定义 | 实质 |
|---|---|---|---|
| 清算 | Clearing | 交易数据汇总、配对、对账、计算净额的过程 | 信息的计算与核对 |
| 结算 | Settlement | 根据清算结果，在参与方账户间实际转移资金 | 资金的划拨与交割 |
| 交割 | Delivery | 结算完成后的最终资金到账确认 | 资金所有权的最终转移 |
假设一天内发生了3笔交易：
| 交易 | 付款方 | 收款方 | 金额 |
|---|---|---|---|
| #1 | 商家A | 商家B | ¥100 |
| #2 | 商家B | 商家A | ¥200 |
| #3 | 商家A | 商家C | ¥150 |
清算阶段的计算：
结算阶段的实际操作：
这个例子展示了为什么净额清算可以显著减少资金转移次数——原本需要3次转账，通过净额计算只需要2次。
| 清算模式 | 时间窗口 | 适用场景 | 典型系统 |
|---|---|---|---|
| T+0（实时清算） | 交易发生时即时清算 | 卡组织小额交易、数字钱包 | Visa DPS、支付宝 |
| T+1（隔日清算） | 交易日次工作日完成 | 跨境支付、B2B贸易 | SWIFT、银行间清算 |
| T+2 | 交易日+2工作日 | 国际卡组织标准 | Visa/Mastercard |
| T+N（定期清算） | 固定周期（周/月） | 批发支付、合作伙伴分润 | 代理行模式 |
交易日(D日) D+1日 D+2日 D+N日
| | | |
├─交易数据收集─────┤ | |
| (抓取所有交易) | | |
├─数据配对─────────┤ | |
| (按交易ID匹配) | | |
├─差异分析─────────┤ | |
| (标记不匹配项) | | |
└──────────────────┼─净额计算──────────┤ |
| (汇总净应付/应收) | |
└────────────────────┼─资金划拨──────────┤
| (发起实际转账) |
└────────────────────┼─到账确认
| (结算完成)
每个清算周期开始时，系统从支付网关、收单系统、发卡系统等各子系统采集当周期内的全部交易数据。数据来源包括：
数据格式示例（一条清算记录）：
| 字段 | 值 | 说明 |
|---|---|---|
| 交易ID | TX2026053000001 | 全局唯一交易号 |
| 交易时间 | 2026-05-30 14:23:15 UTC+8 | 交易发生的精确时间 |
| 交易金额 | 15.99 USD | 原始交易币种和金额 |
| 结算金额 | 115.13 CNY | 按汇率转换后的金额 |
| 商户号 | MERCHANT_A001 | 收款商户标识 |
| 渠道 | VISA_CREDIT | 交易渠道 |
| 手续费 | 0.32 USD | 每笔交易的手续费 |
| 交易状态 | SUCCESS | 交易成功/失败/退款 |
这是清算最关键的环节。系统将交易日志与外部对账文件进行逐笔配对匹配。常见的配对键包括：
交易ID + 交易金额 + 交易时间 + 商户号（最严格）交易ID + 交易金额（常用的折中方案）参考号 + 金额（卡组织场景）配对结果分类：
┌─────────────────────────┐
│ 100% 匹配 (Match) │ ≈ 95%+ 的交易
│ ✓ 金额、ID、时间一致 │
└──────────┬──────────────┘
↓
┌─────────────────────────┐
│ 金额不符 (Mismatch) │ ≈ 1-3%
│ ✗ 交易存在但金额不同 │
└──────────┬──────────────┘
↓
┌─────────────────────────┐
│ 一方存在 (One-Sided) │ ≈ 1-2%
│ ✗ 我有一笔对方没有 │
└──────────┬──────────────┘
↓
┌─────────────────────────┐
│ 完全缺失 (Missing) │ ≈ 0.1-1%
│ ✗ 对方文件没有匹配项 │
└─────────────────────────┘
配对后产生的不匹配项进入差错处理流程：
| 差错类型 | 产生原因 | 处理方式 | 处理时效 |
|---|---|---|---|
| 金额差 | 手续费计算差异、汇率差异 | 核查费率配置、补传凭证 | T+3内 |
| 单边账 | 一方成功、另一方失败 | 根据支付网关日志确认实际状态 | T+1内 |
| 时间差 | 跨时区交易日期归属不同 | 以交易发生时间为准统一 | T+1内 |
| 重复记账 | 系统重试导致同一笔交易被记两次 | 去重后冲正其中一笔 | T+1内 |
| 缺少交易 | 对方未收到报文 | 重新发送对账文件 | T+1内 |
这是清算的核心计算步骤。
净额清算 Net Settlement：
参与方集合 P = {银行A, 银行B, 银行C, 商户X, 商户Y}
支付义务矩阵 M[i][j] = 参与方i应支付给参与方j的金额
净额 = 应收总额 - 应付总额
实际计算示例（假设5个参与方一天的交易数据）：
| 参与方 | 应付给其他人 | 应收自其他人 | 净额 |
|---|---|---|---|
| 银行A | ¥500,000 | ¥320,000 | -¥180,000（应付） |
| 银行B | ¥280,000 | ¥450,000 | +¥170,000（应收） |
| 银行C | ¥150,000 | ¥200,000 | +¥50,000（应收） |
| 商户X | ¥0 | ¥380,000 | +¥380,000（应收） |
| 商户Y | ¥0 | ¥120,000 | +¥120,000（应收） |
| 合计 | ¥930,000 | ¥1,470,000 | ¥0（借贷平衡） |
通过净额清算，实际资金划拨次数从潜在10次（5×5减去自付）降为5次（净应付参与方向净应收参与方转账一次）。
全额清算 Gross Settlement： 每个交易都单独结算，不做轧差。优点是风险隔离，缺点是资金需求大、效率低。主要用于央行大额支付系统（如中国的HVPS、美国的Fedwire）。
清算计算完成后，结算系统执行实际的资金转移：
| 结算方式 | 说明 | 时效 | 示例 |
|---|---|---|---|
| 央行行间结算 | 通过央行支付系统进行银行间资金划拨 | 实时（RTGS） | 中国大额支付系统（HVPS） |
| 代理行结算 | 通过代理行账户完成跨境资金转移 | T+1~3 | SWIFT MT103 |
| 内部转账 | 同一机构内部账户间划拨 | 实时 | 支付宝商户结算 |
| 卡组织结算 | Visa/Mastercard通过清算银行结算 | T+2 | Visa Net Settlement |
| 格式 | 特点 | 适用场景 | 解析难度 |
|---|---|---|---|
| ISO 8583 | 卡组织标准，二进制报文 | 实时交易授权与清算 | ⭐⭐⭐⭐⭐ |
| CSV | 简单、通用、易处理 | 中小规模对账、内部系统 | ⭐ |
| XML | 结构化、自描述、扩展性好 | SWIFT MX、银行间报文 | ⭐⭐⭐ |
| JSON | 轻量、开发友好、层次化 | API驱动的现代支付系统 | ⭐⭐ |
| EDI | 企业数据交换标准 | B2B贸易、供应链金融 | ⭐⭐⭐⭐ |
ISO 8583 是卡支付领域的核心标准，清算文件通过 MTI（Message Type Indicator）区分用途：
| MTI | 含义 | 用途 |
|---|---|---|
| 1100 | 授权请求 | 交易发起时 |
| 1110 | 授权响应 | 发卡行回复 |
| 1200 | 交易请求 | 清算阶段发送 |
| 1210 | 交易响应 | 对清算请求的确认 |
| 1304 | 清算文件 | 批量清算数据 |
| 1420 | 撤销 | 撤销一笔交易 |
| 1804 | 退款 | 发起退款 |
ISO 8583 清算消息的典型字段布局：
MTI: 1304 ← 清算文件
Bitmap: B0 28 04 00 10 00 00 00 ← 指示哪些字段存在
DE2 (PAN): 622202****1234 ← 卡号
DE3 (处理码): 000000 ← 交易类型
DE4 (金额): 000000001599 ← 15.99 USD
DE12 (时间): 143015 ← 14:30:15
DE13 (日期): 0530 ← 05月30日
DE15 (清算日期): 0601 ← 清算日期
DE32 (机构码): 123456 ← 收单机构
DE41 (终端ID): TERM00123 ← 终端标识
DE54 (附加金额): 000000000032 ← 手续费 0.32
交易ID,交易时间,商户号,交易金额,手续费,结算金额,币种,渠道,状态
TX0001,2026-05-30 14:23:15,MER001,15.99,0.32,115.13,CNY,VISA,SUCCESS
TX0002,2026-05-30 14:25:30,MER001,89.50,1.79,644.35,CNY,MASTERCARD,SUCCESS
TX0003,2026-05-30 14:30:00,MER002,250.00,5.00,1800.00,CNY,VISA,SUCCESS
TX0004,2026-05-30 14:32:45,MER001,3.99,0.08,28.73,CNY,VISA,REFUND
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.054.001.08">
<BkToCstmrDbtCdtNtfctn>
<Ntfctn>
<Id>NOT202605300001</Id>
<CreDtTm>2026-05-30T23:59:59+08:00</CreDtTm>
<Ntry>
<Amt Ccy="USD">159900</Amt>
<CdtDbtInd>CRDT</CdtDbtInd>
<BookgDt><Dt>2026-05-30</Dt></BookgDt>
<ValDt><Dt>2026-06-01</Dt></ValDt>
<BkTxCd>
<Prtry><Cd>VISA_SETTLEMENT</Cd></Prtry>
</BkTxCd>
</Ntry>
</Ntfctn>
</BkToCstmrDbtCdtNtfctn>
</Document>
成熟的支付系统采用三级对账，逐层确保资金准确：
第一级：交易对账（Transaction Reconciliation）
│ 系统内交易日志 vs 外部渠道对账文件
│ 频率：每日
│ 粒度：逐笔
v
第二级：资金对账（Fund Reconciliation）
│ 清算净额 vs 实际银行到账金额
│ 频率：每个结算周期
│ 粒度：按结算批次汇总
v
第三级：手续费对账（Fee Reconciliation）
│ 系统计算手续费 vs 渠道收取手续费
│ 频率：每周期
│ 粒度：按费率模板汇总
输入:
A: 支付系统交易日志（数据库导出）
B: 渠道对账文件（Visa/银行/卡组织提供）
步骤:
1) 数据标准化——将A和B转换为统一格式
2) 键匹配——按(交易ID, 金额, 时间)匹配
3) 分类:
a. Match → 一致, 标记完成
b. AmountMismatch → 金额不一致, 进入人工核查
c. OnlyInA → 系统有但渠道没有(长款), 需核实
d. OnlyInB → 渠道有但系统没有(短款), 需补录
4) 生成对账报告
配对算法示例（伪代码）:
def reconcile(system_txns, channel_txns):
unmatched_sys = set(system_txns.keys()) # 长款集合
unmatched_chn = set(channel_txns.keys()) # 短款集合
matches = []
mismatches = []
# 第一轮：精确匹配（ID + 金额 + 时间）
for tx_id in system_txns:
if tx_id in channel_txns:
sys_txn = system_txns[tx_id]
chn_txn = channel_txns[tx_id]
if abs(sys_txn.amount - chn_txn.amount) < 0.01:
matches.append(tx_id)
unmatched_sys.remove(tx_id)
unmatched_chn.remove(tx_id)
else:
mismatches.append((tx_id, sys_txn.amount, chn_txn.amount))
# 第二轮：模糊匹配（仅ID，忽略金额差异）
for tx_id in list(unmatched_chn):
if tx_id in unmatched_sys:
# 标记为金额不一致，人工介入
mismatches.append((tx_id, system_txns[tx_id].amount,
channel_txns[tx_id].amount))
unmatched_sys.remove(tx_id)
unmatched_chn.remove(tx_id)
return {
"matched": matches,
"amount_mismatch": mismatches,
"long_only": list(unmatched_sys),
"short_only": list(unmatched_chn)
}
假设一天有10,000笔交易，对账结果如下：
| 对账结果 | 笔数 | 占比 | 处理方式 |
|---|---|---|---|
| ✅ 精确匹配 | 9,750 | 97.5% | 自动通过 |
| ⚠️ 金额差（<¥1） | 120 | 1.2% | 自动调整，记录日志 |
| ⚠️ 金额差（≥¥1） | 45 | 0.45% | 自动标注，人工复核 |
| ⚠️ 单边账（系统有） | 55 | 0.55% | 核实后补发/冲正 |
| ⚠️ 单边账（渠道有） | 20 | 0.2% | 核实后补录 |
| ⚠️ 缺失交易 | 10 | 0.1% | 重新发送对账文件 |
| 合计 | 10,000 | 100% | — |
可接受的对账成功率：
| 维度 | 净额结算（Netting） | 全额结算（Gross） |
|---|---|---|
| 资金需求 | 只需准备净额部分，资金效率高 | 需要准备全部交易金额，资金需求大 |
| 结算笔数 | O(N) 笔（N=参与方数量） | O(N²) 笔（每对参与方之间） |
| 流动性风险 | 一方违约会影响多方，风险传播 | 逐笔交割，风险隔离 |
| 日内信用风险 | 存在（结算前风险敞口累积） | 极低（实时交割） |
| 适用系统 | 卡组织清算、ACH | 央行RTGS系统 |
| 国际案例 | Visa Net Settlement | Fedwire、中国HVPS |
假设10个参与方，每个参与方与所有其他参与方各有1笔¥100的交易：
在实际的多边支付系统中，净额结算可以将资金需求降低 60%~90%。
| 挑战 | 说明 | 典型案例 | 应对方案 |
|---|---|---|---|
| 时差 | 跨时区导致清算日归属争议 | 北京时间23:00的交易，美国东部时间11:00 | 以UTC时间为基准，明确"交易日"定义 |
| 币种 | 多币种清算需要外汇兑换 | USD收款要用CNY结算 | 自动换汇、多币种结算账户 |
| 监管 | 各国清算规则不同 | 欧洲要求SEPA清算，美国用ACH | 本地化部署、对接本地清算系统 |
| 节假日 | 各地节假日不同导致清算延迟 | 中国春节——美国正常工作 | 智能日历管理、预设节假日表 |
中国 🇨🇳 美国 🇺🇸
┌────────────────┐ ┌────────────────┐
│ 商户A │ │ 买家 │
│ (收款方) │ │ (付款方) │
└───────┬────────┘ └────────┬───────┘
│ │
┌───────▼────────┐ ┌────────▼───────┐
│ CNAPS │ │ Fedwire/ACH │
│ (大额支付) │ │ (美国清算) │
└───────┬────────┘ └────────┬───────┘
│ │
┌───────▼──────────────────────▼───────┐
│ 代理行/中间行 │
│ (如：中国银行纽约分行) │
│ │
│ 功能: │
│ • 报文转发 (SWIFT MT103) │
│ • 币种兑换 (USD→CNY) │
│ • 资金托管 │
└───────┬──────────────────────┬───────┘
│ │
▼ ▼
+¥1,000 (商户A) -$142.86 (买家)
(最终入账) (银行卡扣款)
整个过程涉及3次清算：
跨境清算中，同一个交易可能被记录为多个币种金额：
| 环节 | 币种 | 金额 | 汇率 |
|---|---|---|---|
| 用户支付 | USD | $142.86 | — |
| 卡组织清算 | USD | $142.86 | — |
| 收单行接收 | USD | $140.49 | VISA汇率 |
| 收单行结算给商户 | CNY | ¥1,000 | 收单行自定汇率 |
| 手续费 | USD | $2.37 | 费率2.0% |
对账时需要在这5个金额之间建立多币种关联，任何一个环节的汇率差异都会产生资金差。
┌─────────────────────────────────────────────────────────┐
│ 自动对账系统 │
├─────────────────────────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 数据接入 │ │ 数据转换 │ │ 配对引擎 │ │ 差异处理 │ │
│ │ │ │ │ │ │ │ │ │
│ │ FTP/SFTP │→│ CSV→标准 │→│ 精确匹配 │→│ 自动冲正 │ │
│ │ API拉取 │ │ XML→标准 │ │ 模糊匹配 │ │ 人工工单 │ │
│ │ MQ消费 │ │ ISO8583→│ │ 多键匹配 │ │ 报表导出 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────────────┐ ┌───────────────────────────┐ │
│ │ 规则引擎 │ │ 监控告警 │ │
│ │ │ │ │ │
│ │ • 费率匹配 │ │ • 对账成功率<99%告警 │ │
│ │ • 超时判定 │ │ • 未处理差异超24h告警 │ │
│ │ • 自动调账 │ │ • 大额异常交易告警 │ │
│ │ • 仲裁策略 │ │ • 渠道对账延迟告警 │ │
│ └──────────────────┘ └───────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
| 维度 | 指标 | 参考值 |
|---|---|---|
| 吞吐量 | 每日可处理交易笔数 | ≥100万笔 |
| 配对速度 | 10万笔交易的配对耗时 | ≤5分钟 |
| 自动处理率 | 无需人工介入的差异比例 | ≥95% |
| 对账完成时间 | 从收到文件到完成对账 | ≤2小时 |
| 数据一致性 | 系统数据不发生读写不一致 | 100% |
| 容错性 | 单点故障不影响对账 | 主备切换≤30秒 |
Level 1: 精确匹配（最基础）
配对键 = (交易ID, 金额, 时间)
匹配率 ≈ 95%
优点：零误匹配
缺点：任何字段差异都导致不匹配
Level 2: 容错匹配（推荐）
配对键 = (交易ID, 金额)
允许金额差异 ±0.01（考虑取整误差）
匹配率 ≈ 98%
仍不匹配的进入人工池
Level 3: 多键综合匹配（高级）
使用多个配对键候选集：
- (交易ID, 金额)
- (交易时间, 金额, 商户号)
- (渠道参考号, 金额)
取交集或最高分匹配
匹配率 ≈ 99.5%
Level 4: AI辅助匹配（前沿）
基于机器学习的异常检测
自动学习正常交易模式
预测性差异预警
匹配率 ≈ 99.9%+
| 风险类型 | 描述 | 影响程度 | 防控措施 |
|---|---|---|---|
| 流动性风险 | 参与方在结算时资金不足 | 高 | 流动性池、备用信贷额度 |
| 信用风险 | 参与方违约无法付款 | 高 | 押金/保证金制度、信用评级 |
| 操作风险 | 系统故障导致清算失败 | 中 | 容灾备份、降级策略 |
| 法律风险 | 跨境法律差异导致结算无效 | 中 | 合同条款明确、申请本地牌照 |
| 系统性风险 | 单一参与方违约引发连锁反应 | 极高 | 央行最后贷款人、PSR评估 |
参与方按预计日交易量预存保证金：
| 参与方 | 日均交易额 | 保证金要求（5%） | 实际清算金额 | 是否需要追加 |
|---|---|---|---|---|
| 银行A | ¥5000万 | ¥250万 | -¥300万 | 是（追加¥50万） |
| 银行B | ¥3000万 | ¥150万 | +¥100万 | 否 |
| 银行C | ¥2000万 | ¥100万 | +¥200万 | 否 |
当参与方资金不足时，按优先级排序等待：
排队队列:
1. 央行大额支付 → 最高优先级，立即处理
2. 客户资金结算 → 次高，必须在截止时间前完成
3. 金融机构间结算 → 普通优先级
4. 内部调拨 → 低优先级，可延迟
为防止单一参与方过度负债，设定净借记上限：
例如：
| 系统 | 国家/地区 | 清算方式 | 结算模式 | 日处理量 | 运营方 |
|---|---|---|---|---|---|
| HVPS | 中国 | 全额 | RTGS | ~300万笔 | 中国人民银行 |
| IBPS | 中国 | 净额 | 批量 | ~1800万笔 | 中国人民银行 |
| Fedwire | 美国 | 全额 | RTGS | ~80万笔 | 美联储 |
| CHIPS | 美国 | 净额 | 指定时间 | ~50万笔 | The Clearing House |
| TARGET2 | 欧盟 | 全额 | RTGS | ~40万笔 | 欧央行 |
| SEPA | 欧盟 | 净额 | 批量 | ~5000万笔/日 | EPC |
| BOJ-NET | 日本 | 全额 | RTGS | ~6万笔 | 日本央行 |
| CHATS | 香港 | 全额+净额 | RTGS | ~10万笔 | HKICL |
中国的清算体系由央行支付系统和清算机构两层构成：
┌──────────────────────────┐
│ 中国人民银行 │
│ (监管与运营) │
└────────┬─────────────────┘
│
┌───────────────┴───────────────┐
│ │
┌──────▼──────┐ ┌─────────▼────────┐
│ 大额支付 │ │ 小额批量支付 │
│ (HVPS) │ │ (IBPS/BEPS) │
│ RTGS │ │ 净额/批量 │
│ 实时到账 │ │ 非实时到账 │
│ 工作日运行 │ │ 7×24 │
└─────────────┘ └──────────────────┘
│ │
└───────────────┬───────────────┘
│
┌──────────────▼──────────────┐
│ 网联清算（NUCC） │
│ 银联清算（CUPS） │
│ 城银清算 │
│ 农信银清算 │
│ 跨境清算（CIPS） │
└─────────────────────────────┘
关键差异：
在系统设计初期就应该统一对账文件格式，避免后期多个渠道对接时陷入格式泥潭：
class ReconciliationFile:
"""统一的对账文件接口"""
format: str # csv, xml, json, iso8583
delimiter: str # 分隔符（CSV用）
encoding: str # UTF-8, GBK等
header_rows: int # 表头行数
skip_rows: int # 需跳过的行数
date_format: str # 日期格式
amount_multiplier: int # 金额乘数（分→元需除100）
# 字段映射
field_mapping: dict = {
"系统交易ID": "tx_id",
"交易金额(分)": "amount_cents",
"交易时间": "tx_time",
"商户号": "merchant_id",
"渠道": "channel"
}
对明确的小额差异（如¥1以内的金额差），可以实施自动冲正处理：
| 差异金额 | 自动处理 | 人工介入 | 案例 |
|---|---|---|---|
| ≤¥0.01 | ✅ 自动调平 | ❌ 不介入 | 汇率四舍五入差异 |
| ¥0.01 ~ ¥1.00 | ✅ 自动标注 | ✅ 可查询 | 手续费率微差 |
| ¥1.00 ~ ¥100 | ❌ 需确认 | ✅ 必须介入 | 费率配置错误 |
| >¥100 | ❌ 禁止处理 | ✅ 必须审核 | 系统Bug或欺诈 |
# 节假日影响清算日示例
holiday_calendar = {
"CNY": {
"2026-01-01": "元旦", # 中国元旦
"2026-02-17": "除夕", # 春节
"2026-02-18": "春节", # 春节
"2026-10-01": "国庆节", # 国庆
...
},
"USD": {
"2026-01-01": "New Year's Day",
"2026-01-15": "Martin Luther King Day",
"2026-05-27": "Memorial Day",
"2026-07-04": "Independence Day",
...
}
}
def get_settlement_date(trade_date: str, currency: str) -> str:
"""计算T+N清算日期（跳过节假日）"""
# 使用对应币种和交易发生地的节假日表
calendar = get_local_holidays(currency)
target = trade_date + timedelta(days=2) # T+2
while target in calendar:
target += timedelta(days=1)
return target
| 监控指标 | 告警阈值 | 严重程度 | 说明 |
|---|---|---|---|
| 对账成功率 | < 99% | P0 严重 | 资金差异风险 |
| 未处理差异数 | > 100笔 | P1 高危 | 处理积压 |
| 最长差异未处理时间 | > 48小时 | P2 中危 | 需跟踪确认 |
| 当日清算延迟 | > 2小时 | P1 高危 | 影响资金到账 |
| 渠道文件缺失 | 未收到 | P0 严重 | 立即联系渠道 |
| 大额异常单笔 | > ¥1000万 | P0 严重 | 可能欺诈或系统Bug |
| 地区 | 合规要求 | 具体要求 |
|---|---|---|
| 中国 | 《支付结算办法》 | 清算机构需持牌经营、备付金100%存管 |
| 香港 | 《结算及交收系统条例》 | 指定系统需获金管局认可 |
| 新加坡 | 《支付服务法》 | 清算活动需持MPI牌照 |
| 欧盟 | PSD2/SEPA | 跨境清算需符合SEPA规则 |
| 美国 | 《银行保密法》/OFAC | 跨境清算需进行制裁名单筛查 |
| 数据类型 | 保留期限（中国） | 保留期限（一般国际标准） |
|---|---|---|
| 交易日志 | 5年 | 7年 |
| 对账文件 | 5年 | 5年 |
| 清算报表 | 永久 | 10年 |
| 差错处理记录 | 3年 | 5年 |
| 结算凭证 | 5年 | 7年 |
支付清算与结算是支付系统的资金闭环，其核心职能可以概括为三个层次：
对于从事跨境支付的技术团队，以下几个设计原则值得重点关注：