A FIX Rules of Engagement (RoE) specification is a reference manual describing how FIX Protocol Standards are extended, with additional FIX fields/tags, messages, and enumerations within specific usage contexts.
About the Financial Information eXchange (FIX) protocol
Before we explore FIX Variant Specifications, it is important to understand the Financial Information eXchange (FIX) protocol itself.
The Financial Information eXchange (FIX) protocol is an open electronic communications standard, that is designed to standardise and streamline electronic communications in the financial services industry. FIX supports multiple formats and types of communications between financial entities; such as order advertisements, order submissions, order amendments, order status and trade execution reporting, and trade allocation.
The core FIX protocol and family of messaging specification standards have evolved into a range of related technical standards; with differing use cases. Below, we will outline key considerations for FIX Protocol Standards; to enable a better understanding of FIX Variant “Rules of Engagement” specifications, that enable FIX connectivity between parties.
Technical Specifications, Not Concrete Implementations
It is important to note that the FIX Protocol Standards are technical specifications rather than concrete implementations.
The core technical implementations are known as "FIX Engines" that support the FIX Protocol session, application and encoding specifications. A key benefit of the FIX protocol standards used for trading is that they mandate the behaviour of connected counterparties - meaning that FIX Engine implementations from different providers are interoperable.
Considering use case here, FIX Standards are used for many order surveillance and post-trade feeds – and they work very well in this context. FIX APIs are also supported by various aggregators for indirect market access (for example, Trading Technologies (TT®).
But FIX connectivity is not universal. The FIX Application level messaging specifies the fields and messages used at an application level. It is the FIX application level messages that most developers will work with to create and consume message-based communications with counterparties via the APIs of the FIX Engine implementation that is in use.
It is also worth noting that the FIX messaging standards are designed to be extensible - meaning that it is common practice to add FIX tags that extend the base message standards based on bilateral or multilateral usage conventions.
Such usage is usually defined in a "FIX Rules of Engagement" (FIX RoE) specification that is published by the relevant exchange, investment firm or utility for implementation by counterparties. Such extensions are typically known as "FIX Dictionary" FIX dialect variants that extend or specialise the base FIX messaging standards.
Understanding FIX Rules of Engagement Specifications
A FIX Rules of Engagement (RoE) specification is a reference manual that describes how the FIX Protocol Standards are extended with additional FIX fields/tags, messages, and enumerations within specific usage contexts.
The FIX RoE specifications are interpreted and codified in XML instance documents, that define the additional FIX fields/tags, messages, and enumerations. This interpretation of the FIX RoE specifications is usually a manual process, although in some cases an XML instance document is also provided with the FIX RoE specification that can be directly implemented.
FIX RoE Specification Naming Conventions
The FIX RoE Specifications are usually named in variations of the document naming convention of <venue> FIX API for <service> where:
- <venue> = the liquidity pool or exchange venue, investment bank, broker, utility or application vendor.
- <service> = the specific API to which the connection is being made.
By way of named specific document examples:
- “ICE FIX TC Reference Manual – Version 4.8”
- “Cboe Futures Exchange FIX Specification”
- “LSE MIT205 – Drop Copy Gateway (FIX 5.0) Specification”
The extension of FIX messaging with additional FIX fields/tags, messages, and enumerations is widely used in the industry for FIX application level messaging based on the business requirements of liquidity pools/exchanges, counterparties, industry utilities and application vendors/ISVs.
The XML instance documents that are used to define the additional FIX fields/tags, messages, and enumerations are known as FIX dictionary dialects or FIX variant dialects.
The OnixS FIX Engine implementations support FIX dialect descriptions as a part of the configuration settings.
Example in OnixS .NET Framework C#:
EngineSettings settings = new EngineSettings();
settings.Dialect = "IceTradeCaptureFixDialect.xml";
Engine.Init(settings);
The Dialect configuration parameter specifies one or more dialect definition files in XML format and the FIX dictionary dialect definition file must conform to the dialect XML schema
FIX Dialect customisation includes the ability to expand the set of FIX messages with new messages, to extend messages and repeating groups with new fields and subgroups. It is also possible to replace regular FIX tag fields with repeating groups and vice versa. However, there is no way to exclude any FIX message, tag and/or group that are part of the base formal FIX standards.
Using FIX Dialects with OnixS FIX Engine Implementations
OnixS Engine implementations support FIX dialects for a single specific FIX session (session level dialect), as well as the capability to replace the standard FIX dictionaries with dialect implementations that are used everywhere in the FIX Engine. (engine level dialect).
A basic example FIX dictionary dialect variant description file looks like the following example:
<!--?xml version="1.0" encoding="utf-8"?-->
<!--
Root of dialects descriptions.
May contain engine-wise as well as per-session dialects descriptions.
-->
<Dialect xmlns="https://ref.onixs.biz/fix/dialects"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://ref.onixs.biz/fix/dialects
https://ref.onixs.biz/fix/dialects/dialects-2.15.xsd">
<!--
FIX field defines single dialect description.
Attribute 'version' defines version of FIX messaging specification which is being customized.
-->
<FIX version="4.0">
<!-- Changes into single message structure go here (as well as new messages definitions). -->
<Message type="D">
<!-- Tags and groups which enlarge or modify message. -->
<Field tag="526" name="SecondaryClOrdID"/>
</Message>
</FIX>
</Dialect>
OnixS provides two primary options with regard to usage of FIX dictional dialects:
- Do it yourself based on the OnixS FIX Engine implementation documentation in the OnixS Programming Guide API Documentation / FIX Dictionary and FIX Dialect sections. This may be suitable for development teams and ISV’s – for example those primary focus may be creating FIX RoE specifications and implementations for exposing FIX access services to their own platforms.
- And the more packaged option to use prepackaged venue and service specific solution SDK bundles that are implemented and supported to provide API access to the relevant FIX API(s). This is suitable for trading firms, application ISV’s who want to quickly integrate with services such as the previously quoted ICE FIX Trade Capture (TC) API, the Cboe Futures Exchange FIX services, or the LSE Drop Copy FIX service.
The OnixS directConnect: ICE FIX Trade Capture Handler SDK is an example of such a package. The OnixS directConnect: ICE FIX Trade Capture Handler SDK consists of a bundle of the OnixS FIX Engine, the ICE FIX TC specific FIX dictionary dialect, reference implementation fast-start source code samples and is fully supported to be kept up to date with updates to the ICE FIX TC Reference Manual (RoE) specification.
