Local EPUB Text
系统实施
实施高频系统的关键步骤
绝大多数系统交易平台的结构都如图16-2所示。本节详细讨论流程的每个组成部分。
图16-2 典型的高频交易过程
步骤1：核心引擎
核心引擎由一个或多个运行时处理器组成，包含了交易机制的核心逻辑，并且履行以下职能：
·接收、评估和归档传入报价。
·进行运行时计量经济分析。
·实施运行时的投资组合管理。
·启动和发送买卖交易信号。
·等待并接收执行的确认。
·计算运行时的损益。
·基于目前的投资组合配置和市场状况，动态管理风险。
大多数高频交易的产品系统都是用C++语言编写的，尽管据我们所知也有一些高频交易公司使用Java和Q语言，这是由Kx Systems分发的语言语法和数据库组合的商业融合。例如，据说纳斯达克OMX的撮合引擎是用Java编写的，但代码禁用了“垃圾收集机制”，这是Java的核心功能，它将其与C++区分开来，但也会降低系统的速度。C++通常被认为比Java“更轻”和“更快”，这也就是说，C++程序占用运算的能力不像Java所需的这么多。因此，C++系统的工作速度通常比基于Java的系统要快。
接下来，核心引擎和投资组合的管理框架会启动，并向经纪自营商发送订单。在收到并执行订单后，经纪商会将客户的订单状态和订单完成情况，包括价格和成交数额等发回给客户。然后，系统计算出收益情况，并评估反馈到投资组合管理部分的风险管理参数。
运行组合管理的设计和实施，反映了核心计量经济学的引擎。除了原始报价输入外，投资组合管理框架还包含计量经济模型、当前头寸（仓位）规模、与投资组合多元化相关的其他信息，以及投资组合回报最大化的投入，同时最小化投资组合的风险。
经纪自营商与客户或交易所之间彼此传递报价、订单以及其他信息，主要是通过用于传输实时财务信息的财务信息交换（FIX）协议传送，同时还使用其他协议，如FAST和Nasdaq专有的ITCH和OUCH。
据FIX行业网站（www.fixprotoco.org）的资料，FIX于1992年诞生，起初是作为美国富达投资集团（Fideity Investments）与所罗门兄弟（Saomon Brothers）之间股权交易的双边沟通框架。目前它已成为各经纪商、交易所和交易客户之间的主要沟通方式。事实上，根据fixprotoco.org进行的调查，2006年，有75%的买方公司、80%的卖方公司和超过75%的交易所利用FIX进行系统交易。
FIX是一个由全球指导委员会监督的编程语言，该全球指导委员会的成员分别来自世界各地的银行、经纪商、交易所、行业公用事业和协会，机构投资者和信息技术提供商的代表。FIX的标准是开放且免费的。然而，通过FIX实施通信的过程，需要仔细地规划和专门的资源分配，并且可能耗资巨大，就像任何其他系统的开发过程一样。
一条典型的FIX信息由头部、正文和尾部组成。头部通常包含以下三个域：（1）标识信息开头的字符串（FIX域＃8）；（2）紧跟信息头部之后的正文的字符个数（FIX域＃9）；（3）信息类型（FIX域＃35）。其中，许多消息类型中都有报价和订单执行、订单指示和确认，以及旨在确保系统正常和良好运行的看家信息。
例如，MsgType=0是“心跳”（heartbeat）信息——这个信息被发送到另一个通信方，以确保通信仍保持连接，并且没有由于任何不可预见的技术问题而中断。心跳信息通常在预先指定的不活动时间超过秒数后发送。如果任一通信方没有从另一方接收到心跳信息，它就会发送一个测试请求（Test Request）信息（MsgType=1）来“询问”另一个通信方。如果在发出测试请求消息后还没有收到心跳信息，则认为连接已经丢失，需要采取措施重新启动连接。
MsgType=6被称为“兴趣指标”（indication of interest）。交易所和经纪自营商使用兴趣指标信息，来传递他们以专有自营身份或代理身份买入或卖出的兴趣。MsgType=R表示一个“报价请求”（quote request）消息，经纪自营商的客户利用该信息来请求报价流。在正常情况下，经纪自营商会用连续的报价信息（MsgType=S）来响应报价请求消息，其中包含实时报价信息，如卖价和买价等。
其他信息类型包含的订单，如单名订单、列表订单、日内限价订单、多日订单、各式取消请求以及确认等。头部中的所有域都有如下格式：
[Field #] = [data]
例如，要表达此信息中包含某一订单的状态，我们使用如下序列：
35=8|
所有域序列都用一个特殊字符作为结尾，此字符的计算机值为0x01，该字符在屏幕上显示为“|”。
信息的正文部分包含信息的详细内容，即它是一个报价请求，还是报价本身，还是订单和交易信息。信息正文还指明了交易所，包含毫秒数的时间戳、证券代码，以及其他一些必要的交易数据。跟头部一样，正文中所有的域也有如下格式：
[Field #] = [data]
并且每个域序列都以特殊计算机字符0x01作为结尾。
最后，每条信息正文尾部都是“校验和”（checksum），即信息中所有字符的数字值之和，信息包含此校验和主要是为了验证信息是否全部到达。FIX信息的示例在本书的第2章已做出说明。
风险管理功能一般包括以下组成部分：如果突破了绩效盈亏限制，则跟踪系统性能的基本组件并生成警告消息。适当的风险管理参数可能包括每单位时间的消息计数限制，损益参数以及本章后面详细讨论的其他变量。
步骤2：报价归档
大多数报价信息都会使用专有的FIX引擎进行接收和存档，而这些引擎在各种消息场景中都进行了测试。下面的报价数据将用于对账和仿真交易。
如第2章所述，公共网络上的报价信息可能不可靠：用户数据报协议（UDP）所公布的一些报价不能保证点对点传送。因此，没有进行主机代管的高频交易可能会丢失报价信息。此外，一个实体到下一个实体的报价接收技术的变化不能保证每个实体的记录数据流与下一个实体的数据流相同。在某些情况下，所购买的高频数据可能不能完全展现出数据购买方从他自己的报价界面进行报价信息归档的过程。当研究者缺少数据时，其所购买的历史数据填补了重要信息的空白。最佳的执行表明，每个交易实体将从内部归档的数据中获益最多，因为这些数据是系统在生产过程中所收到的数据中最具代表性的。
大多数拥有高频交易系统的公司需要以文本或二进制文件格式归档所有接收到和已发送的消息。文本文件，被称为行业中的平面文件，是最简单的存储形式。平面文件是可读的，无须特殊翻译。文件中的字段可以用逗号或制表符分隔，并且可以轻松地加载到Exce中，也可以使用PC上的记事本或LINUX上的纯文本编辑器打开。通常称为大二进制对象或BLOB的二进制文件，以机器可读的十六进制（十六进制）字符进行记录。以牺牲可读性为代价，BLOB比平面文件更快、更紧凑。例如，交易经纪商经纪人ICAP外汇撮合引擎在连续的每周BLOB中记录所有高频数据。随同外汇市场，每个ICAP的BLOB从周日晚上开始，并在纽约时间周五晚上结束，每个这样的BLOB可以占用多达1TB的存储空间。这样的存储要求在10年前可能非常昂贵，但今天这样的存储却是非常合理的。存储区域网络（SAN）的各种形式允许无缝访问已存储的数据。
许多数据库试图打破存储实时高频数据的市场，并用其产品取代平面文件。大多数数据库不适合高频交易，因为在高频交易中最具时效性的功能是数据归档。降低输入/输出操作速度会延迟交易引擎的执行，从而破坏高频交易系统的性能。高频数据仅在执行时间不是关键参数的模拟交易中进行检索。然而，大多数数据库经过优化，可有效地检索数据，而不是将其输入系统。Kx Systems发行的KDB已被证明是一个有前途的工具，已被多家公司采用。
步骤3：交易后分析
最好的高频交易系统不会就此止步。交易后分析引擎将产生的结果与使用相同代码以及相同数据下的模拟结果一致，并更新收益分布、交易成本、风险管理参数，以反馈到主要处理引擎、投资组合优化过程，以及风险管理组成模块中。
步骤4：模拟
模拟是指一个交易策略的虚拟执行。模拟很重要，其关键原因如下：它允许研究人员在短时间内测试一个策略，而不用冒险动用实际资本。在模拟中运行良好的策略，可以在“生产”步骤中使用真实资本进行交易。相反，在模拟中运行失败的策略，将难以在实际交易环境中获得积极的成果。
模拟引擎是一个独立的模块，可以测试关于过去和运行时数据的新交易策略，而无须真正执行交易。不同于仍处于用MatLab甚至Exce进行编码的开发初期的理念，在模拟引擎测试中通常使用生产语言（C++或Java）进行编码。
模拟近似于真实的交易，并且只有当模拟的执行部分被正确地编程时才会发生。具体来说，需要区别对待市价订单和限价订单的执行。在模拟中提交的市价订单可以假定在市价订单提交时按当时的报价执行。因此，假设市价买单可以以最低卖价全部成交，那么则可以假设市价订单规模小于最低卖价挂单规模；同样，小规模市价卖单可以假设以最低卖价进行交易执行。
然而，关于执行市价订单的最优报价的假设，大部分时间都会夸大交易系统的表现。在实时交易中，市价订单将产生市场冲击或滑点，从而导致价格坏于最高买价和最低卖价的预测价格（有关市场影响的更多详情，参见第5章）。为了更好地接近实时交易结果，高频交易研究人员估计每单位交易规模平均市场冲击，然后调整最低报价的市场冲击估计值。考虑市价买单会以当前市场询价加上基于订单规模的预期市场冲击来执行，以期进一步接近真实的市场交易环境，同时以期在模拟交易中很大程度地应用保守主义交易理念。同样，可以预期市价订单会以较小的市场冲击估计的最低卖价来执行。
限价订单的模拟执行也很复杂。只有当市场价格“交叉”订单价格时，才能考虑执行限价订单，如图10-1所示。当市场价格等于限价订单的价格时，限价订单可能会也可能不会在实时交易中被执行。因此，限价交易的模拟通常考虑：当市场价格下跌到买入限价订单的价格以下时，或者当市场价格上涨超过限价卖单的价格时，才执行限价订单，这样限价订单才能得以保证被执行。
策略的模拟可以在样本内和样本外进行。样本内模拟会以同一样本运行首先开发的策略。然而，一些自然问题困扰着样本过程：数据可能过量；结果可能在正常的市场条件下不能成立。
为了确保该策略在现实交易中有机会执行，该策略需要进行样本测试。样本外测试包括运行策略中大量以前未使用的数据量。样本外测试通常按以下顺序进行：
1.回测（back-test）；
2.纸上模拟交易（paper trading）；
3.生产（production）。
回测 用历史数据运行的策略称为回测。回测通常使用至少两年的最新高频数据。测试两年的数据是最低要求，而这些数据可能是低频月度绩效评估日的突出数据：24个月提供了一些月度观测数据，几乎足以在统计学中的中心极限定理下进行统计学显著性推论。
理论上，正如第6章所讨论的那样，夏普比率决定了能够充分证明策略绩效的最低观测数据。然而，在实践中，较小的数据集倾向于更多的观测数据，因为观测次数越多，评估战略绩效的机会就越多，对策略结果的信心就越高。
大量的历史数据（至少两年的连续高频数据）确保了该模型能够最大限度地减少数据抽样偏差，即在模型超过数据中的偶发误差时，这种情况才会发生。
在模型研发阶段会使用一组新的历史数据进行回测，这被称为做“样本外推断”。
回测也可用于估计给定交易系统的风险。用于高频交易风险量化模型中的输入变量优先收益分布，是从基于实时资本的系统运行中获取的。用至少两年的高频数据运行该模型，可以获取交易收益的回测分布，而这些高频数据也可以用于风险管理应用程序，即使回测分布可能产生误导的结果：回测可能无法考虑到系统正在进行交易时发生的所有极端收益和隐藏成本。
为了减少意外和低概率的极端收益，即为黑天鹅（Taeb，2007），高频交易研究人员可以考虑通过组合“压力测试场景”的历史或模拟数据运行高频交易代码。2010年5月6日的闪电崩盘数据是压力事件的历史例证。然而，可以模拟一些与全球金融市场假设同时失效相关的数据。
需要对样本外的回测结果进行评估。至少，评估过程应计算测度交易理论表现的基本统计参数：累积和平均收益、夏普比率和最大回撤，如第6章所述。
一旦确定策略在回测中的表现令人满意，那么这个策略将会运用到纸上模拟交易中。
纸上模拟交易 基于实时数据实时运行但没有进行真正交易的策略，即为纸上模拟交易。纸上模拟交易阶段将所有订单记录在文本文件中。订单和交易记录应至少包括：
·订单的粒度时间戳，最少为1毫秒，或更精确；
·交易性金融工具代码；
·最后所观测的最优买价和最优买价规模、最优卖价和最优卖价规模，以便订单和数据的日后调节；
·订单数量；
·假设执行价格。
实时交易模型和回测模型之间的主要区别在于报价数据的来源；回测系统包括历史报价流模块，它从归档中读取历史记录数据并将其按顺序馈送到具有主要功能的模块。在纸上模拟交易系统中，不同的报价模块从交易场所和经纪商处获取实时高频数据。
除了接收报价信号的差异外，纸上模拟交易和回测系统应相同；可以对它们同时构建，并且使用相同的代码进行核心功能编程。本章回顾了系统的实施过程，假设回测和纸上模拟交易引擎都是并行构建和测试的。以下部分总结了高频系统开发过程中的关键步骤，详细介绍了系统开发过程，包括常见故障，并讨论了开发交易系统测试的最佳执行。
生产 基于实时资本运行的策略通常称为实时交易或生产。生产订单通过FIX或其他消息协议发送到实时交易所。生产中，高频交易系统运行仍然需要本地归档所有的订单，正如上文所讨论的纸上模拟交易。纸上模拟交易记录和实时交易记录将有助于完成订单和对账分析，并有助于评估该策略的执行绩效。
实时战略与纸上模拟交易之间的绩效差异，被称为执行落差。通过对实际市场中获得的价格及其模拟对手进行直接观测，执行落差提供了最可靠的滑点和其他潜在成本的措施。
步骤5：人力监督
需要对该系统进行持续的人力监督，以确保其不会成为某些恶意活动的受害者，例如计算机病毒或模型本身未予说明的市场事件。然而，人类交易商的角色通常只限于确保系统的性能能够控制在特定范围内。一旦突破界限，人类交易商应该有权在当天关闭交易或直到导致破坏的因素都已解决。
系统实施中的常见缺陷
信息确认循环
市价订单通信过程包括以下步骤：
·客户向经纪人或交易所发送市价订单；
·交易所接收订单/经纪商将订单转交给交易所；
·交易所发出订单确认；
·客户端收到订单确认；
·执行交易订单；
·交易所发出执行确认；
·客户端收到执行确认。
时间在客户端发送订单与客户端接收到订单执行确认信号之间流逝。在美国，市价订单的往返执行速度在10毫秒以内；在欧洲，可能会达到50～100毫秒；在亚洲，则可能还需要1～2分钟。无论执行过程的速度如何，在订单发起和执行确认之间经过的有限时间内，都足以发生偏离算法的事件。
新手因位置计算器编程错误而导致系统运行失控。考虑下面的逻辑：交易算法根据具体的市场情况发出订单，直至总投资组合达到一定的上限。当位置计数器仅在接受执行确认进行调整时，交易系统会在订单执行期间发出订单指令，这可能会导致执行数量超限，远高于设定的执行数量限制。这个错误既常见又很容易解决。一个解决方案是保留两个位置计数器：一个用于发送命令；另一个用于确认执行位置。然而，对于缺乏高频交易经验的人来说，则可能想不到这个方案。
时间失真
模拟按自身的时间运行时，使用在另外一个进程运行时间内收集及存储的报价信息。收集现为历史数据的进程中所记录的报价频率可能会有很大差异，主要因为以下两个因素：
1.原始进程中收集报价的金融工具的数量。
2.原始进程中计算机系统运行的速度。
它们的影响是由报价过程的性质和它在大多数交易系统中的实现所造成的。大多数系统包括用于接收报价和服务器信息（提供报价的经纪自营商应用程序）的客户端（报价收集和/或交易应用程序）。客户端通常是在“本地”运行“本地”应用程序：在交易商完全控制的计算机硬件上。代理商服务器几乎总是一个远程应用程序，这意味着客户端必须通过远程连接与服务器通信（如互联网）。要接收报价，客户端应用程序通常必须与服务器进程进行以下通信。
1.客户端向服务器发送消息或一系列消息，其中包含以下信息：（1）客户身份认证（由承包服务器的代理商给予客户的）；（2）请求报价的金融证券名称。
2.服务器将响应，确认客户端的消息。服务器的响应也将指示客户端是否接受基于某些原因下所请求的任意报价。
3.服务器开始向客户端发送报价。报价通常以“异步”的方式传输，也就是说，一旦新的报价可用，服务器将向客户端发送报价。一些证券的报价频率比其他证券要高。例如，在围绕经济信息公告的高波动期间，像欧元/美元汇率每秒钟可以发送多达300个报价的现象就非常常见；同时，一些模糊期权只能在每个交易日产生一个报价。在设计报价接收部分的应用程序时，记住报价的预期频率是非常重要的。
4.之后经常发生报价失真。一旦报价信息到达客户端计算机，客户端就有责任收集和处理所有报价。这里可能会出现几个问题。在客户端机器上，所有传入的报价按其到达顺序排列成队列，最早到达的报价排在处理器最前列。这个队列可以被看作是机场登机队列，然而，与机场队列不同，此队列通常具有有限的长度或容量，如果队列已满，任何已到报价都会被丢弃。因此，第一个问题：如果客户端系统具有不同长度的队列，所有其他系统特性相同，报价时间序列可能因客户端而异。
一旦报价在队列中，系统从队列中选出最早的报价来进行处理，然后队列中的所有报价都将更接近处理引擎中的报价。如前所述，报价到达的速度要快于能够处理这些报价的客户端，从而能够补充报价队列并引导系统处理完较早的报价之后再处理新的报价单。即使一个看似简单的操作，例如将报价复制到存储在计算机系统上的文件或数据库中，都需要花费计算机时间。虽然报价存储时间可能是一小部分时间，并且从人为时间标准角度看，可忽略不计，但时间可能会因计算机计时而重要，并减慢传入报价的处理速度。
客户端系统可以指定报价的达到时间，即从达到队列中获取报价的时间。因此，时间戳可能与服务器引用的时间戳不同。根据报价所收集的证券数目及在某一特定时间内市场的波动情况，时间戳失真可能由于报价处理延迟的结果而显著不同。如果在数学上进一步操纵报价以产生交易信号，则时间戳的失真可能更加显著。
5.当然，在处理能力较慢的计算机上运行的系统会比在较快的计算机上运行的系统遇到更多的时间戳。较快的计算机能够以更快的速度传输顺序报价信息，从而实现较少的报价信息丢失。即使是系统功率中最为微小的差异也可能导致产生不同的报价流，从而产生不同的交易信号。
可以通过以下四种方式提高报价传输的可靠性：
1.在将报价放入队列之前，每个报价一到达市场，就立即标记时间戳。
2.增加报价队列的规模。
3.考虑到成本/效益分析，将系统内存增加到最大可用性。
4.减少任意给定客户收集报价的证券数量。
当客户端应用程序从头开始设计和构建时，特别是当使用FIX协议进行报价传输时，用于提高报价传输可靠性的这四个步骤可以轻松实现。然而，许多现成的客户端，包括执行代理商分发的客户端，可能难以或不可能进行定制。对于计划使用现成客户端的企业，可以谨慎地询问软件制造商如何在客户端解决上述问题。
执行速度
执行时间可以使高频交易模型有效或无效。例如，许多用于市场临时出现错误报价时套利的交易策略，都取决于以闪电般的速度获得订单的能力。无论谁发现市场存在价格偏差，并首先在交易所上发布订单的，都可能获取最大的利润。
执行速度由以下交易平台组成部分决定：
·应用产生交易信号的程序速度。
·应用程序向执行代理生成交易信号的邻近程度。
·执行代理平台发送执行请求的速度。
·执行经纪商相对于交易所的邻近程度。
·交易所处理执行命令的速度。
图16-3说明了执行过程的时间依赖性流程。
图16-3 执行过程
为了提高消息的安全性以及降低客户与经纪商或交易所之间由于交易信号物理传输造成的延迟，依赖于执行速度的客户经常选择在邻近中心内进行主机代管或安置其服务器。主机代管或邻近安置主机服务通常配备能够在系统或电源故障的情况下恢复服务的系统管理人员，从而确保客户端应用程序至少能够工作99.999%的时间。本书第2章详细讨论了主机代管和邻近安置主机。