什么是集中交易系统

admin 管理员组

文章数量: 887021

一、集中交易系统

从名字上看，一定是从分散的交易系统整合而来的，事实上也确实如此。

在上世纪90年代证券市场发展初期，证券经纪业务是以营业部为单位开展的，每家营业部都有自己的证券交易系统，单独保存自己的业务数据。粗放的管理模式带来了巨大的业务隐患，出现了诸如修改客户结算数据、挪用客户保证金、伪造客户交易指令等风险事件。

2004年左右，整个行业风险经过多年累积，呈现集中爆发的态势，出现了“南方证券”，“德隆系”等一系列重大风险案件，促使国家开始对证券行业进行综合整治。

也就是从这个时候开始，所有证券公司开始部署集中式的证券交易系统，由技术部门统一运营管理，这一代的证券交易系统也开始被行业内称为“集中交易系统”，并一直沿用至今。

二、集中交易系统承载哪些职能

集中交易系统是按照满足券商经纪业务来设计的，因此承载了很多业务职能。大致可以分为如下几大类：

1、账户业务。可以为客户进行账户开户、销户、管理业务权限、处理与交易相关的适当性管理、合规报送等。

2、资金业务。早期通过银证转帐实现，后来全面实行了客户保证金三方存管制度。

3、证券交易业务。处理投资者提交的各类交易指令，按照交易规则进行资金和证券的处理，并实现与交易所的委托和成交指令的对接。

4、信用交易业务。2010年证监会推出融资融券业务试点，投资者可以通过向证券公司融资买入股票，也可以融券卖出股票，实现了杠杆交易。系统需要按照信用交易的业务规则处理各类交易指令。

5、基金代销业务。投资者可以通过证券账户购买开放式基金产品，系统处理投资者的产品申购赎回指令，并实现与相应基金公司的指令交互和资金、份额结算。

6、清算业务。负责与交易所、登记结算公司进行数据交互和业务核对，完成客户在交易所内产品的资金、股份清算和结算。

7、查询业务。满足客户需要的各种交易流水、对账单、交割单等业务数据。

8、理财产品销售。券商为扩大客户投资品种范围，自行提供的各类理财产品的销售。

9、现金余额理财业务。可将客户投资账户上的现金余额自动申购为货币基金，提高客户的资金收益。

10、其他管理职能。系统参数设置、客户账号安全、外围系统接入、异常交易监控等。

三、集中交易业务有哪些特点？

1. 时效性：

• 交易时段限制。交易所开盘只有4个小时，在开盘时间范围内的指令才会得到处理。

• 竞价交易规则。交易达成是通过竞价实现的，竞价规则是价格优先+时间优先。如果指令提交太慢，就可能错过最佳的成交时间。

“时效性”的特点，决定了集中交易系统在设计时，必须要满足以下特性：

• 极强的稳定性和高可用性，尤其是在交易时段的高可用性
• 有竞争力的性能指标，保障客户的交易指令能快速到达交易所
• 主要业务都在开盘时间内集中处理，因此需要有足够的系统容量，并能随着业务规模的扩大灵活扩容。

外部性

证券开户需要通过登记结算公司，交易需要通过证券交易所，资金转帐需要通过存管银行，基金交易需要连接基金公司，交易清算需要依赖交易所和登记结算公司提供的结算文件。

“外部性”的特点，决定了集中交易系统在设计时，需要充分考虑与外部系统之间的交互逻辑和业务规则间的对应关系。

多样性

各种金融产品的交易、结算、交收规则各不相同，要求业务系统具有很好的灵活性，能适应各种不同金融产品的业务处理要求。

合规性

根据资本市场的主体责任划分，券商需要对交易的合规性进行前置检查，不允许出现证券卖空、资金透支等交易风险，因此就要求业务系统要保障业务逻辑的一致性。

四、证券交易系统技术架构演进之路

第一代的集中交易系统主要供应商包括恒生电子、金证股份、金仕达软件等，基本都采用了三层架构。如下图所示：

系统大至分为三层：

1. 接入层，一般为一个高性能的消息中间件，负责渠道系统的接入和业务消息传输。

2. 业务逻辑层，一般包含业务处理中间件框架，负责将业务消息分配到不同的业务处理模块进行处理。各业务模块通过与数据库交互，处理相应的业务请求。与外部系统相关的业务，则产生相应的业务请求并发送到外部系统，如交易所报盘、银行转账、登记结算公司账户开户等。

3. 数据库，也称为数据层，通过传统的关系型数据库存储所有的业务数据，也有些系统通过存储过程实现部分的业务逻辑。 根据了解，数据库承载了大量的业务逻辑，所以性能一直没有较大的提升，并且稳定性、扩展性堪忧

这一代的集中交易系统一般都有这几个特点：

• 通过数据库的事务一致性原理，实现业务逻辑的强一致性。如证券交易要求客户的资金冻结和订单委托必须保证一致性，系统就会把这两个数据库操作封装在一个事务中处理，确保其一致性。

• 数据库承担了大量的业务处理逻辑，为了达到交易系统对容量和延时的要求，必须配置高性能的软硬件设备。软件基本都采用了Oracle、DB2等数据库，硬件则采用IBM的小型机设备，并配备EMC的高端存储。是一种典型的IOE架构。

• 业务中间件负责业务流程的组织，有统一的业务处理框架，通过将不同的业务分拆成可以动态加载的模块，实现系统功能的扩展，但核心逻辑仍然是对数据库的操作。中间件一般会设计成无状态模式，可以任意增加，单台故障也不会影响业务连续性和数据一致性。

• 通过数据库复制软件将业务数据复制到备机和灾备机，即实现了业务系统的备份和灾备。正常状态下，备份系统只能执行业务查询，不能处理交易指令。如主机发生故障，可将备份系统启用。如主备系统均不可用，则可切换到灾备机。系统的可用性水平（如RTO，RPO）主要取决于数据库复制的速度。

第一代集中交易系统架构简单，系统的稳定性也很好，但也遇到了极大的挑战，包括：

1. 由于采用了数据库事务强一致性的方案，导致存在严重的资源争用，数据库成为整个系统的容量和性能瓶颈。券商被迫使用高性能的硬件设备来提高系统容量，降低交易延时，这又导致了高昂的系统部署和维护成本。而且从理论上讲，单台数据库系统有容量上限，交易处理延时下降也存在理论下限。

2. 由于每一项证券业务都在使用客户的资金信息，因此资金信息成为资源争用的中心。数据库事务很容易造成数据资源之间的死锁，因此对业务逻辑的编写有很高的要求，加剧了业务之间的耦合，使系统的研发和维护成本越来越高。

**第一代证券交易系统从2005年开始进入券商，基本满足了当时的市场业务需要。但随着资本市场的快速发展，特别是在经历了2008年的牛市行情，市场成交量逐步放大的背景下，部分商开始尝试解决集中交易系统可能面临的容量和性能问题。 **

第一个思路是寻找支持事务一致性的分布式的数据库系统，试图从数据库层面解决但数据库面临的容量问题，DB2也曾发布过类似的产品，但最终未能得到供应商的支持。但Oracle RAC架构的推出，解决了主备数据库的数据同步和高可用问题，因此得到了全面实施。

第二个思路是业务逻辑前移，将主要计算逻辑从数据库迁移业务中间件处理，降低数据库的负载。但由于证券业务并非计算密集型的应用，而是数据操作性的应用，最终还是需要和数据打交道，这种方案也只能部分降低数据库的负载。

第三个思路是将客户按一定的规则进行分拆，通过部署多个交易中心，解决单交易中心的性能容量问题。这个方案得到了供应商的支持，纷纷发布了新的集中交易产品。这可以称为第二代集中交易系统。

通过客户分拆，理论上系统的容量可以没有上限，但在单个节点上，由于数据库事务强一致性的约束，单笔交易的系统延时还是很大。为了解决这个问题，供应商开始尝试使用弱事务一致性来处理交易逻辑，即在处理交易时，不再强制在单一事务内完成资金和交易的处理，而是把它分解成两步，降低事务的原子级别，如果处理过程中发生异常，则通过反向交易进行账务回冲，从逻辑上保证业务处理的正确性。

弱一致性的引入，可以大幅提高系统的吞吐量，也可以降低单笔业务的延时。在恒生电子的UF2.0中，综合采用了客户分拆、弱一致性事务等机制，在券商中得到了广泛使用。但由于是数据库机制，交易延时仍然只能达到10ms这个量级。

弱一致性在带来好处的同时，也降低了系统的数据一致性，当系统发生局部故障时，就可能出现系统资金和证券数据的不一致，需要通过业务过程中的日志和流水进行状态恢复。

在供应商的推动下，券商从2009年开始全面部署第二代集中交易系统，随后证券市场开始出现了新的变化，包括：

1、交易量开始稳步上升，两市每天稳定在3000亿以上，随时有放大的趋势。

2、易所开始推出各类创新的业务品种，包括创业板、融资融券、个股期权、沪深港通、固定收益产品扩容到地方政府债、公司债、企业债、ABS等。

3、证监会放开非现场开户后，客户争夺更加激烈，市场佣金持续下降。

4、业务合规性要求越来越高

新业务频繁推出，叠加券商间对客户资源的争夺日趋激烈，给集中交易系统带来了庞大的新增需求，供应商响应速度无法达到券商的业务需要，且频繁变更也给系统安全运行带来了巨大的挑战。行业内开始思考如何给集中交易系统进行架构优化。

第一个优化的方向是将账户系统进行剥离，从而为券商优化经纪业务运营体系提供可能性。按照这个思路，部分券商上线了独立的账户系统，将与营业网点相关的账户开立、资料录入、业务审核、合规报送等功能从集中交易完全剥离出来。

第二个优化的方向是将数据查询功能进行剥离，部署独立的数据中心系统，一方面可以减轻集中交易系统数据查询带来的压力，另一方面也可以进一步完善对客户的服务。

第三个优化是将理财产品销售功能进行剥离，部署专门用于处理产品销售的OTC系统，将原有开放式基金业务也纳入OTC系统统一处理。

第四个优化的方向是清算子系统，部分券商将清算职能从集中交易系统完全剥离出来，纳入统一的清算运营平台，更有甚者，将公司自营、资管等业务线的清算也统一考虑，形成了公司级的运营平台。

由于在如何给集中交易系统进行架构优化上，不同的券商有不同的思路，因此并没有形成行业统一的产品形态，以上提及的几个优化方向，券商会按自己的业务实际情况，有选择的进行实施。

瘦身后的集中交易系统功能更加纯粹，聚焦在高效稳定支持各种场内业务的交易、清算、合规管理等职能。但从交易功能上看，并没有改变围绕数据库进行业务处理的框架，可以看成是第二代集中交易系统的优化版。

短时间来看，需要一个长期的过程，等待黑马的出现，改变这种现状也不是不可能，最近几年，各大证券软件供应商一直被券商诟病。
静待黑马的出现。。。。。。

在证券市场高速发展的同时，投资者结构也悄然发生了深刻变化，大量出现了以量化私募基金为代表的专业机构投资者，他们对交易系统的要求提升了一个量级，主要体现在：

1.使用计算机软件进行程序化交易。

2.对交易延时极为敏感，不同投资者之间存在速度竞争。

3.可能在较短时间内发出大量订单，对系统稳定性要求更高。

以数据库为中心的交易系统虽然经过了各种架构优化，但也只能将交易延时缩短到10ms左右的水平，离专业投资者的要求还有很大的差距。供应商开始推出全内存化的快速交易系统，专门服务少量的专业投资者。快速交易系统只有交易功能，其账户业务、资金划拨、清算均依托集中交易系统。所有业务全部在内存中完成处理，且每个客户的业务均采用串行化处理，确保数据的一致性（这一设计借鉴了期货交易系统）。

快速交易系统将交易延时提升了一个量级，达到了100微秒左右，有些供应商的系统甚至更快一些。但由于数据全部保存在内存中，损失了一定的高可用性，且由于业务串行化处理，吞吐量也受到了一定限制，因此单个节点的快速交易无法承载很多客户，券商会根据需要部署多套快速交易系统，有些甚至部署不同供应商的快速交易系统。券商交易系统进入了一种融合的架构模式

这种融合架构的集中交易系统部署方案，已在大部分券商的生产系统得到实施。

本文标签： 交易系统