【支付系统】资金视角看支付系统架构设计

#跨境业务 #资金平台 #账户

1 前言2 支付和资金的关系3 资金平台的职责4 跨境业务的复杂性5 支付和资金的关系6 资金平台做了哪些事7 总结

在线支付是一个有近 20 年发展历程的行业，其背后系统的技术设计也随着时间、政策、技术的迭代，不断发生着变化。作为一个与钱直接打交道的行业，支付系统的准确性、安全性、稳定性要求都非常高，对程序员而言无疑是一个非常有挑战性的技术领域。

本文从资金的视角提炼了支付系统背后的业务与技术要点，帮助大家理清支付和资金的关系，文中多处架构示意图非常直观，相信能给大家一些全面的技术输入！

一、前言

提起在线支付，大家一定不陌生，这个行业发展了快20年了，最近又推出了“碰一碰”支付等创新形态。但绝大多数人对支付的了解仍只浮在水面上，作为支付行业从业者，今天来带大家看看冰山下面的部分：欢迎走进“资金管理”这个神秘领域。

二、支付和资金的关系

这里所说的“资金”或“资金管理”不是特指某一个团队或某一款产品，你可以理解为支付一定要与钱打交道吧？我暂且把在支付流程中与钱相关的东西都放进一个黑盒子里，为了便于叙述，给这个黑盒子取一个名字叫“资金平台”，再一步步解密黑盒子里放了哪些东西。在正式解密之前，我们先看看这个黑盒子（“资金平台”）在支付流程中是如何与上下游交互的。

举个例子，小明口渴了，进711买了一瓶水，用微信支付向收银员付了5元钱。

整个流程大致上像是这样：

首先这个资金平台是服务于支付公司（比如微信支付）的，理论上每个支付公司都应当有个资金平台，架构上或许多少有些不同，但底层原理上是一致的。

那么资金平台需要做些什么呢？如果只从最浅显的角度看，应该至少完成这1件事：把小明支付的5元钱转给711。

问题就来了，就这么简单，支付系统不能自己做吗，为什么一定要交给资金平台？直觉告诉我们，银行、微信支付、711属于不同的体系，用户的钱不会乖乖的自己飞到711的账户里，这里面一定还有许多“猫腻”，不着急，下面就来一点点解密。

在此之前先插个题外话：上图向银行发起扣款看起来也是与资金相关的动作，为什么不是资金平台来完成？这是因为扣款是支付主链路的关键环节，支付强依赖扣款结果来确认支付状态，而且扣款指令只是完成了与银行的信息流交互，并未真正发生资金流转。

三、资金平台的职责

3.1 备付金账户管理

首先还是要回答这个问题：钱是怎么从用户银行卡转到711的?

银行当然不会直接对接711，中间需要经过微信支付进行中转，根据央行的规定，第三方支付的资金都需要受到两联（银联、网联）监管，微信支付需要在央行开设一个备付金账户，所有未结算的资金都会沉淀在备付金账户里。

资金平台需要负责对备付金账户进行管理，包括：

1、账户开立。
2、账户信息管理。
3、冻结解冻。
4、账户销户。

实际上一家支付公司不可能只开一个备付金账户，在断直连以前账户都是直接开在商业银行的，断直连后也仍有许多场景需要在商业银行开户。理论上说只有开在央行的账户才叫备付金账户，大家平时交流说习惯了会把普通账户也叫做备付金账户。

不管怎么样，这些账户里都是有存钱的，都是物理账户，为了便于管账，每一个物理账户还会在公司内部开设一个虚拟“影子户”或者叫“头寸户”。

3.2 （客户）账户管理

小明作为微信支付的用户，在微信支付里有个钱包账户，就是我们平时看到的这个：

每个用户在资金平台内都有一个“余额户”，充值、收到红包时账户就会加钱，使用余额支付时账户就会扣钱。

小明买水如果用银行卡支付，就不涉及余额户的变动；如果用余额支付，则余额-5。

=所谓“客户账户”就是指提供给客户使用的账户，包括个人用户和商户==。

与“客户账户”对应的叫做“内部户”，内部户不需要开放给客户使用，只用于内部记账。

至此，我们可以用一张图描述资金账户体系：

这里的账户体系所包含的，是企业自己需要管理的账户。像小明自己在工商银行开设的账户则不属于管辖范围。

3.3 结算

有了上面的准备工作后，我们就可以开始结算了。

结算，就是把资金结给商户的过程。

根据商户入驻时签订的合同，每个商户都有相应的结算周期和结算方式。

• 结算周期：例如实时结算，T+1 结算
• 结算方式：结算到卡，结算到余额

假设 T+1 结算，整个过程看起来像这样：

如果结算到余额，直接商户余额+20，如果结算到卡，根据行业规范要求信息流需要经过银网联，再由银网联进行统一清算。

3.4 对账

资金平台很重要的一个职责是保证资金安全。我们先来看看小明支付的5元是怎么进到微信支付的备付金账户的：

前面说到第三方支付的资金受到两联监管，每一笔交易都需要上报，网联在这里面还承担了资金清算的职责。它会算清楚工商银行和财付通的应收应付账款，一定时间内进行汇总后一次性打款。

可以看到清算的工作交给了网联，支付公司只是被动接受消息和收到账款，虽说网联是国家队，但有没有极小的可能性它也会算错？例如程序员写了一个bug之类的？

为了避免这种情况发生，我们就需要进行资金对账，使用标准的三层对账模式：

第一层：明细对账，我方的【交易明细】和网联的【清算明细】进行逐笔明细对账，对账的结果生成一个【汇总账单】
第二层：资金对账，【汇总账单】和备付金银行入账后会生成的【银行账单】进行汇总级的对账
第三层：余额对账，今天的银存日终余额 = 昨天银存日终余额 + 今日发生额

三层对账保证了每一笔明细、每一笔账款的准确性。

不只是小明的付款会有对账，前面提到的结算过程也会对账，只要发生了实体资金变动的都需要进行对账。因此有时也把对账称为账实核对。

3.5 记账

上面的支付过程有个小问题，如果是 T+1 结算，从小明支付成功到真正结算还隔着老长时间，在这中间买水的5元钱去哪了？

这就要分实体资金和虚拟资金来说明了。

实体资金，也就是真正意义上的钱在哪，这个要看网联的清算周期

1、网联完成清算后，实体资金才会进到备付金账户
2、备付金账户的钱，需要T+1结算后给商户（实际上这里也需要等网联清算完成才能真正到账）

实体资金的流转看起来像这样：

可以看到实体资金的流转并不总是那么实时的，有一些“真空期”：钱在路上了，至于到哪了咱也不知道。为了能更好地管理整个资金的生命周期，降低资金风险，就需要引入虚拟资金流，也就是我们所说的“记账”。

上面提到小明支付成功后，但还未结算前，资金就沉淀在“商户待结算”里面，类似于“商户待结算”这样的账户，就是内部户。

我们尝试还原一下完整的记账过程，注意记账是以支付公司的视角去记的（假定商户是结算到余额）：

细心观察可以发现，记账过程有这样的特点

1、每次都记两个户，一个是借记(D)一个是贷记(C)，这是因为记账过程用的是复式记账法，需要遵循“有借必有贷，借贷必相等”
2、内部户有个账户类型的属性，标在表格里了 D 表示借记账户，C 表示贷记账户。账户类型与记账方向，同号为增，异号为减
3、记账全部完成后，最终备付金头寸+5，商户余额+5，这与预期相符。

上面提到了实体资金流，那是否有虚拟资金流？

当然有，我们按照借记指向贷记的顺序，把所有相关的内部户串联起来，就形成了虚拟资金流。

那么记账有什么用呢？

1、更细粒度管理资金的流转，通过记账可以知道一笔资金现在到了哪个环节。
2、通过账户沉淀资金，可以推断是否存在资金风险，例如“应收待清算”账户长期沉淀大量资金，说明可能有合作机构未完成资金清算。
3、记账本身就是一种资金风险的防控手段，例如有人篡改了账户余额，通过余额和账务流水核对就可以发现。
4、出财务报表。

3.6 会计核算

现在我们知道了一笔支付的钱怎么收进来，怎么结出去，怎么通过记账、对账来防范和识别风险，还有什么没做的吗？

确实还有一件事：如果账记错了怎么办？不仅会影响资金风险防控的效果，财务报表也会不准确，影响经营决策。

在会计学上是通过会计核算的方式来验证账本是否有问题。

简单来说，会计核算就是在做核对和统计。有这么几件事：

1、借贷平衡校验。每一笔账需要保证满足“有借必有贷，借贷必相等”。

2、对内部户进行归类，形成一颗多叉树结构，叶子节点是所有的内部户，不断向上汇总。我们把非叶子节点都称作“科目”，父科目的总额=子科目汇总金额。

3、在总账上，必须满足借方余额=贷方余额。也就是会计恒等式：资产=负债+所有者权益。

感兴趣的可以进一步搜索【资产负债表】、【利润表】、【现金流量表】，本文就不再继续延伸了。
用一张图总结一下在支付流程中资金平台的职责和作用：

四、跨境业务的复杂性

文章的上半部分说的是境内一笔支付的场景， 在跨境场景下是否有什么区别呢？任何业务一旦加上了“跨境”二字，整个业务和系统的复杂度就不只是上升了一个量级。

1、最直观的感受，好像啥都变多了：主体、银存、币种、时区……例如银存，在国内可能开两三个备付金账户就够用了，到了跨境业务，至少各大洲都要开设银存，还得覆盖至少10多个大币种。
2、对资金的时效性更敏感了。在国内大家已经对资金立即到账已经习以为常，就连跨行转账都能做到秒级到账。跨境就不一样了，资金通常需要经过多个国家或地区，资金链路越长，到账时效也就越长。时效性对用户体验的影响是巨大的。
3、需要了解每个地区当地的支付习惯，我觉得在所有复杂性里面，localization是最复杂的一个环节。每个国家，他们的消费习惯和支付习惯完全不一样，如果只是照搬国内的业务模式，大概率会失败。
4、需要应对不同的监管政策。例如货币的出境限额，经营牌照，备付金的存管方式，数据隐私性要求等。
5、需要敏锐地观察和应对国际局势，包括但不限于：xx 国大选、地缘冲突、政治博弈、货币政策等。我曾经历过美联储加息，通过购买理财“躺着把钱赚了”，也经历过俄乌冲突一夜之间卢布暴跌，俄罗斯账户全面冻结。是的，就是这么刺激！
6、技术架构的复杂度大大增加。做国内业务可能只需考虑同城多机房，再复杂一点可能需要考虑 X 地 X 中心，国际业务中就不得不考虑每个国家对数据出境的政策要求，政策会影响机房的建立和部署，还会进一步影响容灾策略和性能，例如在对客业务中跨洲的调用延时是绝对无法接受的。

以上不同因素的叠加导致资金业务的复杂性也是指数级上升，但咱也别被这些就吓住了，看看在这样的背景下资金平台应该怎么做。

五、支付和资金的关系

从这个章节起，我们聊一聊跨境支付中的资金管理问题。

现在把场景换成跨境支付，小明去韩国旅游，进711买了一瓶矿泉水，价格是1000韩元（KRW），拿着微信扫码，随着“滴”的一声，付款成功5人民币（CNY）。

跨境业务确实有些复杂，上面的场景设置过于粗糙了，正式开始之前我们得补充一些必要的假设 （这个场景是虚拟场景，与微信业务无关）：

1、二维码是怎么来的，微信中国钱包能识别吗？我们假设这个二维码是“微信支付-韩国”分公司提供的，韩国分公司在这里承担的是收单的角色
2、小明拿着微信中国钱包去扫码，钱包的背后也得有家公司，假设叫“微信支付-中国”，这里是发卡的角色（关于发卡和收单，我会专门另开一期单聊）
3、境内支付还涉及网联清算

把上面的图扩展一下，逻辑上的关系大概像这样：

六、资金平台做了哪些事

6.1 备付金和账户体系

备付金其实跟国内的备付金管理区别不大，也是要管理备付金账户的生命周期。但是需要注意：

1、尽量把账户开到大银行上，因为国外的银行是真的会倒闭。
2、出于风险考虑，不要把钱都放到一个篮子里。
3、根据需要开设多币种账户。

账户体系也没什么区别，在上文已经介绍过了。

6.2 资金通路管理

资金从小明的银行卡到711商户要分几步？咱们来一步步分析：

1、小明用微信中国钱包付了 5CNY，这部分根据境内支付行业规范，资金要先经过央行备付金账户。
2、要出境的资金还需要经过跨境专户。
3、在哪里做外汇兑换，也就是把 5CNY 换成 1000KRW？可能有几种方式：

a、在境内直接兑换成 KRW 再出境到韩国。
b、CNY 先出境变成离岸人民币CNH，在香港或新加坡兑换成 KRW，这种情况为了更便于开展业务，就需要在香港或新加坡注册公司，暂且称为“微信支付-香港”和“微信支付-新加坡”。
c、或者有没有可能 CNH 先进入韩国，在韩国境内兑换成 KRW？这种基本不太考虑，因为韩国可能有货币政策的限制，而且香港和新加坡本就是亚洲的金融中心，在外汇方面有更多的自由度。
d、当然还有一种方式就是委托境外机构代发，但要这么说的话这篇文章就没有意义了。咱举例说明，就是要举最详细的例子，全流程都做。

完整的资金通路可能是这样（境内兑换）：

或这样（出境后兑换）：

现实情况可能比这还复杂的多，因此资金平台一个重要的作用就是把资金链路打通，某些情况下或许有不止一条资金通路，那就还需根据资金时效性、资金成本、监管政策等因素进行综合决策，选一条最合适的资金通路。

6.3 外汇兑换

小明支付的5CNY必须经过外汇兑换（FX：Foreign Exchange）才能转成KRW。但如果要展开聊外汇，估计一篇文章都写不下，这里还是聚焦说一说在支付关键链路下外汇的核心流程。

我们以上面的资金通路二进行说明：

1、外汇报价（FX Quote）。用户在扫码支付的那一刻，就需要进行一次外汇报价，根据查询的即时汇率再进行一些加点报给用户，这样用户才能在支付时看到应付 5 CNY。
2、外汇交易（FX Trading）。外汇交易的模式有很多种，在此不长篇大论，仅说本例，交易分成两阶段：

• a、外汇锁价。因为汇率是实时变化的，小明扫码支付了5CNY，在此刻预期是能兑换1000KRW，但如果不锁价，发生汇率波动，真正兑换的时候也许只能兑换980KRW，也可能兑换1020KRW，若不愿意承担风险，通过锁价机制就可以保证交易时不多不少能换回1000KRW。

• b、外汇交易。这一阶段是真正触发交易，按照约定的锁价汇率，把 CNY 付给兑换机构（如 BOCHK），兑换机构把相应的KRW兑换回来。
  3、头寸管理（Position Management）。在小明支付成功那一刻，意味着公司账户收入 5CNY（或者说是待收），同时也意味着公司对711产生一笔 1000KRW 的待付，虽说有锁价机制，但只要没真正去做兑换，这个风险敞口就一直存在。头寸管理就是要把风险敞口或风险水位控制在一定范围内，通过制定合理的交易策略，及时地完成外汇交割，消除风险敞口，这一过程通常也称作“平盘”。

大致上外汇的核心流程是这样的：

6.4 清算和对账

清算的重点就是分清参与清算的双方是谁，谁是主动清算，谁是被动清算。

阶段一：清分，主动清算的一方负责算账，算好了给对方出一份清算文件，被动清算的一方要明细对账，以免对方算错了。

阶段二：清偿，根据清分的结果进行打款。主动清算方通过调拨把钱转入被动清算方账户。这时双方的银行发生动账，会各自收到银行的账单通知，还需要进行一次账单对账。

清算和对账的大体流程如下：

实际上这里的复杂性并不来自于清算流程， 而是对清算关系的分析。我们以上面的资金通路二为例，来捋一捋整个链路中所有机构间的清算关系：

这里有两点稍做解释

1、网联的清算特殊一些，叫做第三方清算模式。网联是第三方清算机构，负责支付渠道（工行）和 WeChatPay CN 之间的清算。
2、WeChatPay CN,HK,KR 之间存在比较复杂的委托兑换和委托代付关系：

• a、Wechat Pay CN 的视角：要付给 KR 1000KRW，但是我手里只有 5CNY，因此要委托 WeChatPay HK 做兑换，兑换后的KRW不急着要回来，后面清偿时再委托代付就好了。
• b、Wechat Pay HK 的视角：收到一笔 CNY-KRW 的兑换请求，并且把兑换完的 KRW 付出去。
• c、Wechat Pay KR 的视角：我只知道 WeChatPay CN 要付给我1000KRW，至于钱是从哪里来的我不关心，所以我感知不到 WeChatPay HK。

6.5 多主体账务管理

说到这里，你应该对实体资金流比较了解了，但资金平台还有一个重要职责就是管理虚拟资金流，也就是记账。

说记账之前又得先说一个名词：主体（Entity），或叫法人主体（Legal Entity），可以理解为在法律上独立注册的一家公司，享有法人权利和义务，例如签订合同等需要法人主体来签订。

还有一个词叫核算主体或会计主体（Accounting Entity），因为稍微大一点规模的公司，不会只做单一业务，不同业务的账需要分开管，而核算主体就是为了管账而设计的，我们平时说的“你这笔账要记到哪个主体下面？”这里就是指核算主体。

与境内支付单主体、单币种不同，跨境支付涉及到跨主体、多币种。为了能够说清一笔跨境支付，我就虚拟出了3个主体（微信支付中国 WPCN，微信支付香港 WPHK，微信支付韩国 WPKR），假设每个主体只做单一业务，也就是只有一个核算主体。

记账的要求是每个核算主体、每个币种都要有单独的账本。

OK，下面就到了资金管理领域最最最最最最难理解的部分了，我会把大致资金流画出来，但我并不打算立刻解释为什么账要这么记，设置这些账户的目的是什么。这部分需要比较深的业务背景和账务知识，外行看起来会很晦涩枯燥。

资金流并不是只有唯一一种画法（与业务流程设计有关），这里以资金通路二为例，仅供参考：

是不是很晕？没关系，对于没有账务背景的同学，目前只需知道两点就够了：

1、资金流的箭头不代表记账顺序，只代表记账的借贷关系，顺序用数字标出来了。
2、虚拟资金流就是物理资金流的展开，虚拟资金流的第一个节点和最后一个节点与物理银存对应，中间节点表示资金所处的中间态。

6.6 流动性管理

咱也问了一下 GPT，什么是流动性（Liquidity）管理？

资金流动性管理是指企业或金融机构对其资金流动性进行监控、分析和优化的过程，以确保在需要时能够迅速获取足够的现金或现金等价物，以满足短期的财务需求和运营支出。流动性管理的目标是平衡流动性风险与收益，确保企业在任何时候都能履行其财务义务。

害~这种专业术语，就是懂的人都懂，不懂的人问完也是一脸懵。

还是我来说吧。我们先来看看在支付业务，尤其在跨境支付中为什么需要用到流动性管理？

1、跨境支付的资金交割链路比较长，中间任意环节卡住了都有可能影响资金交付时效，毕竟每个商户入驻都签订了结算协议的，未在约定的结算周期内完成结算，轻则影响商户的现金流，重则影响平台的声誉，可能面临赔偿
2、某些场景下或许会通过垫资的方式加快资金交付效率，提升产品的竞争力。

不管是上述哪种场景，都是需要识别出哪些环节可能存在资金短缺，并及时通过其他手段（如资金调拨）填补短缺资金，以确保业务运营的稳定性，这就是流动性管理。

要达成这一点，我们就需要做到：

1、对资金流量的预测。流动性管理需要熟悉全局的资金流动情况，并根据历史数据的分析，预测未来的资金流量
2、对资金水位的监控。跨境业务需要在全球不同国家和地区开设许多银存账户，流动性需要监控每个账户的资金水位，识别潜在的流动性短缺
3、要具备全球流动性调拨机制。例如现在需要紧急调拨1亿韩元进入韩国，可能某些银行在非工作时间，无法受理大额跨境请求，这时就要考虑从其他时区调入资金
4、跨境业务还需多考虑一个外汇因素。避免因某个币种外汇储备不足导致业务受影响，但也不能储备过多的外汇，需承担汇率波动风险

七、总结

我们来总结一下，把资金平台这个黑盒子打开，看看里面到底长啥样。

跨境业务是非常复杂的，本文也只是走马观花，把主流程大致盘点了一下。后续还会展开更多技术架构和实现细节，可以关注公众号了解更多。

欢迎关注原文作者 Louis 的公众号：支付进阶之路