Firewall blocks a sample program. What should we do?: Update the firewall rules or temporarily disable the firewall. This usually resolves the issue.

How do we receive the multicast feed in test environments?: In test environments, the multicast feed is provided through tunneling. Run the tunnel proxy program provided by ICE. The proxy connects to ICE over TCP, receives all messages, and republishes them as multicast traffic on your local network. For details, refer to the iMpact Multicast Feed Technical Specification and the Getting Started guide.

How do we test connectivity to TCP or tunneling servers in test environments?: Use telnet to connect to the target IP address and port. If the connection fails, work with your network team to investigate the issue. All test ports are open for Internet access.

How do we determine the multicast channel for a market type?: The supported market types and their corresponding multicast product groups are listed in the appendices of the ICE iMpact Multicast Feed Message Specification.

Why do I get code 3 (password expired) in Login Response for the test environment?: The password expires immediately after the ID is created. This error is returned until the password is changed through WebICE.

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

Should TradeMessage reduce order quantity instead of removing the order? (Full Order Depth Only): No. In a partial fill, the exchange removes the original order and creates a new order with a different ID. If the client only decreases the quantity of the original order, the local book becomes incorrect. For this reason, delete the order from the local book when a TradeMessage is received.

How is order priority preserved when a partial fill creates a new order? (Full Order Depth Only): The new order keeps the same entry timestamp as the partially filled order. Use that timestamp when sorting orders at the same price level. For clients that do not track order priority within a price level, this is not relevant.

Can DeleteOrderMessage reference an order ID not seen in AddModifyOrderMessage? (Full Order Depth Only): Yes. This can occur in some scenarios. The client can ignore the DeleteOrderMessage in that case.

Can TradeMessage reference an order ID not seen in AddModifyOrderMessage? (Full Order Depth Only): Yes. This can occur in some scenarios.

How should I process the 'H' Investigated Trade message?: This depends on the client application. The Investigated Trade message does not affect the order book, so some customers ignore it. A trade under investigation usually has one of two outcomes: it is later cancelled, or it returns to its original status. If the trade is cancelled, a Cancelled Trade Message is sent.

How should I process the 'I' Cancelled Trade message?: The Cancelled Trade message does not affect the order book because the system does not restore the orders. If the client tracks trades, it should mark the trade as cancelled or remove it. A Cancelled Trade message is usually followed by a Market Statistics message with updated values. If the client calculates market statistics independently, it must apply the adjustment itself.

What is the difference between 'D' Market Snapshot Order and 'E' Add/Modify Order? (Full Order Depth Only): A Market Snapshot Order is sent immediately after the snapshot message. An Add/Modify Order is a real-time message. For order book processing, both messages can be handled in the same way.

How should I handle the IsImplied flag? (Full Order Depth Only): Implied orders, including both spread and outright futures orders, are tradeable and must be shown in the book. When using WebICE for comparison, note that WebICE has its own implied engine and may display implied prices much farther out on the curve. As a result, WebICE may not match the iMpact Price Feed unless the WebICE implied engine is turned off. For more information about implied orders, see Additional Implieds FAQ.

What does the IsSystemPricedLeg flag in TradeMessage mean?: This flag indicates whether the trade price was generated by the system. System-priced legs usually result from an exchange-native spread, such as a crack spread or calendar spread, executed together with another spread market on the system. In these cases, the system publishes the transaction price of the spread and the leg prices to the relevant leg market contracts. System-priced leg prices do not update contract statistics such as High, Low, and WAP. Because of system pricing mechanics and exchange-imposed price reasonability checks, one or both legs of a system-priced spread can violate the resting bid or ask in the leg market at the time of trade. Therefore, system-priced legs must not be treated as indicative bid or ask prices for the leg market contract. Accordingly, they must not be used as valid real-time market price indicators and must not trigger client-side synthetic order types in the leg market, such as Stops or Stop Limits.

Does iMpact feed volume include busted trades, block trades, or other off-market trades?: No. It does not include busted trades, block trades, or similar off-market trades.

Is a market statistics message sent after a Cancelled Option Trade Message?: Yes.

How should we use OrderSequenceID in AddModifyOrderMessage? (Full Order Depth Only): OrderSequenceID was used for out-of-sequence detection and remains for legacy reasons. It can be ignored.

How should I interpret IsRFQ? Should such orders appear in the book?: Orders with IsRFQ set cannot be traded and must not be shown in the book.

Is conformance required before production access?: Yes. Contact confo.nosp@m.rman.nosp@m.cesup.nosp@m.port.nosp@m.@thei.nosp@m.ce.c.nosp@m.om when you are ready for conformance.

Can you confirm conformance for ICE Futures Europe S2F and ICE Futures US S2F markets?: ICE approves S2F market access on a per-customer basis. Each ICE customer must certify independently, regardless of any work completed by OnixS in advance. For OnixS to certify as an ISV, separate legal agreements and exchange fees would apply. Because each customer must still certify directly with ICE after ICE approval, there is no practical benefit in OnixS certifying as an ISV. From a technical perspective, the OnixS implementations already work correctly with S2F. The remaining requirement is the legal and conformance process mandated by ICE. This is ICE policy.

Does an Adjusted Trade keep the original trade ID and timestamp?: Yes. The Adjusted Trade has the isAdjustedTrade flag set to true and keeps the original trade timestamp.

Is the local order book valid after each message in a multicast block?

This depends on which channel the client uses: PL or FOD. The multicast blocks themselves do not provide any special information for book processing. For Price Level live updates, this does not matter. For Full Order Depth live updates, clients may need to process bundle marker messages, depending on their requirements. The book may be temporarily inconsistent while a bundle is being processed. For example, an order may be removed before the remaining quantity is added back to the book. Example:

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

Some client books may not be valid while messages 10051-10300 are being processed. The book becomes valid again after the bundle ends at seq No 10301. The number of multicast blocks used to carry these messages is not relevant.

How do I handle 'Login request rejected because the last attempt was fewer than 15 seconds ago'?: This is an exchange limitation. To avoid this issue, implement a throttling mechanism in your application. This can occur when Handler::start() is called repeatedly without a timeout between attempts.

Must a client register directly with ICE to access ICE iMpact through OnixS?: Yes. OnixS provides software only. To access ICE iMpact market data, the client must contact ICE directly.

What does "Number of enqueued packets exceeded configured limit" mean and how do I address it?: This is the PacketQueueOverflow warning: one of the Handler's internal packet queues (used while snapshot recovery is in progress) overflowed and the oldest packets were dropped. It is driven by the volume of packets arriving during a recovery window and is tuned through the queue-size settings in SnapshotRecoveryOptions. See Warning Handling for the full explanation and sizing guidance.