FIX Connect offers order routing and Drop Copy Functionality.
Trade routing connectivity is available to more than forty exchanges worldwide. We support platform-neutral trade execution and risk management processes by leveraging CQG’s industry-leading unified exchange gateway and Customer Account Service Tool (CAST) risk control system without the need for access to a CQG proprietary client.
Access to the CQG gateway for FIX can be incorporated as part of a wide range of trading and back office solutions, such as algorithmic trading, customer risk control, alternative client manual trading, and managed execution.
This document is designed to supplement the FIX protocol documentation that can be found at http://www.fixprotocol.org/ rather than being a complete and self-sufficient reference.
In the message descriptions below, the following assumptions and notation are used:
•FIX 4.2 is the basis for all messages.
•Only supported fields are listed.
•Readers should have a good working knowledge of FIX prior to reading this document.
Conformance Testing
Before using FIX Connect on a live production environment, it is important to ensure that the client application works as expected and can recover from order rejects, missed events, etc.
This verification is achieved through FIX Connect conformance testing. CQG provides connectivity to a testing environment where you can test and debug your applications using simulation trading accounts.
Features
•For FIX message consistency, CQG defines maturity as contract last trading date for all contract types.
•For administrative messages, all fields not specified are optional and are ignored by the CQG gateway.
•For application messages, only the specified fields are valid. If a client submits unspecified fields or unspecified field values, the FIX message is rejected via the Session Reject Message.
•For application messages sent from the CQG gateway to clients, it is possible that new fields will be added or existing valid values will be extended. Client applications should be able to process such messages.
Note for QuickFIX users: make sure your session setting ValidateUserDefinedFields is set to “N”.
•The CQG gateway can limit the number of client requests per interval. If the request rate for messages UAF (Order Mass Status Request), UAN (Request for Position), or UAR (Account Data Request) exceeds the limit, the incoming message is rejected via the Business Level Reject. The default limit is no more than 5 requests of any type per account in 20 seconds.
•Except where noted, fields within a message can be defined in any sequence. (Relative position of a field within a message is inconsequential.) The exceptions to this rule are:
•The first three fields in the standard header are BeginString (tag 8) followed by BodyLength (tag 9) followed by MsgType (tag 35).
•The last field in the standard trailer is CheckSum (tag 10).
Note for QuickFIX users: make sure your session setting ValidateFieldsOutOfOrder is set to “N”.
•Orders submitted via the CQG FIX interface are visible in CQG Integrated Client (IC).
•Execution Report messages contain ClOrdID (tag 11) that is populated with a specific format on order actions originating from CQG IC and other CQG clients. This string starts with “CQG_” prefix plus a numeric identifier that corresponds to the order being processed by the CQG gateway, thus allowing full control of such orders by the FIX application.
•The only way to activate a parked order is to send an Order Cancel Replace Request with Tag 18 (ExecInst)=g. See Parked Order Activation Request for details (including a slight deviation from the FIX Protocol). Note that CQG FIX also uses OrdStatus = 9 (Suspended) to refer to orders being held by the CQG gateway for later automatic activation. Execution Reports on such orders do not include Tag 18 (ExecInst) = S. They are not considered parked orders, and thus they can't be activated by FIX message.
•CQG FIX API users are able to trade via the CQG FIX API and use other contract symbols, like Bloomberg, Reuters, or other custom symbols. By default, contract symbols are in CQG IC long format. Users interested in using an alternate symbology should contact CQG. When symbol conversion is enabled and a symbol cannot be mapped, CQG FIX API sends the symbol in CQG IC long format.
•CQG defines a number of instrument tags, which can be enabled for each message. To be able to receive them, please contact customer support.
Currently the FIX server supports flexible adjustment of symbol conversion. Consider the CCMY algorithm:
CCMY is a symbol format where CC is the external commodity code (various lengths), M is a month letter of FGHJKMNQUVXZ pattern, and Y is the last year digit. For example: ESZ9 <-> F.US.EPZ09.
•Currently the FIX API server is able to reset all sessions every 24 hours. Note that this functionality is not in use now but may be in the future.
•Currently FIX logical sessions are tied to connections, i.e. each time the FIX client reconnects, it should use sequence number 1 in the Logon message. But if the session persistence feature is enabled, the client can send the next after the last sent sequence number in Logon message with ResetSeqNumFlag set to ‘N’. CQG implementation of session persistence mechanism requires the client to support PossResend (tag 97) in standard header. During session restoration, some execution reports may be sent repeatedly with different sequence numbers, so the client should have the ability to filter such messages, for example using ExecID (tag 17). Maximum storage time of the persisted session is 24 hours after the last disconnect. Session persistence option is configured based on the FIX vendor. Please contact CQG if you want to enable this feature.
•General FIX 4.2 specification requires Side (tag 54) and Symbol (tag 55) for order cancel request, and the CQG gateway accepts requests with such fields although the only fields that are used to cancel the order are: OrderID (tag 37) and OrigClOrderID (tag 41).
•CQG FIX interface supports the following identifiers provided for Account (tag 1):
•Account ID, provided by the CQG gateway.
•Account name, provided by the CQG gateway.
•FCM account number, provided by the FCM.
The default account identifier type is Account ID, used for both incoming and outgoing messages. The account identifier type is configured based on the FIX vendor. Please contact CQG if you want to change the account identifier type from Account ID provided by the CQG gateway. The CQG FIX interface will reject incoming requests for account names or FCM account numbers that are not unique.
•The CQG gateway limits the number of client collateral inquiries per interval. The default limit is 1 inquiry per second per account. If the inquiry rate exceeds the limit, the incoming message is rejected via the Business Level Reject.
•The CQG gateway limits the number of logon requests during a specific time interval. The current limit is 20 logons within 5 minutes. If the logon rate exceeds that limit, the incoming logon message is rejected via the logout message. This limit can be changed without prior notice.
•The CQG gateway also limits the number of successful logons during a specific time interval. The current limit is 200 logons per UTC calendar day. If the limit is breached, subsequent logon attempts are rejected via the logout message. This limit can be changed without prior notice.