1997—2001：证券公司为什么必须集中交易#
从营业部本地电脑，到交易主站，再到 KCBP/KCXP#
1990年代初，把一台电脑放进证券营业部，已经是一场技术革命。
但到了1990年代后期，问题已经不再是：
“怎么让一个营业部实现电脑化？”
而变成了：
“怎么把几百家营业部、数百万投资者、多个交易所、多个交易席位、银行、清算和登记系统连接成一个统一的交易网络？”
这正是中国证券IT从“营业部软件”走向“集中交易系统”和“交易中间件”的关键历史阶段。
一、最早的证券电脑系统，其实是“营业部自己的系统”#
在1990年代初，证券公司最自然的技术架构，就是：
营业部 A
↓
本地证券交易服务器
↓
本地数据库另外一家营业部：
营业部 B
↓
本地证券交易服务器
↓
本地数据库再一家：
营业部 C
↓
本地证券交易服务器
↓
本地数据库也就是说：
营业部 A → 自己的数据
营业部 B → 自己的数据
营业部 C → 自己的数据这其实很好理解。
当时：
- 营业部数量有限；
- 投资者数量还没有后来那么巨大；
- 计算机网络成本高；
- 广域网技术不成熟；
- 数据量相对较小；
- 各营业部在业务上具有较强的独立性。
所以：
“一个营业部一套系统”是当时非常自然的技术选择。
二、但是证券市场开始疯狂增长#
问题很快出现了。
投资者数量不断增加。
股票品种增加。
交易量增加。
证券营业部增加。
证券公司开始从一个城市的几个营业部，发展成：
几十家营业部
↓
上百家营业部
↓
跨地区营业部网络于是证券公司开始面临一个非常现代的问题：
“这些营业部到底是不是一个公司？”
从业务角度来说：
是一家公司。但从IT系统来看：
却像几十个甚至几百个独立系统。三、最先爆发的是“客户数据分散”问题#
假设张三在：
上海营业部 001开了一个证券账户。
后来他去了另外一个营业部：
营业部 023希望继续交易。
如果系统仍然是：
营业部 001
↓
本地数据库那么营业部023首先会遇到问题：
张三是谁？
他的资金是多少？
他持有什么股票？
有没有未完成委托？
有没有冻结资金？
有没有冻结证券？因为这些数据都存在：
营业部001的本地数据库而不是整个证券公司的统一数据库。
因此架构开始发生变化。
从：
客户
↓
营业部逐渐转向：
客户
↓
证券公司中央系统
↓
多个营业部四、“集中交易”到底是什么意思？#
很多人看到“集中交易”四个字，会理解成：
把所有投资者搬到证券公司总部交易。
当然不是。
这里的“集中”，主要指：
把原本分散在各营业部的交易处理能力，集中到证券公司的中央交易系统。
原来的架构：
营业部 A
↓
本地交易系统
↓
交易所
营业部 B
↓
本地交易系统
↓
交易所
营业部 C
↓
本地交易系统
↓
交易所逐渐变成：
营业部 A ─┐
营业部 B ─┤
营业部 C ─┼──→ 中央交易系统
营业部 D ─┤
营业部 E ─┘
↓
交易所这就是集中交易最基本的思想。
五、营业部从“交易中心”变成“交易入口”#
这是一个非常重要的变化。
早期：
营业部
├── 客户
├── 账户
├── 数据库
├── 委托处理
├── 风险控制
└── 交易后来：
营业部
├── 客户服务
├── 委托输入
├── 回报显示
└── 打印凭证
↓
中央系统也就是说：
营业部越来越像一个客户端，而不再是完整的交易处理中心。
这是证券IT架构第一次真正意义上的“大集中”。
六、集中交易之后，证券公司内部出现了一条新的数据链#
一个投资者下单：
投资者
↓
营业部
↓
中央交易系统
↓
交易主站
↓
交易席位
↓
交易所成交以后再反向回来：
交易所
↓
交易席位
↓
交易主站
↓
中央交易系统
↓
营业部
↓
投资者所以到了1990年代后期，一个证券公司的核心问题已经不是：
“怎么保存股票客户资料？”
而是：
“怎么让大量交易消息可靠地穿过整个系统？”
七、为什么“交易席位”仍然存在？#
这里必须把“营业部”和“交易席位”分开。
投资者并不是直接进入交易所交易。
基本结构仍然是：
投资者
↓
证券公司
↓
交易席位
↓
交易所交易席位是证券公司进入交易所交易体系的重要市场接口。
早期“席位”还有很强的物理含义。
证券公司的交易员可能坐在交易大厅里的指定位置，通过电话或者终端接收营业部委托。
所以当时经常可以看到：
营业部
↓
电话
↓
交易员
↓
交易席位
↓
交易所八、这时候证券公司实际上同时存在两个世界#
到了1990年代后期，一家大型证券公司的系统可以被理解成两个世界。
第一世界：客户世界#
投资者
↓
营业部
↓
客户账户
↓
资金账户
↓
证券账户
↓
委托第二世界：交易所世界#
委托
↓
交易主站
↓
交易网关
↓
交易席位
↓
交易所
↓
成交回报真正复杂的地方就在中间：
客户世界
↓
???
↓
交易所世界这个“???”就是证券中间件开始发挥作用的地方。
九、证券中间件究竟是什么？#
简单说：
中间件就是把不同系统连接起来，同时把底层通信和协议差异隐藏起来的软件层。
例如：
证券公司核心系统
↓
中间件
↓
交易所接口证券公司的核心业务系统不需要直接处理所有交易所底层协议。
而是：
证券业务系统
↓
统一内部交易消息
↓
中间件
↓
交易所专用消息这就是证券中间件的基本思想。
十、为什么不能直接用一个网络连接解决？#
因为：
“网络连接成功”不等于“交易成功”。
例如TCP连接成功，只能说明：
两台机器可以通信。但证券交易真正关心的是：
委托有没有发出去？
交易所有没有收到？
交易所有没有接受？
委托有没有被拒绝？
有没有成交？
成交了多少？
成交价格是多少？
这个回报是不是重复的？
网络断线后应该怎么办？所以证券中间件不能只是一个“网络转发器”。
它必须理解：
订单
成交
撤单
回报
确认
拒绝
状态十一、一笔订单其实远远不只是“买1000股”#
例如投资者说：
买600000
1000股
10.00元对于证券系统而言，还必须知道：
客户编号
资金账户
证券账户
营业部
委托编号
市场
证券代码
价格
数量
委托类型
时间
交易席位所以系统内部可能形成类似：
客户
↓
账户
↓
委托
↓
路由
↓
席位
↓
交易所中间件需要负责：
验证
+
路由
+
转换
+
发送
+
接收
+
状态管理十二、这就是KCBP/KCXP这一类系统出现的历史背景#
到了这个阶段，再看：
KCBP
KCXP就不能简单理解成：
“两个老式证券软件。”
更准确地说，它们应该放在：
集中交易
↓
交易主站
↓
交易消息
↓
消息路由
↓
交易所连接这个历史架构里理解。
它们解决的是一种基础设施问题：
如何让证券公司的核心交易系统，与交易所、席位以及其他外部系统可靠地交换交易消息。
具体不同版本和不同证券公司的部署方式可能不同，因此不能把所有历史部署都简单画成完全相同的结构。
但是它们所处的技术问题是高度一致的。
十三、KCBP/KCXP放进整个证券系统是什么位置？#
可以用一个简化模型理解：
投资者
↓
营业部
↓
中央证券业务系统
↓
KCBP / KCXP
↓
┌───────────┼───────────┐
↓ ↓ ↓
上海市场 深圳市场 银行
↓ ↓ ↓
上交所 深交所 银行系统这里最重要的不是具体产品名称。
而是：
中央证券业务系统
↓
交易中间层
↓
多个外部系统这种架构思想。
十四、为什么不能让核心交易系统直接连接所有外部系统？#
假设证券公司有：
100个营业部又需要连接：
上海市场
深圳市场
银行
登记
清算如果每个业务系统都自己实现这些接口，就会变成：
业务系统A → 上交所
业务系统A → 深交所
业务系统A → 银行
业务系统B → 上交所
业务系统B → 深交所
业务系统B → 银行
业务系统C → 上交所
业务系统C → 深交所
业务系统C → 银行系统之间形成大量耦合。
所以更合理的方式是：
证券业务系统
/ | \
/ | \
↓ ↓ ↓
┌────────────────────────┐
│ 交易中间件层 │
└───────────┬────────────┘
│
┌────────┼────────┐
↓ ↓ ↓
上交所 深交所 银行这就是中间件存在的核心理由之一。
十五、中间件首先解决的是“协议耦合”#
没有中间件：
证券核心系统
│
├── 上交所协议
├── 深交所协议
├── 银行协议
├── 登记协议
└── 清算协议有中间件：
证券核心系统
↓
统一内部消息
↓
交易中间件
↓
┌────┼────┬────┐
↓ ↓ ↓ ↓
上交所 深交所 银行 登记核心系统因此不需要知道所有外部系统的底层细节。
这其实已经非常接近现代：
API Gateway
Message Broker
Protocol Adapter
Integration Bus这些概念。
十六、第二个核心问题：消息路由#
例如投资者下单：
买入上海股票系统需要判断：
应该送到哪里？如果是：
上海市场可能：
→ 上海交易通道
→ 上海交易席位
→ 上交所如果是：
深圳市场则：
→ 深圳交易通道
→ 深圳交易席位
→ 深交所所以中间件必须具有：
市场识别
+
路由规则
+
席位选择
+
交易通道选择十七、所以“交易主站”实际上非常重要#
“交易主站”不能简单理解成：
一台性能很强的服务器。
它实际上是一个交易处理中心。
简化来看：
营业部
↓
交易主站
├── 客户账户处理
├── 委托处理
├── 风险控制
├── 交易处理
├── 消息路由
└── 交易所连接因此：
营业部逐渐变成：
交易主站的前端入口而：
交易主站则成为：
证券公司交易网络的中心节点十八、这就是“多营业部 → 一个主站”的变化#
以前：
营业部A → 交易所
营业部B → 交易所
营业部C → 交易所
营业部D → 交易所后来：
营业部A ─┐
营业部B ─┤
营业部C ─┼──→ 交易主站
营业部D ─┤ ↓
营业部E ─┘ 交易席位
↓
交易所整个网络拓扑发生了巨大变化。
十九、为什么这被称为“集中交易”#
因为原来：
交易能力分散在营业部现在：
交易能力集中在中央系统营业部主要负责：
接待客户
↓
录入委托
↓
显示回报
↓
打印凭证中央系统负责：
账户
↓
委托
↓
风险
↓
路由
↓
交易
↓
成交状态所以：
集中交易的本质，是把“交易处理权”从营业部集中到证券公司的中央交易基础设施。
二十、但是集中化带来了一个新的巨大问题：可靠性#
如果只有一个营业部挂掉：
营业部A故障可能只是：
A营业部不能交易但如果中央系统挂掉：
中央交易主站故障可能变成：
A营业部 ─┐
B营业部 ─┤
C营业部 ─┼── 全部无法交易
D营业部 ─┤
E营业部 ─┘所以集中化带来了新的要求：
高可用
+
备份
+
热备
+
灾备
+
故障恢复
+
消息恢复证券IT开始真正进入“关键金融基础设施”的时代。
二十一、交易中间件也必须考虑断线恢复#
假设：
委托10001发送出去。
突然：
网络断了。证券公司不知道：
交易所到底收没收到？如果直接重发：
委托10001就可能产生重复委托。
因此系统必须知道：
这个消息是谁？于是出现了：
消息编号
委托编号
序列号
确认号
会话状态
成交状态这些东西。
二十二、证券交易天然需要“消息状态机”#
一笔委托可能经历：
新建
↓
发送
↓
已收到
↓
已接受
↓
部分成交
↓
全部成交也可能：
新建
↓
发送
↓
拒绝或者：
已报
↓
撤单
↓
撤单成功所以证券中间件实际上维护的是：
交易消息的生命周期。
二十三、这已经非常像今天的分布式系统#
虽然1990年代的技术远远没有今天先进，但是它们面对的问题其实非常现代：
网络故障
消息丢失
消息重复
消息乱序
部分失败
状态恢复
幂等
消息重放
一致性
对账今天微服务架构讨论：
Exactly Once
At Least Once
Idempotency
Replay
Event Ordering在证券交易领域其实早就有对应的问题。
只是当年的实现方式可能是：
C/C++
+
Unix
+
数据库
+
专用网络
+
自定义通信协议而不是今天的：
Kafka
REST
gRPC
Microservices
Cloud二十四、为什么必须有“序列号”#
假设交易系统发送：
1001
1002
1003
1004
1005交易对端收到：
1001
1002
1004
1005那么系统马上知道：
1003丢了。于是可以进行：
消息恢复这就是金融交易系统为什么特别重视：
Sequence的原因。
二十五、为什么“收到消息”和“交易成功”完全不是一回事#
例如：
网络发送成功只说明：
消息到达了下一层。并不代表：
交易所接受了委托。因此系统必须区分：
通信成功和：
业务成功例如：
TCP连接成功
≠
交易所接受委托
≠
订单成交这三个状态完全不同。
二十六、这就是为什么交易中间件不能只是“消息转发器”#
真正的证券交易中间件通常需要关心：
消息格式
消息顺序
消息状态
路由
会话
确认
异常
恢复
重发
去重
成交回报
撤单
对账所以它实际上已经是一套：
金融交易消息基础设施。
二十七、中央化以后，风险控制也开始中央化#
假设投资者有：
现金：100,000已经存在：
未成交委托：30,000现在又想下：
80,000中央系统可以计算：
30,000 + 80,000 > 100,000然后直接拒绝。
这就是：
集中风险控制的意义。
如果每个营业部都有自己的本地系统，就更难知道：
这个客户在其他营业部有没有其他委托？而集中系统能够看到统一状态。
二十八、集中交易同时解决了“单一事实来源”#
假设：
营业部A：
客户现金 = 100,000但：
营业部B：
客户现金 = 80,000到底哪个是真的？
集中系统可以建立：
中央账户状态
↓
100,000所有营业部都只是：
中央状态的访问入口而不是自己维护一套独立事实。
这就是所谓：
Single Source of Truth
虽然当时未必使用这个现代术语，但架构思想已经非常接近。
二十九、证券账户也从“营业部对象”变成“中央数据对象”#
早期：
客户
↓
营业部
↓
本地账户集中交易以后：
客户
↓
中央客户资料
↓
证券账户
↓
中央持仓于是：
营业部A ─┐
营业部B ─┼──→ 同一个中央账户
营业部C ─┘成为可能。
这对于跨营业部交易、统一风险控制、统一清算都非常重要。
三十、这时候“营业部”实际上被软件重新定义了#
1980年代：
营业部
=
柜台
+
柜员
+
股票
+
账簿
+
现金
+
人工登记1990年代初：
营业部
=
柜台
+
电脑
+
本地数据库
+
交易软件1990年代末：
营业部
=
客户入口
+
终端
+
网络
+
中央交易系统到了后来的互联网证券时代：
营业部
=
一个访问渠道再往后：
营业部
+
PC
+
手机
+
互联网
+
API共同访问中央交易基础设施。
这是一个非常大的历史变化。
三十一、“席位”也经历了类似的软件化#
最早：
交易席位
=
交易大厅里的一个物理位置后来：
交易席位
=
交易资格
+
交易通道
+
交易身份再后来：
席位
=
一个逻辑交易通道所以可以看到：
物理席位
↓
电子席位
↓
逻辑交易通道这是金融市场从“物理世界”向“软件世界”迁移的另一个典型案例。
三十二、股票本身也经历了同样的变化#
前面的文章我们讲过：
纸质股票
↓
证券账户
↓
电子持仓现在把它和交易席位放在一起：
股票凭证
↓
电子账户
物理席位
↓
电子交易通道
营业部柜台
↓
网络客户端这三个变化其实是同时发生的。
整个证券市场正在把：
“物理对象”转换成“数据库中的逻辑对象”。
三十三、这也是证券中间件真正兴起的历史原因#
当证券市场变成：
电子账户
+
电子订单
+
电子成交
+
电子清算
+
电子登记以后，市场真正流动的东西已经不是纸。
而是：
Message即：
消息。
一笔交易在IT系统里，本质上就是一连串消息：
委托消息
↓
确认消息
↓
成交消息
↓
清算消息
↓
结算消息
↓
持仓更新消息因此：
谁能可靠地处理这些消息，谁就掌握了证券交易系统的核心基础设施。
三十四、这就是KCBP/KCXP历史位置的重要性#
所以研究：
KCBP
KCXP不能只研究：
它有哪些菜单？
它有哪些功能？
它运行在哪台服务器？更应该研究：
它位于哪一层？
它连接谁？
它接收什么消息？
它向哪里路由？
它如何处理交易状态？
它如何适配交易所？
它如何处理故障？
它如何支持集中交易？这样才能真正理解它们为什么重要。
三十五、1990年代末的证券系统已经形成明显的分层结构#
可以抽象成：
┌─────────────────────────────┐
│ 投资者 / 营业部应用 │
├─────────────────────────────┤
│ 证券业务系统 │
│ 客户 / 账户 / 委托 / 风险 │
├─────────────────────────────┤
│ 交易中间件 │
│ KCBP / KCXP 类基础设施 │
├─────────────────────────────┤
│ 通信 / 协议适配 │
├─────────────────────────────┤
│ 交易网关 / 交易席位 │
├─────────────────────────────┤
│ 交易所 │
└─────────────────────────────┘这已经非常接近现代企业IT中的：
Frontend
↓
Business Layer
↓
Middleware
↓
Gateway
↓
External System只是证券行业把这种架构发展得非常早。
三十六、把一笔交易完整走一遍#
假设投资者想：
买入600000
1000股
10元数据可能经历：
投资者
↓
营业部柜台 / 客户终端
↓
中央证券业务系统
↓
账户检查
↓
风险检查
↓
交易中间件
↓
市场路由
↓
席位路由
↓
交易网关
↓
交易席位
↓
上交所如果成交：
上交所
↓
交易席位
↓
交易网关
↓
交易中间件
↓
中央证券业务系统
↓
营业部
↓
投资者这就是完整的交易闭环。
三十七、但成交并不是终点#
成交以后还有：
成交
↓
清算
↓
交收
↓
登记
↓
资金更新
↓
证券持仓更新因此完整链条实际上是：
客户
↓
委托
↓
交易
↓
成交
↓
清算
↓
结算
↓
登记
↓
账户更新这也是为什么：
证券公司交易系统绝不只是一个“下单软件”。
三十八、证券IT真正的核心其实是“状态”#
投资者看到的是：
买入成功但后台看到的是：
客户状态
账户状态
资金状态
委托状态
成交状态
证券状态
清算状态
结算状态
登记状态这些状态必须最终保持一致。
所以证券系统最重要的事情之一就是：
让整个交易生命周期中的状态保持正确。
三十九、这也解释了为什么必须进行“对账”#
例如证券公司系统认为：
成交笔数 = 10,000但交易所或清算系统认为：
成交笔数 = 9,999那么：
有一笔交易出了问题。于是每天都需要：
交易对账
资金对账
证券对账
清算对账
持仓对账这就是证券系统里非常重要的：
Reconciliation——对账。
四十、“集中交易”并不是一步完成的#
历史上不能简单理解成：
1995
↓
全部集中实际上是一个逐步过程：
营业部本地系统
↓
营业部联网
↓
中心数据库
↓
集中账户
↓
集中委托
↓
集中交易
↓
统一风险
↓
统一清算
↓
统一灾备很多证券公司在不同年份、不同地区、不同业务线上采用的架构并不完全一样。
因此研究历史系统时，必须区分：
产品架构和：
某家证券公司的实际部署架构两者不能完全等同。
四十一、为什么1997—2001年如此关键？#
因为这是中国证券IT从：
营业部时代真正走向：
证券公司网络时代的阶段。
前一个时代：
营业部是中心后一个时代：
中央交易系统是中心前一个时代：
本地数据库后一个时代：
中央数据前一个时代：
电话 + 人工后一个时代：
消息 + 中间件四十二、可以把这段历史压缩成五次“软件化”#
整个中国证券IT的发展，可以理解成：
第一次：股票软件化#
纸质股票
↓
证券账户第二次：客户软件化#
营业部客户
↓
中央客户数据第三次：交易软件化#
人工委托
↓
电子委托第四次：席位软件化#
物理席位
↓
电子交易通道第五次：市场连接软件化#
电话
↓
交易消息
↓
中间件
↓
交易网关这五个过程共同形成了现代证券交易系统的基础。
四十三、最终的网络形态#
到2000年前后，可以用这样一张图理解整个体系：
投资者
│
▼
┌────────────┐
│ 营业部 │
└─────┬──────┘
│
▼
┌────────────────────┐
│ 中央证券业务系统 │
│ │
│ 客户 / 账户 / 委托 │
│ 风险 / 持仓 / 状态 │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ 交易主站 / 中间件 │
│ │
│ 消息 / 路由 / 转换 │
│ 会话 / 恢复 / 对账 │
└─────────┬──────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
上海交易通道 深圳交易通道 银行通道
│ │ │
▼ ▼ ▼
上交所 深交所 银行这就是理解1990年代末证券IT最重要的一张“脑图”。
四十四、“双速网络”开始形成#
这里还有一个特别有意思的现象。
证券公司的客户侧：
几百个营业部
+
大量投资者
+
大量委托属于：
多入口、高并发、强聚合。
而交易所侧：
少量交易席位
+
严格交易协议
+
高度规范化交易接口属于：
少通道、强控制、高可靠。
于是中间件实际上承担的是：
很多
↓
中央交易层
↓
少数交易通道即：
Many-to-Few
的网络聚合。
这正是后来所谓证券“双速网络”的重要技术基础。
四十五、KCBP/KCXP为什么会成为一个时代的产物#
现在再看：
KCBP
KCXP它们并不是凭空出现的。
它们背后的历史链条是：
1980年代
纸质股票
↓
营业部柜台
1990年代初
电脑化营业部
↓
本地交易系统
1990年代中期
营业部联网
↓
中央数据库
1990年代后期
集中交易
↓
交易主站
集中交易
↓
交易席位
交易主站
↓
交易中间件
交易中间件
↓
交易所 / 银行 / 登记 / 清算因此：
KCBP/KCXP实际上是中国证券市场从“营业部电脑化”进入“证券公司网络化”以后，非常典型的一代基础设施软件。
四十六、这也是为什么金证与恒生后来会出现“中间件双子星”#
到了这个阶段，一个非常有意思的问题自然出现：
如果金证和恒生面对的是同一个市场：
营业部
↓
集中交易
↓
交易主站
↓
交易席位
↓
交易所那么：
为什么金证形成了KCBP/KCXP这样的体系，而恒生又形成了AS/AR这样的体系？
它们实际上面对的是高度相似的时代问题：
集中交易
+
多营业部
+
多市场
+
交易席位
+
异构接口
+
高可靠消息
+
清算登记但两家的系统设计、模块边界、消息模型和产品演化路径并不完全一样。
这就进入了下一层历史。