Firewall blocks a sample program. What should we do? Updating firewall rules or simply turning it off usually solves the issue.

How can we get multicast feed in test environments? Multicast feed for test environments is provided through tunneling. All you need is to run the tunnel proxy program provided by ICE, which connects to ICE through TCP, gets all messages and sends them out through multicast on your local network. Please refer to iMpact Multicast Feed Technical Spec and Getting Started document on more details.

How to test whether we can connect to the TCP or tunneling servers in test environments? Just telnet to the IP/Port. Work with your network department if there is a problem. All our test ports are open for access through the Internet.

How do we know what multicast channel is used for a particular market type? The list of supported market types and their corresponding multicast product groups are listed under the appendices section in ICE iMpact Multicast Feed Message Spec.

I tried to connect to the test environment and got code 3 (password expired) returned in the Login Response. What happened? Password expires right after ID is created. A client gets this error until a password is changed through WebICE.

How can I verify that my local book is correct? WebICE can be used for comparison. Contact price feed support to get WebICE test ID for test environments. You can also use the iMpact feed test client included in the Getting Started package.

Upon receipt of TradeMessage, shouldn't I deduct the quantity for the order in my book instead of removing the order? (For Full Order Depth Only) In case of partial fill, the exchange removes the old order and creates a new order with a different ID. If client deducts the quantity instead of removing the order that got partially filled, it will be wrong. Thus we recommend the client to delete the order from the local book upon receipt of a TradeMessage.

If a new order is created in case of partial fill, how can client keep the priority of the order? (For Full Order Depth Only) The entry timestamp of the new order is the same as that for the partially filled order. And that should be used in sorting at a particular price level. Apparently, for the client that doesn't care about order depth at a price level, it is not an issue.

Could client get a DeleteOrderMessage with order ID not referenced by AddModifyOrderMessage previously received? (For Full Order Depth Only) Yes, that could happen under certain scenarios. The client can ignore the DeleteOrderMessage in that case.

Could client get a TradeMessage with order ID not referenced by AddModifyOrderMessage previously received? (For Full Order Depth Only) Yes, that could happen under certain scenarios.

What processing should I be doing on the 'H' Investigated Trade message? It depends on the client application. However, Investigated Trade message has no effect on the order book and thus it is ignored by some customers. A trade placed under investigation typically ends up in one of two outcomes: it is either subsequently canceled, or returned back to its original status. If the trade is canceled, you will receive a Canceled Trade Message.

What processing should I be doing on the 'I' Canceled Trade message? Canceled Trade Message has no impact on the order book because the system would not put the orders back. If the client keeps track of deals, it should flag or remove the canceled trade. Canceled Trade message is usually followed by a Market Statistics message with an update of the stats. However, if the client does its own market stats processing, it should make the adjustment accordingly.

I am not sure of the differences between message 'D' (Market Snapshot Order) and 'E' (Add/Modify Order). Both messages carry the same information and are treated the same in my code. Am I missing something obvious? (For Full Order Depth Only) Market Snapshot Order is sent to the client right after the snapshot message, while "Add/Modify Order" is real-time message. But they could be treated the same for updating your book.

How shall I treat the IsImplied flag? I assume this flag applies to spread orders being implied out of the plain futures orders and also plain futures orders being implied out of the spread orders. The question is, are implied orders (both spread and plain futures) tradeable and therefore do they need to be shown on the book? (For Full Order Depth Only) Implied orders (both spread and plain futures) are tradeable and they should be shown on the book. If you are using WebICE for comparison, please be aware that WebICE has its own implied engine and might display implied prices much farther out the curve. What you see there might not match with what you get via iMpact Price Feed unless WebICE's implied engine is turned off. For more details on implied orders: Additional Implieds FAQ

What is the IsSystemPricedLeg flag in TradeMessage? This value indicates if the trade price is system generated or not. System priced legs are typically the result of an exchange-native spread (crack spread or calendar spread) being executed in conjunction with another spread market on the system. In these instances, the system will notify the transaction price of the spread and the leg prices to the appropriate leg market contracts. System priced leg prices do not update contracts statistics, specifically High, Low, and WAP. Due to system pricing mechanics and exchange imposed price reasonability checks, there is the very real potential that one or both legs of a system price spread may violate the resting bid/ask of the leg market contracts at the point of trade. Systempriced legs cannot be relied upon as indicative of the bid/ask prices in the leg market contract. Accordingly, these system priced leg prices cannot be relied upon as valid real-time market price indicators, and thus, must not be relied upon to trigger client side synthetic order types in the leg market contracts such as Stops, Stop Limits, etc.

Does the Volume figure supplied by iMpact feed contain busted trades and block trades and other things that might be considered actions not initiated by the matching engine (i.e. off-market trades)? No. It doesn't include busted trades or block trades.

Will you send a market statistics message following a Canceled Option Trade Message to reflect the change of market statistics? Yes.

What should we do with OrderSequenceID in AddModifyOrderMessage? (For Full Order Depth Only) OrderSequenceID was used for out-of-sequence detection and it is there for a legacy reason. You can ignore it.

How do I interpret IsRFQ? Can such orders be traded? Or should they not be shown on the book? (For Full Order Depth Only) They can not be traded, and thus should not be shown in the book.

Is conformance required prior to production access? Yes. Please contact confo.nosp@m.rman.nosp@m.cesup.nosp@m.port.nosp@m.@thei.nosp@m.ce.c.nosp@m.om for conformance when you are ready.

Can you confirm that conformance tests for the ICE Futures Europe S2F and ICE Futures US S2F markets have been passed? ICE S2F market access is approved on a customer by customer basis, therefore any ICE Customer will each need to certify on their own regardless of any work that OnixS do ahead of time. For OnixS to certify as an ISV there are separate/additional legals and exchange fees that would be applicable to certifying. Since each customer would need to certify directly with the ICE anyway, following their individual approval by the ICE, there is no benefit to OnixS certifying as an ISV. Regarding the technical point of view, the OnixS implementations already work well with S2F. It is just a legal and conformance hurdle that is mandatory for the ICE customer. This is ICE policy.

Is an Adjusted Trade comes back with the same id as the original Trade and also is the DateTIme on the Adjusted Trade same as the original Trade? Yes, the Adjusted Trade will have the IsAdjustedTrade flag set to Y and will have the same timestamp of the original deal.

Is it correct that after processing every message in a multicast message block a local order book remains valid? This will depend on which channel (PL or FOD) the client uses. The message blocks themselves do not provide any information for book processing. For PriceLevel live updates, it does not matter. But for FOD live updates, depending on their requirements, they might need to process the bundle marker messages. The book might not be "valid" when a client is in the middle of processing a bundle. It also depends on what's "valid" in their view. There will be some "transient" state during a bundle (e.g, an order was removed but remaining qty has not been added back to the book yet).

For example,

seq No 10050, MessageType 'T' , MarkerType 'S' (bundle start)
seq No 10051 - 10300 a bunch of Orders/Withdraws/Deals
seq No 10301, MessageType 'T' , MarkerType 'E' (bundle end)

Some of the client's books might not be valid when they are processing messages 10051-10300. Books will be valid again after the bundle ends (seq No 10301). It does not matter how many multicast blocks are there to carry these messages.

How to work around "Login request rejected because the last attempt was fewer than 15 seconds ago"? This is an exchange's limitation and to work around this issue you need to implement throttling mechanism in your application. This issue may happen when OnixS::ICE::iMpact::MarketData::Handler::start() is called without timeout between attempts.

In order to establish the connectivity with the ICE iMpact data feed through OnixS does a client need to register directly with ICE or can this all be done through OnixS? OnixS as a software company only provides software solutions. To get access to ICE iMpact market data you need to reach ICE directly.