THE 24-HOUR FIX QUESTION BANK

Short of it, for now. The group expects hours to extend in steps to 23/5 rather than jump to 24/7, because clearing, settlement, corporate actions, surveillance and staffing all still assume a break. Exchanges are adding a night session; the SIPs, DTCC and NSCC plan to run from 8 p.m. ET Sunday to 8 p.m. ET Friday. The FAQ notes some firms already run true 24x7 models with no pause.

Under the Nasdaq-style 23/5 model: pre-market 4:00 to 9:30 a.m. ET, regular hours 9:30 a.m. to 4:00 p.m., after-hours 4:00 to 8:00 p.m. (all part of one Day session), a maintenance pause 8:00 to 9:00 p.m., then a night session 9:00 p.m. to 4:00 a.m. that counts toward the next trade date. 8:00 p.m. ET is the end of the trade date.

No. It is an operational choice exchanges have made, to leave time for maintenance and testing, corporate-action processing, clearing and the date rollover. It is not universal: some platforms run 24x7 with blue-green or rolling deployments, and some markets use a weekly maintenance window instead of a daily one.

Their obligations and downstream dependencies differ from a primary listing exchange's, so some maintenance can be done with less market-wide impact or designed around altogether. The FAQ is careful that this is about each venue's responsibilities and design, not venue type alone: any venue running long hours still needs a controlled way to maintain and recover.

At 8:00 p.m. ET. Per the FAQ, NSCC treats the overnight session as 8:00 p.m. to 4:00 a.m. ET and does not recognise the exchanges' 8 to 9 p.m. pause as a separate session: exchanges simply submit nothing in that hour, while ATSs keep trading.

336 names the session; 625 names the phase within it, such as pre-trading, opening auction, continuous, closing auction or post-trading. A phase always belongs to a session. FIX defines sessions and phases, not clock times: each venue publishes what its labels mean, and that published list is authoritative.

As the Day session in its post-trading phase: 336=1 with 625=5. It sits on the same trade date as a 10 a.m. print, because the US trade date does not roll until 8 p.m.

As the After-hours session in continuous trading: 336=6 with 625=3. It already belongs to the next trade date.

Because the US trade-date boundary is 8 p.m., and post-market trades carry the same trade date and clearing date as the regular session. Keeping 4 to 8 p.m. inside the Day session, phase 5, keeps the label consistent with the date. Evening remains available for markets that run a genuinely separate third session.

For ATSs trading through it: 336=6 with 625=3, the same as the rest of the overnight session. Exchanges print nothing in that hour; they can signal the paused state with a TradingSessionStatus message using phase 7 (Quiescent).

Yes, the FAQ recommends it. A receiver cannot tell an empty 625 from a venue that does not support it. One open point it records: many OMS and EMS platforms already express auction participation through time in force and order type, and reconciling the two approaches is unresolved.

Publish them in FIX. A TradingSessionList (35=BJ), with updates via TradingSessionListUpdateReport (35=BS), can carry start, open, close and end times for each session and phase, and TradingSessionStatus (35=h) announces the transitions as they happen.

No. The tag number is shared but the dictionary is not. Per the FAQ, DTCC defines its own values for four brackets (pre-market, regular, post-market and overnight), and its overnight processing controls key off that value. There is no agreed one-to-one mapping yet; Appendix A sets out the comparison and a proposed composite.

No. Per the FAQ, NSCC reads 336 only, so 625 does nothing on the clearing leg. Firms may still populate it to keep one convention across trading and clearing.

The submitting firm. NSCC does not derive it, because the execution timestamps it receives are not reliable enough for that. The practical advice: translate at the edge and validate before the trade goes out, since an invalid value is rejected.

It is ambiguous unless the venue publishes what its business day is. In the US a Day order could span 4 a.m. to 8 p.m. ET. The FAQ advises against TimeInForce(59)=0 on its own; paired with a TradingSessionID it means good for that session, and the venue should state which phases a Day order is eligible for.

EffectiveTime(168) for when it starts and ExpireTime(126) for when it ends. Both are UTC timestamps, which removes time-zone and session-boundary ambiguity. Better still, target the session or phase you want and let the venue resolve the times from its session list; add ExpireTime only when you need a precise cut-off.

Not as the main control. ExpireDate is a local market date and the cut-off time depends on local practice, which is ambiguous once a session spans midnight. The FAQ recommends against it in continuous or overnight sessions unless the venue publishes its business day and expiry convention.

TimeInForce(59)=6 (Good Till Date) with an ExpireTime(126), or TimeInForce(59)=A (Good for Time) with ExposureDuration(1629) and, optionally, ExposureDurationUnit(1916) for a duration from entry.

Target the session in the order's TradingSessions group: for an overnight ATS order, one entry with 336=6 and 625=3. Pre-market only is 336=1 with 625=1; post-market only is 336=1 with 625=5; the full Day session is 336=1 with 625 left out. An order can list more than one session.

The FAQ's example: a limit order sent at 19:00 UTC with EffectiveTime 19:00 UTC and ExpireTime 08:00 UTC the next day stays live from 2 p.m. ET through midnight to 4 a.m. ET. At expiry the venue cancels the remainder with an unsolicited cancel. The timestamps settle validity; TradeDate(75) separately carries the business date.

No new fields are expected. Existing mechanisms cover order validity; the shift is toward orders with explicit validity windows instead of broad day or night labels. Venues should spell out how duration, session eligibility and expiry work across regular, post-market and overnight trading.

Whatever the venue publishes. Participants should know whether a GTC order stays live overnight, pauses in maintenance or control windows, and how corporate actions and halts treat it. Many exchanges carry GTC orders past the daily reset; CME Globex, for example, removes them at the end of the trading week unless weekend trading is enabled.

The FAQ points to the FIX Recommended Practices for 24x7 Sessions for this, in particular its sections on sequence number format and message resend limits.

With an explicit UTC ValidUntilTime(62). Valid until the close stops working when the day spans midnight. An IOI meant for one session should end at that session's published boundary, and one that spans sessions should say so. IOITransType(28) works as before; what changes is that validity must be stated, not assumed.

The next one. In US overnight ATS trading, market practice has settled around an 8:00 p.m. ET roll, so anything after it belongs to the next trade date. The FAQ notes there is still no single global transition point, and some venues may roll at 4 p.m.

Monday. TradeDate(75) is the logical business date, not the calendar day the trade happened on.

No, and the FAQ is emphatic. Timestamps say when something happened; TradeDate(75) says which business date it belongs to. After 8 p.m. ET the two diverge until midnight, and holidays apply to business dates, not clock times. Populate TradeDate explicitly, including on execution reports.

TradeDate is the business date the venue assigns; ClearingBusinessDate is the one the clearing house assigns. For overnight cash equities they normally match, but they can diverge when the clearer's cut-off differs from the trading cut-off, as it can in derivatives. The FAQ's point is that firms need to state which field drives settlement.

Not on its own, the FAQ says. It carries a date but no time, and a single message cannot tell you whether that date is the clearer's current or next business date without the clearing calendar. The group flags this as a wider standards gap, with parallel discussions at FIA, ISDA, ICMA and in the CDM community.

Three, per the DTCC guidance the FAQ summarises. TradeReportID(571) restarts at 1 each processing date. ClearingBusinessDate(715) is in the real-time output from June 2026, and 24x5 participants must use it to keep trade IDs unique. TradingSessionID(336) is required for anyone submitting overnight trades, and an invalid value is rejected.

Pair it with ClearingBusinessDate(715). With two clearing dates open at once, 571 alone can repeat; the combination is the reconciliation key. A trade booked to the wrong date is fixed by cancel and resubmit.

On T+1 from its next clearing date. Per the FAQ, a post-market trade keeps the same trade and clearing date, while an overnight trade posts to the next clearing date once the sending firm has finished its end-of-day processing. The FAQ's example: a 9:05 p.m. ET trade on Thursday 3 September 2026 carries Friday's dates and, with Monday a holiday, settles on Tuesday 8 September.

It posts to the current processing date, even though the venue's TradeDate already shows the next day. The clearing date rolls when each sending firm completes its own end-of-day cycle, and TradeReportID numbering restarts at 1 after that. Hence the FAQ's advice to reconcile on ClearingBusinessDate plus TradeReportID.

No. Existing FIX session models can run continuously, provided both sides agree the operating boundaries. The FAQ describes three patterns in use: date-partitioned numbering (restart per date, or put the date in the identifier), one continuously rising sequence, or replay limited to a defined window. Agree and document the choice in advance.

Yes, if both counterparties choose to, but the goal is recovery you can predict and audit, not an unbroken connection. Agree sequence management, how far back replay goes, monitoring, and when to re-establish the session rather than recover it.

Don't paper over it with a gap fill. A Sequence Reset in gap-fill mode is for messages intentionally skipped, such as administrative ones, not for messages you can no longer recover. If recovery cannot be completed within the agreed policy, the safer response is to end or re-establish the session so both sides agree on its state.

Yes, per the DTCC guidance the FAQ quotes. A FIX sending firm must balance and complete the current processing day, then disconnect and reconnect before submitting next-trade-date trades, with TradeReportID(571) starting again at 1.

There is no single answer; it depends on topology and deployment model. The FAQ's guidance is to document the approach in the session operating agreement with counterparties, including how they will be notified and what recovery to expect.

The risk is that trading starts before custodians, clearers or OMSs reflect the event, leaving positions and reference data out of step. Some overnight venues halt order entry in affected names, often signalled through reference data files rather than the market data feed. Nasdaq proposes halting affected names from 8 p.m. the night before the effective date through the overnight session. FIX Extension Pack 299 carries a corporate-action reference price.

The group did not agree it is feasible or desirable across all markets, given different structures, asset classes, rules and post-trade dependencies. The near-term path it favours: venues publish clear halt, pause, reference-data and exception-handling practices, and harmonise where they can.