0x00 引言

清算网络作为支付业务中的重要一环，承担着转接和清算两项主要的功能。目前全球比较有名的清算组织包括Visa(维萨)，Mastercard（万事达）,American Express(美国运通，以下简称AMEX),Discover（大莱），银联（UnionPay）。 国内的清算交易组织，还包含网联（NUCC），其中银联主要负责银行卡支付相关，网联主要负责非银支付，出于对三方支付监管的需求而成立，并逐渐通过清算网络完成了收单侧断直连和发卡侧的断直连。如果从系统维度，还应包含城银清算支付系统，农信银支付清算系统等。

AMEX和MasterCard分别于2019年和2023年在国内获得《银行卡清算业务许可证》。其中AMEX和连连数科共同出资并和银联进行合作，而MasterCard则是和网联进行合作。通过该方式使国外卡组能够在国内得以开展业务。这类公司，业内也称之为Joint Venture(以下简称JV)。与此同时，复杂的组织形式和多方的协作问题以及跨境数据的流动也带来了更多的安全问题。本篇将从架构师视角进行总结，并一探究竟。

0x01 业务篇

这里并不会从市场视角讨论业务，例如：理财，消金，信贷等等；而会关注于支付场景的参与方，以及常见的交易行为。且以下场景均是基于Retail payments 零售支付（Payments between non-financial institutions (e.g. private households, non-financial corporations or government agencies) are normally classified as retail payments.）业务场景讨论的。

1. 支付中的参与方

出于对业务的了解，我们先从日常的几个生活场景来看支付的过程中存在哪些参与方：

• 企业按月将工资存进员工的银行账户；
• 从ATM或者柜台进行取钱，把银行存款变成法币；
• 使用现今购买一杯奶茶，把现金交给店员；
• 使用支付宝或者微信支付等第线上三方支付工具购买一杯奶茶，顾客出示付款码【被扫】，或者【主动】扫描店铺的二维码进行支付从银行卡扣款进行支付或者从余额扣款进行支付（即可以是【主动】扫码，也可以是）；
• 使用美团买券，从银行卡进行扣款。 商户核销券，并给出对应
• 使用银行卡APP进行支付

那在这些支付过程中，显而易见的存在，顾客，商户，支付平台（收单），银行（发卡）。 实际在此背后的则还有一个机构叫做卡组。卡组的主营业务就是负责将对应的支付信息通过对应的路由机制，把相应的数据送到对应的银行里去，并负责完成相应的清结算（包含清分和结算）。在这种模式下，如果发卡和卡组都是一家机构的话，我们称之为三方模式；反之，为四方模式。目前的三方模式的有Discover，AMEX，四方模式的有Visa，MasterCard和银联。

该图引用自European Central Bank的Payment System一文，详细参考见附录。另关于模式不同的详细介绍可以参考之前做的电子支付基础系列分享。两种模式各有优劣， 三方模式虽然重资产、成本高。但由于其介入了支付产业链经营，所以能够直接控制发卡和收单业务，并提供更全面的金融服务。而四方模式定位于支付网络经营和系统建设，生态和规模更易扩展，不仅可以降低服务成本，还能促进行业发展。但需要与多个发卡行和收单行合作，沟通协调成本可能较高。

2. 交易是如何进行的

一笔经典的交易，分为两部分： 授权（Authorization）和清结算（Clearing & Settlement）。这里的交易，并非完全指pay for something,比如借记、贷记的业务类型。而是指发了网络里发生了一笔transaction。在这一笔transcation中可能包含签约、解约、余额查询、退货、通知等业务类型。当然从支付是否需要卡片，这些类型的业务交易还可以区分为持卡交易(Card-Present)和无卡交易(Card-Not-Present)。另外常见的支付协议有ISO8583，ISO20022以及国内独有的以XML表示业务类型以及HTTPS通讯的协议（下文简称XML支付协议）。回归到业务流程本身，我们来看一下授权场景中的流程：

让我们抽象一下，实际就是：

而Acquire System可以是Pos、SoftPos， mPOS、Virtual Terminal， 亦或是Payment Gateway。而实际Acquire system从发起Request到接收到Response的Transaction LifeCycle也不仅如此。在此不再做介绍。

3. 利润是如何分配的

你有没有注意到，无论是在京东购物，还是美团买券，亦或者在携程付款，各个平台都会优先采用自己的支付平台。京东支付，美团支付，程支付，小米支付，Oppo支付等等；

在完成一笔交易的过程中，顾客支付给商户的金额并不会全部最终到商户账户中，通常还包含着通道费，品牌费，手续费，跨境交易费等。而根据费改后机制，如果只考虑手续费，且假设收单机构以5ps分润为例，1亿元的交易中，收单侧可以获利5w元。另根据人行的2024年支付系统总体报告，网联平台的日均交易额在1.42 万亿元（日均处理业务 28.27亿笔）。2023年共处理497.90万亿，2024年共处理520.5万亿元，同比增长4.54%（银联的支付则同比下降8.61%，日均处理业务9.14亿笔，为6979.66亿元，两者一个是处理日均万亿，一个是处理日均亿元）。那么也就是对于三方支付平台，每天分得的蛋糕在7250万元左右。不过根据商户类型的不同，费率可能有所不同。但总体来说这依旧是一个每年高达百亿的市场。而且根据最新公示，国内大概有170多家持牌的非银支付机构。而以头部电商、社交业务所衍生的支付平台更是占了大头。无论是出于业务的竞争，还是开展金融业务。电商平台配备自己的支付系统似乎也成为了标配。另外就是这些企业的入场方式，大概率是收购一家持牌公司，逐步注资到完全控股。而除了手续费，对于平台促进的消金业务更是盈利大头，京东白条，蚂蚁花呗，美团先付后花（我难道点个拼好饭都要先付后还？）。在消费主义的促进下，金融证券化工具被玩的眼花缭乱，最终用户的信息以及债务早已不知道被卖了几手。

0x02 技术篇

清算网络出于行业的特殊性，必然不会有非常先进的技术。且出于对支付网络的职责和上下游依赖，保持7x24h的运营也更加的重要。接下来，从多个维度来看在网络中发生了什么？

1. 协议：业务是如何转换为数据流的？

如前文所说，国内的支付系统中，主要基于以下两种协议完成交易：分别是ISO8583支付协议，和XML支付协议。前者基于TCP/IP协议，后者则是基于HTTP/S协议。

从图中也不难看出，收单机构会根据持卡交易还是无卡交易将对应的交易信息上送至网络（即所谓的前置，不过网络侧的前置一般是收单侧的后置，网络侧的后置一般是对接发卡侧的前置），其中无卡支付甚至需要复用已有的8583交易链路。而ISO8583并不是一个新的协议，你可以在下图之中看到，其最早创建于1987年，而最新的版本也是在2003年。其设计的方式是通过bitmap的形式，为每一个标志位设置为不同取值的方式，来完成对业务的mapping。从图中也不难看出整体的消息结构为MTI-BitMap-Data。具体的信息可以根据下图进行学习。

其中针对字段的保留，取值，以及消息的类型（单双消息）设置也不尽相同。比如AMEX采用双信息交互，即授权和请款分为两次，银联则采用一次请求即可。所以即便采用同一种ISO8583的协议，但出于属地化的不同，和卡组的设置。也仍需进行一定的转换。

XML本身不打算在此介绍，毕竟不具有代表性，但出于文章完整性考虑。仍放置此处。其主要通过XML的字段对业务进行Mapping，并通过HTTP/S协议进行交互，但是也如前面所述，一定情况下，该类报文仍会被转换为ISO8583完成后续的switching，这是出于历史考量的设计，虽然并不是最优的设计。

另外ISO20022没有在此处介绍，ISO20022也是基于XML Schema的，但相对更加规范。XML本身一是可以携带更多的信息，二是所有的数据更易读。从国内的XML协议可窥一斑，不同国家domestic的支付协议也不尽相同。基于两大需求，在Swift的推动下，国际批量支付的已经逐步向ISO20022切换，感兴趣的可以自行了解。另外随着新技术的发展，协议也是在发展，前段时间在学习CBDC的过程中，发现BIS也通过mBridge项目使得各国CBDC得以互换。其中涉及的细节感兴趣也可以了解一下。

2. 网络：如何链接到清算数据中心？

这篇地方的网络终于回归到技术人理解的网络了，没错就是IT含义的Network。数据的交互无论通过什么协议进行总是要经过传输的。在清算网络中出于对安全性和稳定性的要求。往往会要求机构（此处代指发卡侧和收单侧）通过专线和前置机的形式链接到网络中去。更有甚者，存在前置机房以供机构参与者接入。前置机有的会完成一部分针对OS的基线控制等，或者是定制的OS，当然有的前置机可能只是部署一套特定的应用程序（例如部分银企直联的前置系统）。

然而即便在国内的推广两地三中心模式的情况，实际展业的过程中，也仍然存在单区域单机房的展业情况。至于为何，不得而知。另外除物理的专线外，在网络协议层面，还可以通过IpSec协议进行链接。而如果需要维护网络层面的高可用，则一般是多路专线，并选择不同的运营商。或者是一路专线，一路IpSec VPN打通，这取决于卡组对接入网络的要求。而回归到清算网络本身，也会基于主流的网络架构实现高可用。以Spine-Leaf架构为例：

而如果是存在多个机房，则又通过各自机房的border leaf交换机进行专线连接，以实现稳定的传输。

这样每个DC有两个可确保不会发生任何边界Leaf故障而导致DC被隔离。即便单个DC网络故障，应用和服务仍然可以故障转移到幸存的DC，利用VXLAN EVPN提供的扩展L2/L3网络。对网络更底层的知识，我没那么专业了，就不在此班门弄斧了。如果有兴趣，可以通过阅读华为最新AI数据中心网络架构进行系统化学习，对比一下，AI化的数据中心和金融数据中心的区别。

3. 应用：有哪些核心系统和周边系统？

前面讨论了业务通过ISO8583协议和XML协议进行mapping，并转换为数据流。然后通过可信网络（专线、IpSec等）进行TLS传输，那么针对核心的Switching和Clearing & Settlement之外，有哪些系统支撑业务的完整运行呢？让我们继续一窥究竟。

首先从系统维度来看，整体以清算网络的核心（转接和清算）并围绕核心建立起来的系统。如下图所示，转接部分已在前面部分讲过，不再赘述。清算部分关系到资金的清分和结算，因此除却资金划付系统、清分系统，还有文件收发系统、支付标记化系统、差错系统、风险系统等。当然风险系统同时也会作用于转接过程，即所谓的实时风控。在整个过程中文件收发系统作为网络内的上游数据系统，收集来自不同源的数据并给到内部系统进行消费。数仓/大数据作为数据中台经过对数据的处理提供给其他业务系统进行消费。

在上图中，作为2B业务，清算网络也只是服务于机构。但是在三方模式之下，卡组在权益相关的优势就体现出来了（前提是权益真有优势才行…..），卡组同时也会面向持卡人服务，即开始存在2C的业务。而围绕着服务持卡人则又引申出了一系列新的系统。包含营销活动管理、用户行为分析、内部的风险管理、黑名单的筛查、对账计费等系统。而清算网络也由此围绕着机构和持卡人开展相应的业务。

最后从应用本身来看的话，其实没太多好讲的。不想去讨论什么先进的还是合适的。如果单体架构能够适应稳定性的情况下，当行业业务属性不需要快速扩容和迅速迭代的话，也无关紧要。只是无论单体架构还是SOA，亦或是Event-Driven（个人私下认为这几种架构更适合支付类业务场景），都能够满足需求即可，但这并不意味着，仍然使用jsp，asp去编写一些程序，即便抛却UI的古老风格，也需要去考虑一下满足202X年代的一些基本实践。更不用提抽象出什么公共框架和组件了，这也是为什么一些简单的改造动辄都需要数百万至数千万，实际不过是政治遗产下的木偶戏罢了。

0x03 安全篇

这里我们暂时不再关注针对整体的安全设计，而是通过交易和支付的视角来看其中的安全控制，感兴趣的话可以翻翻前面写安全架构的博客。也可以参考金融安全架构设计中的反思

金融支付中的一些解决方案图在绘图时往往会用两种流表示数据，一种是信息流，一种是资金流。信息流基本是包括交易指令、账户信息、支付状态、验证信息等。资金流则是指在支付过程中实际资金的流动。但无论是哪种流，实际都是数据在流动，这也是清算网络中对安全更为敏感的部分。而对数据的保护则主要以密码学为基础，通过对成密钥加密，PKI体系，和混合加密三种主要技术领域进行。这里就只讲讲基础的证书和密钥了（其实是画图也画累了💤）。至于支付标记化（Tokenization，还是挺重要的）是加密的另一种应用方式，以及3DES和AMEX基于3DES的SafeKey如何使用生物认证完成授权动作后续再讲。

1. 证书与无卡快捷支付

• 针对XML报文启用证书完成HTTPS传输加密
• CSR直接从HSM产生
• 证书来自公签CA
• 使用证书校验证书的有效期，及CRL列表，及证书链
• 签名验签和加密解密的Key Usage分离，做成两张证书
• 加密解密的证书私钥来自CA
• 对敏感信息使用加密证书进行加密
• 在报文尾部针对报文主体进行签名
• 发布网络的验签证书给到所有机构，并加载所有机构的验签证书

其余具体使用流程可以直接参考上图即可。其他的还需要关注证书在卡片上的应用，如何通过证书实现防伪；以及如何通过证书完成相关运营系统的登录认证；如何通过硬件Key进行灌注确保私钥的安全等。

2. 密钥与传统持卡交易

关于密钥与持卡交易，如果只想大致了解，可以参考此图：

详细了解，则需要参考下图：

• 在HSM中创建对称密钥，并通过密钥信封分别快递给对应接收人
• 接收后将两到三个密钥信封的分量合并导入到接收方HSM中，使用各自机构的主密钥进行保护
• 双方分别各自同步该密钥到各自HSM集群中
• 根据密钥进行派生出工作密钥，即Data Key，包含Mac Key和Pin Key。并用于加密对应数据及生成对应MAC值（HMAC）
• 根据约定的填充方式针对ISO8583报文启用关键字段加密，或针对Full Message进行加密
• 接收方根据报文校验值进行检验
• 卡组针对收单侧信息进行解密后，在向后的路由过程中使用发卡侧预先同步的密钥进行加密

其他需要关注的还有如何通过混合加密体制，例如非对称包裹一次性对称密钥；以及PGP的应用等，及如何通过使用Key Block格式（TR-31格式）使Key本身具备使用约束，并能够更安全的完成密钥同步等。关于TR-31的知识，请参考ANSI X9.143-2022。

0x04 运营篇

之前的博客曾提到过，传统金融行业中更加注重流程的管理及运营，以此实现安全和稳定的目标。清算网络则更胜一筹，对既有流程运营的依赖更是根深蒂固。出于有限的市场参与者，这使其整体处在了一种“又不是不能用”的运营水平上。就像有人会说：只有几十家接入机构的情况下，为什么还要用DNS，而不是全部硬编码IP。这个理由看起来很充分，做好台账就行了嘛！

1. 从机构入网开始

无论前文中针对密钥的分发还是证书的交换，亦或是专线的接入。这些动作最早发生在机构接入清算网络的过程。（后续存在的定期更换放到下一小节）。

• 资质审核与协议签署： 这里需要入网机构提供一系列的凭证资料，合规资料。例如持有相应的经营许可证，具备反洗钱措施；
• 关键资源申请及配置： 包含了从机构代码（作为清算网络中的唯一标识）的申请，到卡BIN的申请，清算信息的配置等等；关键平台的权限申请，例如商户管理平台，差错管理平台，风险管理平台等；
• 背书及认证： 终端要做认证，卡片要做认证，机构要过一些合规的认证（PCI-DSS认证，UPDSS认证，等保认证等）；
• 密钥及证书： 签名验签的证书申请，双应用证书的申请，平台运营用户的登录证书申请等；
• 接入及系统调试开发：开始物理链路专线接入，然后根据离线测试（本地测试），联机测试（类似UAT），Beta测试（类似线上测试）
• 投业

注意，以上步骤仅为列述，并非强烈依照时间先后顺序进行。但这些步骤强体现了如何多部门协作下的复杂运营以及台账文化共同支撑了机构入网直至展业的整个过程。 其中几乎每个流程都需要多部门/多节点的审批，常规情况下每个流程5个工作日能审批完已经不错了。这并不是说效率很高很严谨，也不是说大家很忙或者没事干。

2. 流程及流程例外

有流程，则一定是有例外管理。流程的运营固然能起到安全的控制作用。但实际上因为流程只能限定在自己的企业部分（一般不能侵入到别的企业中，或者话语权非常强）。而在这种情况下，安全控制中流程的不对等性间接导致了安全的不对等性，进而导致安全控制失效。 就像我之前博客曾记录过的，网络通过严格的密钥管理员机制多路寄出密钥信封给到机构A，对侧机构虽然两个人接收了，但是两个人拿到一起，拆开，输入到TXT文件，拍照给你。复核的流程确实严谨，只是用错了方法。所以及更应通过技术来确保，而非流程。

日常的运营过程中，很多流程都是依赖于台账，通过归档Excel申请表，营业执照复印件来记录台账；通过加盖公章来说明效力，通过多个部门参与来分摊责任成本，通过自签署声明表示知晓，并通过合同后约束法律效益。但这种流程不能深究，他不像1是1，2是2这么有板有眼，任何流程的实现都有操作的空间，有时候甚至无法说明流程的必要性及有效性。更多的流程及例外需要自行思考是否有效。先做后补流程？更新流程的参与范围？如何评定流程的有效性？当然也有一些业务流程的设计非常漂亮，例如Global Authorization Network的失效会自动传输数据到GAN Issuer Gateway。

3. 监管及监管合规

监管是金融行业参与者的生死线，给你例外能让你整改，不给你例外那就难堪了。此处话题高端，不做讨论。仅通过一些监管的项目来说明对安全的重要性。不一定是技术安全，既可以是流程上的，也可以是资金上的。仁者见仁，智者见智。

• 断直连：人民银行“断直连”工作要求，第三方支付机构全部接入银联或网联系统，商业银行与支付机构之间的业务，城银清算有限公司和农信银资金清算中心成员机构与第三方支付机构之间的业务不再计入商业银行行内业务系统、银联清算支付清算系统和农信银支付清算系统业务量统计。
• 商密改造工作：算法迁移到SM4，SM2
• 商户信息报送：三方支付报送商户信息
• 交易个人隐私信息数据保护： ISO8583报文敏感字段加密，XML报文敏感字段加密

除此之外，还有一些行业相关的合规：

• PCI-DSS对Key Blocker的改造需求
• JRT每年小检，三年大检
• 数据出境安全评估

以及其他监管部门的一些需求，例如三高一弱的排查，护网演练等。还有一些是法案和标准的修订，例如最近在网络安全法的修订草案关于公开征求《中华人民共和国网络安全法（修正草案再次征求意见稿）》意见的通知，银行卡清算机构管理办法的征求意见稿等。历史中还有双联互备等项目，使得网联和银联互相存在一部分最小化的对侧系统（我是道听途说），确保了金融安全。

0x05 总结

关于卡组，我本想从Business Model、安全、文档完备、接入和测试、开发者友好和生态增值服务几个维度细致对比一下几个卡组的特性来收尾。由于话题较大，故在本文中放弃。但最终还是把下AMEX，VISA和MasterCard这三家国外的卡组的业务模式进行了对比。（该图来自网络信息公开整理所得。）并在后续中以个人喜好简单进行阐述。

对于安全部门值得关注的一点就是，安全部门在清算网络中可以通过增值服务来体现价值。这一方面在MasterCard体现尤为突出，且带来了17%的YOY增长，并达到了2.3万亿$的收入。另出于当下万事达同网联（NUCC）合作成立万事网联，以及美国运通（AMEX/AXP）和连连成立连通并同银联（CUP）合作，以及银联国际做为银联一部分的基础上。技术上NUCC具有后发优势，UPI则比较和国际接轨，并跟进了国际标准的新需求改造，进而反哺了CUP（或许）。从文档维度，技术方面个人更喜欢Visa和MasterCard的风格，尤其是MasterCard的Blog。尤其是两者的开发者网站。当然从学流程的维度还是AMEX写的最好。而对比Spec和BOP文档，其实不好判断哪些已经实现了API Gateway。不过看起来AMEX得GNS和Visa的VisaNet应该已经是在API Gateway的形式上演进了。另外接入方式上，国外的卡组对IpSec的方式还是比较包容的。

关于跨境支付，对于三方支付一般是通过代理行的模式进行资金的划转。而对于清算网络/卡组，则还有另一种方式，就是其通过属地化的清算中心，完成交易信息的转接。例如外卡内用以及内卡外用。国内银行发行的卡片在AMEX Global进行收单，之后通过网络转接（就是前面提到过的单双信息转换）送还给到国内的网络，并传递给对应的发卡行。反之亦然。对于批量支付，可以关注一下CBDC的应用。

关于JV企业，JV企业就像是景区里的油菜花，品牌形象良好，但细看油菜花地里已经是杂草丛生。等真正看到农民伯伯种的油菜花，又猛然意识到，长的又细，结的籽又少。好在只是充当门面，吸引游客光临就行了。

关于技术趋势，Crypto Agility提了很久了，终于逐步面临落地。当证书有效期逐渐缩短至40多天的时候，将迫使一切自动化起来。另外针对国内做国产化改造的趋势，如何完善生态和建立起有质量的周边服务才是更重要的，可以自己玩，但玩到最后不应该是闭门造车，而是和国际接轨，甚至做的更好。

最后，第一次动手写大概是在2024年2月，但每次去写时愈发感觉自己缺乏的知识很多，于是转而继续学习。后来每隔几月总结一些，但仍然无法去写。直至今年初重新整理相关内容，并给自己限定于从整体视角去看安全相关内容，才开始继续更新这篇。终于从3月25日再次开始直至今天（20250405）搞定。不过限于学习到的知识，如有理解疏误，还请不吝赐教ZnpAY2lzby5jaGF0 （Base64 编码）。最后的最后，文章里的时序图先是自己撰写流程，然后通过AI针对流程描述生成PlantUML代码，最后调整代码，绘制所得。UML参考此处 。总体还是快了不少，但有时候图中参与者的顺序，和流程也会经常出错。

附录: 参考资料

原文始发于微信公众号（放之）：一文了解清算网络：业务、技术及安全