支付域——互联网支付系统设计背景

未经同意窃取和转载我的内容，如果涉及到权益问题，后果自负！

本文链接：https://blog.csdn.net/weixin_41605937/article/details/143134645

摘要

支付体系作为现代金融的重要组成部分，承担着资金流转与经济交易的关键职能。随着科技的发展，全球支付方式迅速演变，尤其是在中国，移动支付、互联网支付等新兴方式已广泛应用。传统的现金、银行卡支付逐渐被数字支付所取代，支付宝、微信支付等第三方支付机构成为主流。支付体系的运行依赖于央行、商业银行、支付机构等多方协作，确保资金清算的安全与高效。与此同时，监管机构对支付的规范与管理也在不断加强，以保障支付市场的稳定性和创新性。

1. 宏观角度看互联网支付系统

我国支付体系庞大而复杂，从用户发起支付到央行清算账户完成最终结算，涵盖了多层次、多参与者的协同运作。要深入理解整个支付网络，我们可以从用户视角出发，跟随一笔支付的路径，遍历互联网支付网络，获得对支付体系的宏观认知。那么我们研究支付宏观，可以站在央行清算账户位置，俯视整个支付金字塔，如图所示：

对于我国的支付体系来说，一笔支付从用户为起点开始，经过众多支付参与者的协同配合，最终到达央行的清算账户，完成资金的最终清算。可以将央行的清算账户视为支付的终点，电子货币结算资产即为支付的最终结算形式。因此，研究支付体系的宏观结构时，我们可以站在央行清算账户的位置，俯瞰整个支付系统架构。

在支付系统中，支付平台、支付机构和人民银行承担了不同的角色和功能，各司其职，共同保障整个支付过程的顺利进行。

支付平台

支付平台作为连接消费者与商家的中介，提供交易技术支持与服务。通常包括在线支付、移动支付、跨境支付等功能。
支付平台通过为用户提供便捷的支付服务，使商家能够迅速接收到资金。
平台必须确保交易的安全性、用户数据的保护，并符合相关的法规和监管要求。

支付机构

支付机构是提供支付服务的公司，如支付宝、微信支付等，负责处理支付请求、资金结算和清算。
支付机构需要获得监管部门的许可，确保其支付业务的合法合规。
这些机构通常也提供增值服务，如数据分析、营销支持等，来增强用户体验和商家合作的效率。

人民银行

人民银行作为中央银行，制定并实施货币政策，对支付系统进行全面监管。
其职责包括维护支付系统的稳定性和安全性，监督支付机构的运行，推动支付创新发展。
通过有效监管，人民银行确保支付市场的公平竞争，保护消费者权益。

支付分层是将支付系统划分为多个层次或模块，每个层次承担特定功能和责任。这种分层架构有助于提升支付系统的灵活性、可扩展性和安全性。

支付分层的作用

功能模块化：将支付流程分解为独立模块（如支付处理、资金结算、风险控制等），各模块专注于特定功能，提高效率。
灵活性：各层次可以独立开发和升级，适应市场变化与用户需求。比如，可以快速集成新的支付方式。
安全性：不同层次实现不同的安全措施，传输支付信息时通过加密通道处理，结算层则专注于资金安全。
风险管理：在特定层次进行风险控制和合规检查，及时发现并处理潜在风险。
互操作性：各支付模块能与银行、第三方支付机构等系统高效对接，支持多种支付方式。

支付分层的好处

可扩展性：随着业务增长和市场变化，支付系统可方便地添加新功能或支付方式，而无需重构系统。
维护成本降低：模块化设计使系统维护和更新更加便捷，降低技术债务和长期维护成本。
优化用户体验：通过对不同层次的优化，提升用户支付体验，减少支付失败率和延迟。
快速响应市场需求：支付分层可以更快地响应行业变化与技术进步，帮助企业保持竞争力。
便于合规与审计：各层职责清晰，便于合规检查和审计，提高系统透明度。

电子支付的实现依靠众多参与者的协同合作，包括为线上交易提供支付产品的第三方支付机构、提供支付通道的商业银行和网联银联、负责最终跨机构清算的央行等。每一笔支付都不仅仅是通过一个平台完成，而是在不同机构的系统之间进行信息传递和处理。从用户在支付平台发起支付，到支付通过多个支付参与者的系统传递，最终在央行完成清算账户的资金结算，整个支付网络的顺畅运行依赖于各层次、各参与方的合作与协调。如图：

1.1. 互联网支付平台

京东购物，美团点外卖，支付宝转账，去哪儿买机票去旅游，好产品让生活变得更便捷；那么我们称该层为互联网应用层，这一层为用户直接提供服务，和支付能力。这些平台为用户提供各式各样的商品或者服务，是直接面向用户的互联网应用；用户在平台购买服务，平台就需要有自己的支付体系来支撑支付业务，比如需要收银台、交易体系、服务履约等。

这个业务架构模型适用于像美团、去哪儿、滴滴、京东等这样的服务平台，当然实际情况要比这个架构复杂的多，但是其核心骨架高度抽象以后基本如此。如果你要从零到一做一套支付体系，那么这么规划完全可以。

商家如果要实现线上支付，都需要接入一个支付机构的，支付系统通过支付通道将支付请求提交给了签约的支付服务提供方，我们以三方支付为例，比如京东将支付提交给了网银在线。那么网银在线内部又是怎么处理的呢？将在做详细介绍。

1.1.1. 服务平台支付架构

刚才我们说从电商平台买了一本书，那么一个典型的电商平台的支付架构是怎么样的呢！一笔支付在这样的平台内部是怎么流转呢？如图是一个比较典型的电商平台的支付架构：

选好商品提交订单以后，平台在订单中心完成订单的创建，订单在交易中心完成账单的创建；我们操作去支付，交易请求支付获得收银台链接，给到订单，订单再将收银台链接返回给我们，这时候用户选择了用招商信用卡支付，输入支付密码，一瞬间支付成功！然而，这几秒钟整个支付的链条跋山涉水，翻山越岭经历千险，经过非常多环节和复杂的处理。

1.1.2. 支付架构中支付部分

我们看上面的架构图，对于一个服务平台的支付架构，一般有图中的相关系统组成：直面用户的收银台，记录业务的订单系统，推动交易的交易系统，对支付指令进行处理的支付系统，支付指令传送通道的支付通道子系统。

1.1.3. 支付架构清结算部分

另外，支付成功后还有一条线清结算线，支付成功以后交易将数据提交清算中心完成数据的清分计算，然后提交账务系统完成记账；再通知会计核心完成内部账的记录；最后对商家进行结算付款，如图所示：

1.2. 三方机构的支付服务

支付机构作为拥有支付牌照，为服务平台提供支付解决方案的企业，也有着自己复杂而庞大的支付体系，我们常听说的比如各类收银台，支付产品，支付路由，支付通道，支付核心，账务核心，清算核心，风控核心，商户入网等等，这一部分我们来研究解析三方支付机构的支付架构。

对于一个支付机构来说，他们的支付架构是什么样的呢？比如刚才支付请求到了支付机构，这笔支付在支付机构会怎么流转和处理呢？如图所示，是典型的支付机构的支付架构图。

上面这个稍微简单点架构图基本涵盖了一家支付机构应该具备的基础能力；比如交易层对交易请求进行处理；支付层对支付请求进行处理；渠道层对支付请求进行提交金融机构或者清算机构完成最后的清算请求指令的处理。既然都是支付，我们可以换个思路，其实支付机构的支付架构跟服务平台的架购在某些角度看大同小异；只不过是服务用户对象一个是用户一个是商户，支付通道一个是三方机构提供，一个是银行提供。下面我们对支付机构的架构进行拆解分析。

1.2.1. 支付接收

支付请求来到了三方支付机构之后，第一个门槛就是到达支付机构的网关层，通过各种风控校验通过许可，来到开放平台，开放平台将支付请求提交给交易处理层进行处理，首先到达订单系统，创建订单后请求支付系统获得收银台链接，返回给开放平台；开放平台处理支付通过收银台请求支付系统进行支付处理，这个过程如图所示：

1.2.2. 支付处理部分

支付处理中心对支付请求进行处理，通过路由选择合适的支付渠道，然后由渠道清算封装支付指令，通过支付通道提交清算指令给清算机构或者银行，该部分如图所示：

1.2.3. 支付清算

清算机构返回清算成功后，支付处理中心通知订单中心支付成功，订单中心将支付单提交给清算中心进行清结算处理，完成计费、清分、记账等处理操作，如图所示：

我们将支付部分和清结算部分的架构合并到一起以后，就可以得到一个支付机构典型支付架构，如图所示：

支付机构将支付清算指令提交给了清算机构，因为现在断直连了，不能直接接入银行；断直连后其实银联网联网关于支付清算的处理是一样的，看看支付指令到了清算机构之后会怎么样的呢。

1.3. 清算机构清算服务

有幸参与了支付机构断直连接入网联的项目，参与了很多场网联的会议，惊叹于断直连后的清算架构和设计理念！我们先看图，从宏观上认知这几个角色之间的关系。

为解决备付金集中存管所形成的热点账户问题，实现对已映射额度管理，网联构建了“备付金热点账户前置系统”RCMP,用于支付机构通过网联平台(EPCC)的业务办理。前置系统分为额度管理模块及账户管理模块，网联为各支付机构在前置系统中建立账户，用于可用额度的监控、已映射额度的管理。

支付机构的指令到了网联以后，网联进行实时清算，什么意思呢，就是实时的对支付指令进行轧差变更可用余额，简单的说就是支付机构将人行备付金的余额映射分配给网联和银联形成映射虚拟额度，用于交易周期内的实时清算；然后定时提交人行进行资金的划拨结算，这个框架如图所示：

断直连以后网银联的清算变得大道至简了很多，说到清算我们有必要说一下银联这个老牌清算机构的清算业务，介绍下清结算相关的几个重要的概念以及银联清算架构的简单解析。

1.3.1. 清算概念

支付结算是指单位、个人在社会经济活动中使用票据、信用卡和汇兑、托收承付、委托收款等结算方式进行货币给付及其资金清算的行为。银行是支付结算和资金清算的中介机构。

支付清算是指支付指令的交换和计算；支付指令是指参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令；支付指令的交换是指提供专用的支付指令传输路径，用于支付指令的接收、清分和发送；支付指令的计算是指对支付指令进行汇总和轧差；参与者是指接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构。

银联的支付清算包括清分和资金划拨两个环节。清分是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？资金划拨是指通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。

1.3.2. 银联的清算架构

银联的支付清算包括跨行清算和收单清算。跨行清算是针对收单机构和发卡机构的清算；收单清算是代替收单机构针对商户和收单专业化服务机构的清算如图：

银联清算系统主要就是三个核心：跨行清算子系统、收单清算子系统、资金管理平台，如图：

1.3.3. 银联的几层清算关系

清算离不开一个核心，那就是清算账户，所有的支付以及清算都是基于账户进行账务处理清算账户与结算账户不是同一概念，两者的区别源于清算与结算的区别。银联境内清算的清算账户均开立在人民银行，跨境业务的清算账户开立在代理清算银行（中行和汇丰），境内成员机构的清算账户均开立在人民银行。银行一般在人民银行开立有准备金账户，一般使用其备付金账户用于和银联的清算，境内商户的结算账户开在商业银行，第三方机构的结算账

户均开立在人民银行。

银联如何进行资金的划拨呢，境内的跨行清算通过央行的大额支付清算系统，完成资金划拨。银联可以主动借记或贷记成员机构的清算账户。通俗地讲，借记就是我问别人要钱，贷记就是我给别人钱。

银联清算系统与大小额支付清算系统的关系是这样的，无论是跨行清算还是收单清算，银联都是作为一个特许参与者，加入大小额支付清算系统，完成银行卡交换业务的资金划拨。银联通过大额支付系统，实现与境内成员机构清算账户之间的双向资金转移。银联通过小额支付系统和当地的票据交换系统，实现与境内第三方机构和商户之间的单向资金转移。

银联清算系统与银行结算系统的关系，银联和商业银行都是作为参与者，加入大小额支付清算系统，完成跨行间的资金划拨。银联清算系统的清算对象是成员机构、第三方机构和直联商户。商业银行结算系统的结算对象是在其本行开立存款账户的单位或个人。银联在央行开立的清算账户从本质上说应属于备付金账户；而商业银行在央行开立的清算账户分准备金账户和备付金账户。准备金账户主要用于监管使用，用于包括存款人合法权益；备付金账户主要用于自身的资金头寸的管理。

银联清算系统与银联会计核算系统的关系，银联清算系统处理的是银行卡交换的清算资金。银联会计核算系统处理的是银联的自有资金，其中自有资金中包括了银联自己清算账户上的资金余额，银联会计核算系统是按照企业会计准则，使用总分户账，登记账户变动及资金转移信息，银联清算系统仅建立了清算资金的台账信息，二者的关系如图所示：

1.4. 银行支付体系

银行是金融机构，相对于服务平台，三方支付机构以及网联这样的清算机构是有很大不同的，首先是业务的不同，银行除了提供互联网支付通道以外，还有门店，ATM,银行卡，存款业务，贷款业务，理财业务等等，业务汇总如图，业务间的关系可以如下所示：

抛开繁多的银行其他业务，我们来看银行跟互联网支付相关的业务架构是怎么样呢，其中也必然包含账户，支付核心，通道，前置系统等，典型的银行内部业务架构如图所示：

1.5. 人民银行支付体系

我国支付系统经历了支付一代系统和支付二代系统；为整个支付提供清算基础设施；我国支付清算体系全貌如图所示：

最左边的就是银联以及三方支付机构所处的位置，上面的就是我们要讲的人行部分，下面是银行所处的位置；其中银联和商业银行直联央行的支付清算系统；我们来看整体的业务架子就是，各参与者连接到NPC就是国家处理中心，或者连接城市处理中心CCPC,包含了大小额支付系统和网银互联跨行支付系统（超级网银），然后PC经过支付指令的处理之后提交清算账户中心(SAPS)进行资金的清算划拨。

1.5.1. 二代支付系统

二代支付系统最核心的几个系统，如图3-23所示，涉及到清算账户系统、大额支付系统、小额支付系统、网上支付跨行清算系统、支付管理信息系统、支票影像交换系统等。

这几个系统以清算账户管理系统为核心，大额支付系统、小额支付系统、支票影像交换系统、网银互联子系统为业务应用子系统，公共管理控制系统和支付管理信息系统为支持系统，共同构成了二代支付体系。

清算账户管理系统(SAPS):是支付系统的核心系统，通过集中存储和管理清算账户，完成支付系统各类业务的资金清算，并为中央银行办理现金存取、再贷款、再贴现等业务提供清算服务；各银行，支付机构，网联银联都会在这里开通清算账户，进行资金的清算

大额支付系统，小额支付系统，网上支付跨行清算系统接受参与者的清算支付指令，进行指令的处理并提交给清算账户管理系统完成资金划拨；在网上银行端发起跨行的付款请求，假设金额较小走了小额支付系统，业务流程如图所示：

支付信息管理系统：是中国现代化支付系统的辅助支持系统，由行名行号管理子系统、参数管理子系统、计费管理子系统、支付业务统计分析子系统、支付业务监控子系统等六个子系统组成，是一个多功能模块的、集中式的支付信息共享平台，如图所示：

1.5.2. 支付清算处理

网联将结算请求提交给人行支付系统之后，支付系统对指令进行处理之后提交清算账户系统，完成最终的资金结算；这个时候开始买书的那笔钱才真正从招商的清算账户进入到网银在线的备付金账户中，如图所示：

通过以上分析和拆解，整个支付体系的每一层参与者的架构都做了一个宏观的认识，一笔支付要经历多么漫长的链条，最后将所有的参与者架构拼接到一起，构成了一座美丽宏伟的支付大厦。

2. 微观角度看互联网支付系统

从一次美团外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付微观细节。看下面外卖盒上的小票，牛肉拌饭1份一共39元，餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元；再看美团订单的信息，烤肉饭1分39元，打包费1元，配送费原价7元现价2元，美团会员15元；美团红包减7元，满减优惠14元；总优惠26元，合计36元，如图3-29所示：

图中可以看出商家的小票信息和美团的订单信息之间有不少的差异，特别是优惠的明细展示，以及优惠总额和应付总额之间存在差异；下面我们就来顺藤摸瓜，分析背后的玄机。

我们先认清一个关系，订外卖的用户跟商家没有直接的关系，美团跟商家直接是结算关系，也就是美团帮助商家代收餐费，并进行结算；简而言之就是用户付给美团综合的外卖钱，美团抽一部分然后给商家结算餐费，如图3-30所表达的关系：

粗略的假想一下，这个过程是怎么完成的，用户先到美团平台选择喜欢的“商品”，然后“下单”，生成交易“账单”，用户选择支付方式进行“支付”，支付成功后美团要履行承诺把餐送到，“履约”完成以后美团就开始进行各方利益的“清分”，计算了算清楚应给给各方多少钱时并计人账簿“记账”，然后就是进行“结算”，这个过程如图3-31所示：

下面，基于上面的业务流程，分析小票在每个环节是怎么处理的，都生成了什么单据，单据中包含哪些信息。

2.1. 商品信息

商品广泛用于电商，在O2O领域可能叫“服务”多一点，站在吃货的角度来看，订外卖，买了一份商品也可以说的通；商品模型这里就不过多介绍，简而言之就是图所示的信息结构。

案例中的这单外卖的商品有4个（这里我们将配送服务看做商品），如表所示：

这里需要说一下美团会员，这是美团推出的一个会员服务，相当于花钱买了多张优惠券，如图3-33所示，所以购买美团会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券。

2.2. 订单信息

选购好了商品，接下来就是下单了，这时候交易系统会去营销系统获取可以使用的活动优惠或者卡券，本小票可以看出来，有这些优惠可以使用，见表：

因为目前还不清楚美团和商家之间的清结算协议，所以暂且认为所有优惠由美团提供给用户，后续美团再基于协议跟商家之间做优惠的分摊，这部分不是本节的重点，大家可以私下思考，这样我们就得到了订单信息了，如表所：

示：

订单信息中美团红包是基于15元购买了优惠券以后才能使用的优惠，相当于这一单，用户要先买会员获得优惠券，然后在本单同时使用优惠券进行优惠，虽然是同一个订单，但我们可以想象出来，在交易处理层，至少需要做2次处理，一个是对美团会员的处理，另一个是对本单整单的优惠处理；所以订单需要拆成2个子单，一个是外卖单，一个是美团会员单，如表3-5所示：

商家的小票中显示商品总价是40，总优惠是19；跟订单11101之间的7元差额是什么呢？其实就是配送费，那么将配送费刨除后跟商家小票一致，可以推断出商家承担了5元的配送优惠成本，加上满减优惠14，商家总优惠成本是19.但是，发现商家实收17元，那么这4元是什么呢？这里有2个推断，一是美团抽佣4元，另一个可能是商家承担美团红包7元优惠中的4元；如果是取中间可能的话，那么实际的清分结果可能是如下模型：

4元=x+y
x=美团抽佣；x∈[0-4]元
y=分摊美团红包优惠；y∈[0-4]元

2.3. 交易处理

完成了订单以后就需要创建支付账单了，基于以上分析交易处理相对比较复杂，因为要先处理美团会员的购买，然后处理外卖订单，这个过程如图所示：

因为有2个子单，所以我们生成2个交易账单，但是在支付的时候我们进行合并支付，账单信息如表所示：

有了账单信息以后，基于账单生成支付请求，这里的支付渠道是广义的，优惠券、满减等都视为一个支付渠道，也就是在支付信息层都算做一个支付方式，如表所示：

2.4. 支付信息

账单生成以后，请求支付系统生成支付单，用户在端上通过收银台发起支付请求，其中微信支付请求支付系统；优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样就完成了账单的支付了，这时候账单变为已支付，订单支付状态变为已支付，订单的履约状态变为待配送，支付信息如表所示：

2.5. 履约信息

订单变为待配送时，会生成服务订单，也就是配送订单，由骑手小王01抢单了，这里的服务单信息如表所示：

之后的过程包含了取餐，送餐，确认已送达，服务单完成等，服务单完成以后将订单推送至清算中心进行清分计算，以最终结清各方利益。

2.6. 清算信息

清算系统接收到的清算订单信息包含，订单信息，账单信息，支付信息，履约信息。在计费环节有几个关键的模块，如图：

计费模型就是基于订单业务应该计算出什么样的费用出来，比如本单其实有2个业务，一个是外卖业务，一个是美团会员业务。

假设计费模型是这样的，美团外卖业务需要计算商家应结算金额，抽佣金额，优惠分摊金额；美团会员计费模型需要计算出美团会员费给平台业务的分成，如图：

再基于业务类型，去查找计费规则，即计费参数，计费基数，计费模式，计费规则；设定规则如图3-37

那么计费规则，我们可以计算出以下清分结果：

优惠成本的分摊如表所示：

2.7. 账务信息

完成清分计费以后就需要请求账务系统完成记账，为了简单这里只对商家的结算和骑手的结算进行记账；这时先生成账务记录，如表3-12所示：

入账成功后账户余额发生变化，如表3-13所示：

2.8. 结算信息

商家和骑手都可以在钱包里看到账户余额了，然后可以对余额发起提现；生成提现订单，请求打款中心完成出款，以上整个清结算的流程框架，可以简化成图：

3. 互联网金融支付场景

3.1. B扫C支付场景

B扫C支付，也称为条码支付，被扫支付。就是商家拿扫码设备扫描顾客支付二维码。在零售场景B扫C支付方式居多，用户只需要打开付款码，收款操作由商家操作。顾客在店消费后，收银员在终端POS收银台操作生成支付订单，收银员使用扫码设备扫描顾客APP（微信，支付宝，云闪付）付款码，支付中台在收到支付请求后，会请求上游支付通道。上游支付通道根据密码验证规则来判断是否输入支付密码，输入密码完成支付，或者不输入密码直接免密支付。

刷脸支付，依托于终端设备，通过面容获取付款码。常见的有微信刷脸和支付宝刷脸。刷脸设备其实和B扫C原理类似，只不过之前是设备扫描顾客手机，获取的是手机付款码支付。现在是设备扫描人脸获取一个对应的面部付款码。之后还是调用B扫C接口进行支付。

3.2. C扫B支付场景

C扫B支付，也称为主扫支付，就是顾客扫描商家生成一个带金额的动态码（只支持扫码一次）。由商家根据用户选择的商品生成支付订单，商家点击支付，终端POS副屏会显示一个动态的收款码。顾客扫描收款码，手机APP会跳转到一个带有金额的页面中（金额无法修改），顾客点击支付，输入密码便完成交易。

3.3. JSAPI支付场景

JSAPI，就是预下单支付。顾客先下单后输入账单金额密码进行支付操作。常见的应用场景有两类：

码牌，顾客扫描静态码牌，手动输入订单金额进行付款。
公众号，小程序：顾客用公众号/小程序下单，输入密码进行付款。

其中码牌，主要是小商户，小摊贩使用居多。对于做小本生意购入一个终端POS设备成本较高，使用静态码牌收款方便省成本。当然它的缺点也显而易见，无法查询顾客购买商品详情。

3.4. APP支付场景

APP 支付，就是发生在商家APP内的支付。在商家APP内发起支付时，支付中台会请求上游支付通道，获取预支付信息。商家APP拿到支付预支付信息后，拉起本地第三方支付方式SDK（支付宝，微信等），最终在第三方应用内完成支付。

最终我们将业务抽象出一套围绕支付业务为核心的支付中台。SaaS软件服务商可以借助支付中台打造自己的护城河。作为护城河主要是以下三个原因：

支付能力多业务线共享，节省人力资本，提升产研和运营管理效率。
将原有业务系统支付解耦，统一封装收银API到支付中台系统中，开发能快速兼容新的支付渠道，对接效率极大提升。
支持多渠道切换，手续费，佣金存在优势，吸引商户使用。为公司和代理商获得额外睡后收入，帮商户减少支付成本。

4. 互联网金融核心信息流

4.1. 互联网金融总览

信息流类型	核心作用	依赖关系
资金流	实现价值交换，驱动经济活动	依赖信息流（如交易指令）
信息流	支撑决策透明度与市场效率	依赖技术流（系统处理能力）
风险流	防范系统性风险，保障安全	依赖合规流（监管要求）
合规流	确保合法运营，维护市场秩序	依赖信息流（数据报送）