Very good information on RoE from http://www.fixtradingcommunity.org/pg/structure/tech-specs/implementation-guide/rules-of-engagement
and on FIX Onboarding.
Rules of Engagement |
Many firms with larger FIX implementations have chosen to support their counter parties by supplying them with rules of engagement documents. This section describes the most common elements of an engagement document. Generally, these documents represent a supplement to the official FIX specification as published on the FPL website. Or you may wish to in include these rules in your standard business terms that can be updated yearly.
Session level and connectivity rules
Network Options
This section usually describes the supported networks and vendors. For example, specifics regarding recommendations for particular vendors would appear here. Additionally, mention might be made of special handling of certain providers, the non-support of Internet based connections, required hardware encryption methods, and the like.
FIX Versions
It is important that at the outset of the document the firm describe their support for varying versions of the FIX Protocol. Most firms support at least FIX 4.0, some support more than just this one version. Any differences between message types, or support for a certain message type only starting with a specific version of the Protocol, will be dealt with later in the document.
Encryption Support
This section may contain information about the encryption requirements stipulated by the firm. For example, a firm might require any Internet based connectivity to be encrypted using a specific implementation, such as PGP-DES-MD5 as described in the FIX Protocol specifications. In addition, a firm would list any supported or unsupported encryption mechanisms.
Duplicate and Resend Message handling
While the FIX specification is detailed in describing required handling of potential duplicate information, some firms choose to implement additional safety checks to protect themselves and the client they connect with. This section is the place to detail any such implementation.
For example, firm SELL will know, and assume the counter party knows, that tags 43 and 97 can indicate potentially duplicate information, either contained within a message with the same sequence number, or in a message with a new sequence number. The rules in processing these messages are detailed and mostly clear, however, firm SELL might decide to improve on the session level handling of duplicates, and institute a rule as follows:
If a message is received from counter party BUY today that shows the following identical fields it will be considered a duplicate, and will be excluded from further processing: Symbol (55), Side (54), and ClOrdID (11).
This rule would be implemented one level above the session layer, and serves as an additional safe guard against duplicate information.
Start of Day / End of Day Procedures
In many cases, a publisher of a rules of engagement document will describe here the ways a FIX session will be started and terminated. Information reflecting the roles and responsibilities of each counter party to the connection can be found here.
For example, a firm might decide to initiate all connections, and not accept any incoming requests for a TCP socket. Additionally, a schedule will be defined here outlining the minimum down time of the firm's infrastructure to accommodate the roll-over of sequence numbers. Some firms allow End of Day (EOD) to run at any time during the day.
Counter Party Identification
Every party to a FIX connection generally has their own way of identifying originator and destination for each connection. In this section, you are likely to find information about the preferred way of identification, such as values for SenderCompID (49), SenderSubID (50), TargetCompID (56), TargetSubID (57), and any OBO (on-behalf-of) ID values required or supported.
Failover Procedures
Many firms operate two or more production machines for FIX connectivity. In some cases, network equipment is installed that make the number of machines at the counter party transparent to the other side in that a virtual IP address exists to which connection request are issued or from where they originate.
Usually, when a machine handling a FIX connection fails, the connection will drop. While a brief interruption of service may result, generally all it takes to get back to normal operating conditions is to reconnect, and sync up sequence numbers (resend any messages generated but not received previously).
It helps if this section contains any procedures to follow in case of a failure of hardware or telecom equipment describing the above processes in as much detail as possible.
Definition of Security ID Conventions
For any trading system, the correct identification of securities in a FIX message is of utmost importance. There are several fields within each FIX message, incoming or outgoing, that allow for identification of securities. A rules of engagement document should specify which symbology is preferred, and, if more than one is supported, which conventions are acceptable.
For example, Symbol (55) might be required in the implementation, but the last word in identity and validation of the security might be performed based on the combination of SecurityID (48) and IDSource (22) to avoid problems with mistyped symbols. Additionally, some other fields might be accepted in an incoming message, but remain unused for validation or identification purposes.
Additionally, there are cases in international symbology where an ID number describes a security listed in more than one location (for example, ISIN numbers are not exchange specific. Rules governing the handling of such cases should be outlined in this section as well.
Lastly, not all ID sources might be accepted or understood by the party, so it is a good idea to list the acceptable forms of SecurityID (48) here as well.
Business message types
It is not always practical or desirable for a counter party to support or even accept all FIX message types. For example, a sell side firm might not accept list orders, but single orders only. This section contains the "meat" of the rules of engagement as it describes the messages supported, any modifications or customizations desired to properly process the message, and the like. A possible list of business message types detailed in a rules of engagement (from a sell side perspective) could include the following items:
- Indications of Interest (out)
- Single Orders (in)
- Day Orders (in)
- Multi-Day Orders (in)
- List Orders (in)
- Day Orders (in)
- Multi-Day Orders (in)
- Order Modify Requests (in)
- Order Cancel Requests (in)
- Order Cancel Rejects (out)
- Don't Know Trade (in)
- Order Status Requests (in)
- Report Busts and Corrections (out)
- Allocations (in)
- Allocation Acks (out)
In addition to the business message types accepted this section could include any conventions for single fields within the business messages, such as the use of the following:
- Account (1)
- HandlInst (21)
- OrdType (40)
- Price (44)
- Text (58)
- TimeInForce (59)
For example, some firms require a certain value to be contained in the Account (1) field for every message received, others only support certain order types (40), and some firms may not accept multi-day orders. This is the area of the rules of engagement to list any requirements of for specific field values.
Test scripts
In order to ensure safe and continuous operation of any system, particularly mission critical transaction handling components, testing is highly recommended. At the time of this writing, no formal standard for certification of FIX engine technology and abilities exists; however, many firms have created specific testing scripts to be executed by a newly connected counter party. This is the section to describe the test bed environment along with any specifics that would help quickly implement the testing effort. The current version of the FIX Protocol (4.4) contains an extensive amount of material that describes the standardized changes in order state for a number of scenarios, along with expected behaviors for session level state changes. These parts of the official specification should form the basis upon which any testing procedures are built.
Examples and Glossary
A really well executed rules of engagement document contains sample message sets that can be used for testing, or that describe in more detail the instructions given earlier. For many implementers, seeing the actual message shortens the learning cycle tremendously. Another good idea is a short but precise guide to language used in the document. For example, some people might understand "Cancel/Replace;" others might mean "Modification," with the ensuing consequences in changing order id and other parameters in a message.
Document Status: FPL's Global Steering Committee has approved this document for release on an online basis to FPL members only. This is the first edition of the Implementation Guide. The Global Fixed Income Committee, as sponsor of this Guide, advises members that the Guide may undergo frequent revision in format, content, or style in the coming months. Among these revisions may the system for assigning edition or version identifiers to the Guide. Whenever the Guide is revised the Global Fixed Income Committee will endeavor to notify all members through the FPL Program Office.
