FIX实施指南: 交战规则

许多拥有较大FIX实现的公司都选择通过向对手方提供交战规则文档来支持他们。本节描述审计业务文件的最常见元素。通常，这些文档是对发布在FPL网站上的官方FIX规范的补充。或者，您可能希望将这些规则包含在您的标准业务条款中，以便每年更新。

会话级别和连接规则

网络选项

本节通常介绍支持的网络和厂商。例如，关于对特定供应商的推荐的详细信息将出现在这里。此外，还可能提到对某些提供者的特殊处理、不支持基于Internet的连接、所需的硬件加密方法等等。

FIX版本

重要的是，在文档的开头，公司描述了他们对FIX协议的不同版本的支持。大多数公司至少支持FIX 4.0，有些公司支持不止这个版本。消息类型之间的任何差异，或只支持从协议的特定版本开始的某种消息类型，将在本文档后面处理。

加密支持

此部分可能包含有关公司规定的加密要求的信息。例如，公司可能要求使用特定的实现(如FIX协议规范中描述的PGP-DES-MD5)对任何基于Internet的连接进行加密。此外，公司会列出任何支持或不支持的加密机制。

重复和重发消息处理

虽然FIX规范详细描述了对潜在重复信息的必要处理，但一些公司选择实施额外的安全检查来保护自己和与之连接的客户。本节将详细介绍此类实现。

例如，公司SELL将知道，并假设交易对手方知道，标记43和97可能表示潜在的重复信息，要么包含在具有相同序列号的消息中，要么包含在具有新序列号的消息中。处理这些消息的规则是详细和明确的，但是，公司SELL可能决定改进会话级别的重复处理，并建立如下规则:

如果今天从交易对手接收到显示以下相同字段的消息，则将被视为重复，并将被排除在进一步处理之外:Symbol (55)， Side(54)和ClOrdID(11)。

该规则将在会话层的上一层实现，并作为防止重复信息的附加安全保护。

一天开始/结束的程序

在许多情况下，交战规则文档的发布者将在这里描述FIX会话启动和终止的方式。反映连接的每个对手方的角色和责任的信息可以在这里找到。

例如，一个公司可能决定发起所有的连接，而不接受任何传入的TCP套接字请求。此外，这里将定义一个时间表，概述公司基础设施的最小停机时间，以适应序列号的滚动。一些公司允许一天结束(EOD)在一天中的任何时间运行。

对手方识别

FIX连接的每一方通常都有自己的方法来标识每个连接的发起者和目的地。在本节中，您可能会找到关于首选识别方式的信息，例如SenderCompID(49)、SenderSubID(50)、TargetCompID(56)、TargetSubID(57)的值，以及所需或支持的任何OBO (on-behalf-of) ID值。

故障转移过程

许多公司操作两台或多台生产机器进行FIX连接。在某些情况下，网络设备的安装使得对手方的机器数量对另一方是透明的，因为存在一个虚拟IP地址，连接请求发出或来自该虚拟IP地址。

通常，当处理FIX连接的机器出现故障时，连接将断开。虽然可能会导致服务短暂中断，但通常恢复正常操作条件所需要的只是重新连接，并同步序列号(重新发送之前未接收到的生成的任何消息)。

如果本节包含在硬件或电信设备发生故障时应遵循的任何程序，那么尽可能详细地描述上述过程将会有所帮助。

安全标识约定的定义

对于任何交易系统来说，在FIX消息中正确识别证券是极其重要的。每个FIX消息(传入或传出)中都有几个字段，用于标识证券。交战规则文档应指定首选哪种符号，如果支持多种符号，则可接受哪种约定。

例如，在实现中可能需要Symbol(55)，但是安全性的标识和验证中的最后一个词可能基于SecurityID(48)和IDSource(22)的组合来执行，以避免符号输入错误的问题。此外，传入消息中可能接受其他一些字段，但用于验证或标识目的时仍未使用。

此外，在国际符号学中，有一些情况是一个ID号描述了在多个位置列出的证券(例如，ISIN号不是特定于交易所的。处理此类案件的规则也应在本节中概述。

最后，并不是所有的ID源都可以被一方接受或理解，因此在这里列出可接受的SecurityID(48)形式也是一个好主意。

业务消息类型

交易对手方支持甚至接受所有FIX消息类型并不总是实际或可取的。例如，卖方公司可能不接受List订单，而只接受Single订单。此部分包含交战规则的“核心”，因为它描述了支持的消息、正确处理消息所需的任何修改或自定义，等等。在交战规则中详细列出的业务消息类型的可能列表(从卖方的角度)可以包括以下项目:

• 意向书（Indications of Interest，IOI）(出)
• 单次订购（Single Order）(入)
• 当日有效单（Day Order）(入)
• 多日订单（Multi-Day Order）(入)
• 列表订单（List Order）(入)
• 订单修改请求（Order Modify Request）(入)
• 取消订单请求（Order Cancel Request）(入)
• 订单取消拒绝（Order Cancel Reject）(出)
• 未知交易（Don’t Know Trade）(入)
• 订单状态请求（Order Status Request）(入)
• 报告取消及改正（Report Busts and Corrections）(出)
• 分配（Allocations ）(入)
• 分配ACK（Allocation Ack） (出)

除了接受的业务消息类型之外，本节还可以包括业务消息中单个字段的任何约定，例如使用以下格式:

• Account(1)
• HandlInst (21)
• OrdType (40)
• Price(44)
• Text(58)
• TimeInForce (59)

例如，一些公司要求为接收到的每条消息在Account(1)字段中包含某个值，另一些公司只支持某些订单类型(40)，还有一些公司可能不接受多日订单。这是交战规则的领域，列出了对特定字段值的任何要求。

测试脚本

为了确保任何系统的安全和持续运行，特别是关键任务事务处理组件，强烈建议进行测试。在撰写本文时，还没有FIX引擎技术和能力认证的正式标准;然而，许多公司已经创建了特定的测试脚本，由新连接的对手方执行。这一节将描述测试平台环境以及有助于快速实现测试工作的任何细节。FIX协议(4.4)的当前版本包含大量的材料，这些材料描述了许多场景中顺序状态的标准化更改，以及会话级别状态更改的预期行为。官方规范的这些部分应该成为建立任何测试程序的基础。

示例和术语表

执行良好的交战规则文档包含可用于测试的示例消息集，或者更详细地描述前面给出的说明。对于许多实现者来说，看到实际的消息极大地缩短了学习周期。另一个好主意是对文档中使用的语言提供简短而精确的指南。例如，一些人可能理解为“取消/替换”;另一些人可能理解为“修改”，其后果是更改消息中的订单ID和其他参数。

原文