CME Group will send tag 60-TransactTime on the iLink Order Mass Action Report (tag 35-MsgType=BZ), the message that reports the result of a mass cancel, with nanosecond precision instead of milliseconds. If your code assumes millisecond values, it can fail in ways that are easy to miss: a truncated column, a report placed out of order on a timeline, a mass cancel that no longer matches its record. None of these needs to raise an error. The rollout is phased by market segment on the Market Segment Gateways, starting on Sunday 4 October (trade date Monday 5 October).
If you consume iLink 3 order entry messages or CME drop copy for risk, reconciliation and audit trails, the work is to find every place this timestamp is parsed, stored or compared, and to prove each one in New Release before the segments you depend on switch. In practice you should check storage, timeline ordering, fragment grouping and audit output, on the order entry path and the drop copy path alike.
What changes and when
CME currently sends TransactTime on the report in milliseconds. Drop Copy encapsulated payload messages will also reflect these iLink messaging changes. Your drop copy consumers are therefore in scope as well as your order entry sessions. For Futures on the Market Segment Gateways, each group of segments switches to nanoseconds on its own date, 4 October, 11 October or 1 November:
- 4 October: segments 68 (CME and CBOT Equity Futures, excluding E-mini S&P) and 78 (NYMEX Metals, Softs, Alternative Markets, Nat Gas, Non-Crude Energy and Emissions Futures, COMEX Futures).
- 11 October: segments 84 (CBOT Interest Rate Futures) and 88 (CME FX Futures).
- 1 November: segments 62 (CME Single Stock Futures), 64 (CME Equity Futures, E-mini S&P), 70 (CME, CBOT and MGEX Commodity Futures), 71 (CME Livestock Futures), 80 (NYMEX Crude and Crude Refined Energy Futures, DME Futures) and 82 (CME and CBOT Interest Rate Futures).
- Listed derivatives Options on the Market Segment Gateways, and listed derivatives on the Convenience Gateways, are marked TBD.
Until the last group of segments switches, you can receive Order Mass Action Reports with mixed TransactTime precision if you trade Futures across these segments. A segment that has not yet switched sends TransactTime in milliseconds; a segment that has switched sends it with nanosecond precision. Anything you aggregate across segments therefore has to handle both forms. The changes are currently available for customer testing in New Release.
Where millisecond assumptions hide
Four places in your code each assume a precision: the parser, the column that stores TransactTime, the key you sort timelines on and the key you reconcile on. Once a Futures segment on the Market Segment Gateways switches, its reports bring nanosecond values to all four. A wrong assumption need not raise a parse error. It can surface later, as a shortened stored value or a reconciliation that no longer matches.
Start with storage: the raw message log, any normalised internal record, database columns and text exports. A fixed-width field or a string length sized for milliseconds is the obvious candidate for truncation. Do not size these fields from documentation samples. CME's Mass Order Cancel wiki includes sample reports in which tag 60 carries a millisecond value such as 20130604-12:49:32.044. Those samples illustrate the millisecond form; they are not a statement of the current wire encoding in the iLink 3 SBE schema or in drop copy. Check each stored or compared field against reports you capture yourself in New Release.
Next, look at anything that sorts or matches on TransactTime. You may place the report on a timeline alongside execution reports and internal risk events. A switched report carries nanosecond precision, while a stored comparison record may still carry milliseconds. Equality tests, tie-breaking and sort order may then no longer produce the sequence the rest of your system expects. Review any rounding, bucketing or validation rule written on the assumption that TransactTime values are whole milliseconds.
Your audit trail can hold no more precision than the copy of the report it is built from. An audit record built from a stored report row, instead of the raw message, keeps only the TransactTime precision that survived storage. Check which copy your audit process reads, and compare the TransactTime it writes with the raw message.
Large mass cancels need a check of their own. The maximum number of cancelled orders listed in one report is configured to 125. If the entries within a repeating group do not fit into one report, they can be continued in another. If a report is fragmented, all its messages must have the same tag 1369-MassActionReportID. Tag 533-TotalAffectedOrders is then the sum of NoAffectedOrders across all messages with the same MassActionReportID. Tag 893-LastFragment indicates whether the report is complete. In CME's fragmented sample, both fragments carry the same tag 60 value. If your reconciliation groups fragments by TransactTime as well as MassActionReportID, you should check it against nanosecond values from both fragments.
The report's content also limits what you can infer about orders that were not cancelled. If a subset of orders could not be cancelled, the report will contain a list of successfully cancelled orders only. The individual cancel reject messages will not be sent. The report also does not explicitly call out which orders could not be cancelled. If you derive the uncancelled set by difference against working orders, that result depends on a correct match against the report. This means the TransactTime checks above apply there too.
What to test in New Release
Follow TransactTime from the raw message to every record built from it. Each check should produce something you can inspect: a captured message, a stored TransactTime row, an exported audit record. A successful connection and a clean parse log supply none of that evidence, because a truncated column or a misplaced report need not raise an error.
Keep each captured message with the stored TransactTime rows and audit records you compared it against, labelled by market segment. An operations or compliance reviewer can then see that each segment was tested before its switch date.
| Check | Evidence that proves it |
|---|---|
| TransactTime on the report received over iLink 3 order entry | The stored value matches the raw message digit for digit, with full nanosecond precision retained |
| The same report received over drop copy | The drop copy value, after your own processing, equals the order entry value for the same MassActionReportID |
| Every storage and export path | A round trip through database, log and file exports returns the value unchanged |
| Ordering against execution reports and internal events | The reconstructed timeline places the report where your process expects it |
| A fragmented report | A mass cancel affecting more than 125 orders produces fragments that your reconciliation groups correctly, with TotalAffectedOrders equal to the sum across fragments and LastFragment handled |
| Mixed precision | Millisecond and nanosecond reports processed in the same run compare and sort as intended |
| Audit trail output | Records built from these messages carry the precision you intend |
Where OnixS fits
No OnixS release is needed for this change: the OnixS CME SDKs described below already support it. The remaining work sits in each firm's own code and records.
OnixS directConnect: CME iLink3 Order Entry Handler SDK - C++ implementation is also available as .NET and Java implementations. If your order entry application uses it, capture the Order Mass Action Report as your code receives it.
OnixS directConnect: CME iLink FIX Drop Copy Handler SDK - C++ implementation is also available for .NET and Java. It delivers the Order Mass Action Report sent in response to a mass cancel, alongside iLink execution reports, and supports both Convenience Gateway and Market Segment Gateway source sessions. It is CME Drop Copy AutoCert+ certified. If you use the handler, compare the drop copy TransactTime your code receives with the order entry value.
For audit trails, OnixS directConnect: CME Audit Trail Generator is a software component (library) that generates the electronic audit trail from the order entry handler's message log. It is fully compliant with CME Globex Front-End Audit Trail Requirements, as per CME, CBOT, NYMEX, COMEX Rule 536.B.2. It ships in the C++, .NET and Java distributions of the order entry SDK. Include its output in the audit trail check above.
Whichever components are used, the customer still owns how its own code handles the TransactTime value, where and in what form it is stored, how Order Mass Action Reports are reconciled against orders and other records, and the testing in New Release that proves all of it. For more details see OnixS directConnect: CME SDKs and the CME iLink 3 Audit Trail Generator.
Run one mass cancel end to end before your segment switches
Pick one mass cancel workflow you run in production, if possible one large enough to fragment, and reproduce it in New Release. Capture the report from both order entry and drop copy. Then follow its TransactTime through every store and report that consumes it, and compare what arrives at the end with the raw messages. Each difference goes on your list of fixes, and each match is evidence to keep for the segments that follow.
