24-Hour Markets: An Industry FAQ on 24-Hour Trading, Market Structure and Operational Challenges

1Introduction

This FAQ document has been developed by the FIX Trading Community’s 24-Hour Markets Working Group to address the key questions facing the industry as trading moves toward extended and continuous market operations.

Working group members (including execution venues, clearing firms, broker-dealers, asset managers and technology providers) have identified the questions most relevant to practitioners and collaborated on the answers provided here. The document builds on prior work of the FIX Continuous Markets WG, including the FIX Recommended Practices – 24×7 Sessions 1 published in 2023, and extends that guidance to reflect current market developments and emerging operational challenges.

The FAQ covers topics across trading hours and market structure, order handling, trade-date conventions, FIX session management, corporate actions, and post-trade processing.

It is intended as a practical reference for firms assessing readiness, designing systems, or aligning with industry peers on 24-hour trading standards.

This document describes FIX Protocol mechanisms and recommended practices. Where it references a specific market implementation, including the US 23/5 structure and DTCC clearing conventions, that material is included to illustrate how the standard is being applied in one market and is not a recommendation.

FIX does not advocate for any particular session structure, trade-date transition point or maintenance window. Markets in Europe, Asia and elsewhere are adopting different models on different timelines, and firms should follow the published rules of the venues and clearing infrastructure they use.

If you have any questions or would like to discuss further, please contact us at fix@fixtrading.org

1 https://fixtrading.org/recommended-practices-24x7-sessions/

2Trading Hours & Market Structure

Current industry developments point towards incremental extension of trading hours to 23/5 rather than a leap to full 24/7 continuous trading. While crypto markets have shown that 24/7 trading is technologically feasible, the market structure and regulatory requirements of traditional securities markets (including clearing and settlement cycles, corporate action processing, surveillance and staffing considerations) make a phased and incremental approach far more likely in the near term.

This is already being implemented in the US, where the SEC approved Nasdaq’s proposal 2 to extend trading hours from 16 hours to 23 hours a day five days a week, following similar approvals for 24X and NYSE Arca. Some US Alternative Trading Systems (ATS) are already offering 24-hour trading, including BlueOcean, MOON ATS and Bruce Markets. The US tape providers, the Securities Information Processors (SIPs), and clearing infrastructure providers DTCC and NSCC have announced plans to extend operating hours from 8pm ET Sunday through to 8pm ET Friday. The one-hour 8–9pm ET technical pause applies to the exchanges only; DTCC and NSCC operate without a pause.

Below is an overview of the US trading day, based on new 23h hours/ 5 days a week structure. Exchanges operate from Sunday 9pm ET to Friday 8pm ET.

Figure 1: US trading day under new 23/5 mode (Nasdaq model):

Source: Nasdaq.

FIX members also note that there are firms, both regulated and unregulated, which are running truly 24x7 trading models with zero downtime or pause today.

Key considerations under the new operation model:

• Longer pre-market and after-hours trading windows , covering most of the 24-hour cycle. There will also be a one-hour trading pause, which marks the end of the trading day, for technical and maintenance reasons. The night session will have reduced functionalities (incl. no unpriced or pegged orders)

2 https://www.nasdaq.com/24-hour-trading-hub

• A clearly defined “core liquidity session”. It is expected that liquidity and price discovery will continue to concentrate during the main day session, and that the market open and close will remain significant liquidity events. Some expect materially thinner trading volumes, with potentially wider spreads and higher volatility during overnight trading. It is also not yet clear whether there will be sustained institutional demand for full weekend trading in a 24/7 model across traditional asset classes
• Greater reliance on automation and algorithmic market making to support thinner liquidity during off-peak hours. Staffing is another consideration that might force firms to lean more heavily on automated trading protocols to support round the clock trading
• Cost-benefit trade-off . Supporting 24×7 trading would require continuous staffing, technology support, and monitoring across all market participants. For most firms, the incremental benefit of weekend trading does not yet justify the associated cost, particularly given uncertain volumes.
• Gradual convergence across regions , enabling more seamless cross-time-zone trading. Some venues have cited growing overnight trading interest from investors in Asia and other non-US jurisdictions as one of the key drivers
• Post-trade and infrastructure limitations . Moving to 24×7 would require significant transformation across the entire market infrastructure stack, not just trading venues. By contrast, extending to 24×5 is seen as a a manageable step that leverages and, in some cases, extends existing operational cycles

The trading halt is an operational and not a regulatory requirement. Most US exchanges have built in a typically daily scheduled pause between the Day Session and Night Session to leave time for:

• Hardware and software maintenance and testing
• Corporate actions processing
• Trade clearing and date rollover

Based on member feedback, there are different models in the market:

• Some trading platforms (e.g. Connamara) run 24x7 with zero downtime and pauses by using blue-green deployments and rolling deployments for software and infrastructure updates.
• There are also exchanges (e.g. CME) that run one or more weekly maintenance window(s) instead of daily one

Some ATSs may not require the same scheduled pause because their operating model, regulatory obligations, and downstream dependencies can differ from those of primary exchanges. Exchange pauses are often driven by responsibilities such as coordinated market operations, reference data and corporate action processing, session controls, and broader market integrity obligations. By contrast, an ATS may be able to handle certain maintenance or recovery activities with more limited market-wide impact, or through architectural approaches that reduce the need for a full pause.

That said, the need for a pause is not solely a function of venue type. Any trading venue operating extended or continuous hours still needs a controlled approach for software and infrastructure maintenance, recovery, and event processing. The appropriate model depends on the venue’s responsibilities, design choices, and the expectations agreed with participants.

3Orders, Order Types & Trade Lifecycle

For orders in 24-hour or multi-session environments, FIX recommends using EffectiveTime(168) to define when the order becomes valid and ExpireTime(126) to define when it expires. Both are UTC timestamps, which helps remove timezone and session- boundary ambiguity.

• ExpireDate(432) captures the date of order expiration (i.e. the last day the order can trade) and is always expressed in terms of local market date (LocalMktDate). The time at which the order expires is determined by local market business practices. In a 24- hour environment this is ambiguous without a published definition of the venue’s business day, expiry cut-off and time zone, whereas ExpireTime(126) is UTC and needs none. Therefore, ExpiryDate(432) is not recommended for expressing order validity in continuous or overnight sessions where the relevant trading window can span midnight or cross session boundaries (unless the venue publishes its business day and expiry convention)

TradeDate(75) represents the logical business date for the trade , whereas timestamp fields identify actual points in time. For example, where a trade takes place Sunday night, the applicable TradeDate(75) field value would be Monday, regardless of the physical calendar day. TradeDate(75) should be populated where it is needed for settlement, processing or downstream business-date assignment, including on ExecutionReport(35=8) messages. Systems should not infer TradeDate(75) from TransactTime(60), SendingTime(52) or message arrival time.

• TradeDate is the business date of the trade assigned by the venue, which is separate to ClearingBusinessDate(715), which is the business date assigned by the clearing organisation. For most overnight cash equity transactions these two dates coincide, however they can diverge where the clearer’s day-roll or cut-off is different than the trading session cut-off (for example in derivative transactions). As noted in the question on FIX tags impacted by 24/5 trading below, the DTCC breaks out ClearingBusinessDate(715) separately in the UTC Common Trade Input Format.

The following table shows how multiple trading sessions and their phases (a.k.a. sub sessions) over a 24h period can be identified with standard FIX fields. The sessions are identified with TradingSessionID(336) and it is recommended that this field is used together with TradingSessionSubID(625) to identify the trading phase within a specific trading session. Each session may have additional phases before and/or after the trading phase. The additional phases shown in the table below are only for illustrative purposes.

• Venues should attach start and end times to the different sessions and their phases and can communicate this information with the TradingSessionList(35=BJ) and TradingSessionListUpdateReport(35=BS) messages. Explicit start and end times of sessions and phases may be communicated with TradSesStartTime(341), TradSesOpenTime(342), TradSesCloseTime(344) and TradSesEndTime(345). Changes from one session to another and between phases of a given session can be communicated with the TradingSessionStatus(35=h) message.
• TradingSessionSubID(625) is an optional field. It is a sub-identifier for a trading phase within a trading session . The recommendation is to populate this field. A consumer cannot distinguish an unpopulated FIX field 625 from a venue that does not support it. Members also noted that auction participation is already captured by many OMS and EMS systems through TimeInForce(59) and order type rather than through TradingSessionSubID(625), and that reconciling the two approaches remains an open topic for venues and vendors.
• Orders may use TradingSessionID(336) and TradingSessionSubID(625) to reference a session or phase during which they are to be valid. Additionally, EffectiveTime(168) and ExpireTime(126) may provide specific timestamps for the start and end of order validity within the session or phase.
• On an order these fields sit inside the TradingSessions repeating group (NoTradingSessions(386)). TradingSessionID(336) is required in each entry and TradingSessionSubID(625) is optional, so a phase is always tied to its session and an order can list more than one session. On execution reports and trade capture reports, by contrast, FIX provides a single instance of TradingSessionID(336) and TradingSessionSubID(625), identifying the session and phase in which the reported event occurred. It is recommended to target the session or phase desired and let the venue resolve the times from its session list (35=BJ). It is recommended to add ExpireTime(126) only where a precise cutoff is needed.

Illustrative US examples, with phase values (e.g. sub-sessions) following the venue’s convention:

• Pre-market only: 386=1, 336=1, 625=1
• Post-market only: 386=1, 336=1, 625=5
• Day session, all phases: 386=1, 336=1, with 625 omitted
• Overnight (ATS): 386=1, 336=6, 625=3
• Venue with its own after-hours session: 336 taken from the venue’s published session list

FIX does not define time slots or market behaviour; it defines sessions and phases. A change of session or phase requires either a change of market behaviour (for example, matching starts or stops) or at least a change of the business date. The labels themselves are generic, and the venue’s published session list is the authoritative source for what each label means at that venue.

Choosing between the Day and Evening sessions. The usage of the TradingSessionID(336) field is determined by market or counterparties, and this field includes 7 potential values: Day, HalfDay, Morning, Afternoon, Evening, AfterHours and Holiday.

• In the context of US equities markets, it is recommended to classify the after-hours (post-market) trading session from 4-8pm as TradingSessionID(336)=1 (Day) with the TradingSessionSubID(625)=5 (Post-Trading). In the US 23/5 structure, any trades executed before 8pm ET would be counted as part of the same trading date and executions after 8pm ET would be classified as ‘next trading date’ for regular way trade reporting and clearing purposes. For example, a 6:30pm ET print is 336=1, 625=5 and sits on the same trade date as a 10am print. An 8:30pm ATS print is 336=6, 625=3 and is already counted as next trading date.

For orders using TimeInForce(59), we recommend using value 6=GTD with ExpireTime(126) for time-bounded orders, or A=Good for Time with ExposureDuration(1629) and ExposureDurationUnit(1916) for duration-based orders.

• FIX suggests avoiding TimeInForce(59)=0 (Day) on its own unless the venue has published an unambiguous definition of "business day" for the continuous session. Day combined with TradingSessionID(336) means good for that session, so pairing the two scopes the order. The venue should also state in which phases a Day order is eligible, because in the US a Day order can span 4:00 a.m. to 8:00 p.m. ET.

Figure 2: Overview of Selected Key FIX Trading Session fields

Source: FIximiate https://orchimate.org/fixtrading/fixlatest/codeSets/TradingSessionSubIDCodeSet

Worked example: A Nordic asset manager sends a limit order at 20:00 CET (19:00 UTC / 14:00 ET). The order targets a US venue operating an overnight session.

• EffectiveTime(168) = 20260609-19:00:00Z. ExpireTime(126) = 20260610-08:00:00Z.
• TradeDate(75) is populated according to the venue’s published business-date convention for the relevant trading session.
• The order is active from 14:00 ET through midnight ET into the next calendar day, until 4:00 AM ET (08:00 UTC).
• At expiry, the venue cancels remaining quantity and sends an unsolicited cancel (ExecType(150)=4 (Canceled), OrdStatus(39)=4 (Canceled)). No ambiguity about order validity arises because all validity timestamps are UTC, while TradeDate(75) separately identifies the applicable logical business date.

Figure 3: Overview of Selected Key FIX Fields For Overnight Trading

In overnight or continuous trading, the group expects greater use of orders with explicit validity windows rather than reliance on broad “day” or “night” labels. Existing FIX mechanisms are expected to be sufficient for order validity; no new FIX fields are currently expected to be required.

Differences in liquidity profiles throughout the day and night should be considered and may affect the appropriate order type and duration. Venues should therefore define clearly how order duration, session eligibility and expiry operate across regular, post-market and overnight sessions.

GTC orders should be handled according to the venue’s published rules for session eligibility, trade-date transition and corporate-action processing. Where a venue supports GTC or equivalent persistent orders across sessions, participants should understand whether the order remains live across overnight boundaries, whether it is paused during defined maintenance or market-control windows, and how it is treated when corporate actions, halts or other exceptions occur.

In practice, many exchanges specify that GTC orders continue to rest in the order book into the next trading day, and beyond the daily reset. In the example of futures trading on CME Globex, GTC orders are eliminated at the end of the trading week, i.e. Friday 4pm, unless weekend trading is specifically enabled.

Please see FIX Recommended Practices for 24x7 sessions 3 , in particular section 5.1. Sequence Number Format and section 5.2 Message Resend Limits

In a 24-hour trading environment in the context of broker workflows, Indications of Interest (IOIs) require explicit validity timestamps to avoid ambiguity. IOIs traditionally rely on implicit session-end conventions ("valid until the close"), which break down when the trading day spans midnight or crosses session boundaries.

Firms issuing IOIs should populate ValidUntilTime(62) with an explicit UTC timestamp reflecting the intended validity window. IOIs should not rely on an implicit "end of business day" interpretation, for the same reasons that ExpireDate(432) is not recommended for orders in continuous sessions without a published venue convention (see Q4).

Where an IOI is intended to cover a specific trading session (e.g., the overnight session only), the validity window expressed through ValidUntilTime(62) should align with the session boundaries published by the venue. IOIs that span multiple sessions should make this explicit.

IOITransType(28) values (New/Cancel/Replace) continue to function as expected. The key change is that the time dimension of IOI validity must be stated, not assumed.

3 https://fixtrading.org/packages/fix-recommended-practices-24x7/

4Trade Date, Time & Calendars

There is not yet a single agreed global trade-date transition point for 24-hour trading.

For US overnight ATS trading, members noted that market practice has generally landed around 8:00 p.m. ET, with the 8:00 p.m. to 9:00 p.m. ET period remaining an important active trading window for some ATSs. Other venues might choose 4pm, the end of the regular trading day as trade date transition period.

On the clearing side, DTCC has confirmed that for NSCC purposes the overnight session runs from 8:00 p.m. to 4:00 a.m. ET. NSCC does not treat the 8:00 p.m. to 9:00 p.m. exchange maintenance pause as a separate session: exchanges simply do not submit during that window, while ATSs continue to trade through it.

However, relevant authorities and conventions may differ by market, asset class, venue type, regulator, clearing model and post-trade infrastructure.

Systems should distinguish between the logical business date of the trade and the actual time at which execution occurred.

TradeDate(75) should identify the business date used for settlement and processing, while TransactTime and other timestamp fields identify the actual execution or message time.

Systems should not infer TradeDate from TransactTime, SendingTime or message arrival time, particularly where executions occur around midnight, over weekends, or across session boundaries.

In the US, after 8pm ET the clearing day and the calendar date stop being aligned. TradeDate(75) is the logical business date, meaning the session the trade belongs to. ClearingBusinessDate(715) is the session when the trade is booked and settled. In the current structure those two align. The convention needs stating because in extended hours they could diverge, and participants need to know which field drives settlement.

The group identified a gap here that is separate from the session and phase question above. ClearingBusinessDate(715) carries a date but not a time, and it does not convey its own relationship to the clearing organisation’s active business date. A downstream system reading a single message in isolation cannot determine whether the date it sees is the current or the next clearing business date without access to reference data or the clearing calendar.

The group’s view is that clearing date and time should be available to downstream consumers, and that this is a broader standardisation question rather than something to resolve through session identifiers. Members noted parallel discussions in other forums, including FIA, ISDA, ICMA and the CDM community. This is flagged as an area for further work.

5FIX Sessions, Sequencing & Connectivity

Yes, existing FIX session models can support continuous or near-continuous operation without daily sequence number resets, provided counterparties agree clear operating boundaries for sequence management, recovery, and replay.

The FIX Recommended Practices for 24x7 sessions 4 recognises that continuous operation does not require a single mandatory sequence number model. Instead, firms should adopt an approach that preserves deterministic recovery, supports monitoring and operational control, and is appropriate for the duration and volume profile of the session.

In practice, several sequence number patterns are commonly used:

• Date-prefixed or date-partitioned model – sequence management is logically segmented by business date or processing date, which can simplify operational support and exception handling, but requires clear agreement on date boundaries and rollover behaviour. Two variants are in use: the sequence restarts at 1 for each business or processing date, with a disconnect and reconnect at the boundary (DTCC UTC works this way today, with TradeReportID(571) restarting at 1 each processing date); or the business date is carried in the identifier itself, for example ClOrdID 20261008-000123, so uniqueness comes from the date prefix and the numeric sequence need not reset
• Monotonic continuous model – sequence numbers increase continuously across sessions without daily reset, which is simple in principle and aligns well with uninterrupted connectivity, but can make long-range resend and recovery handling more operationally sensitive.
• Time-windowed or bounded-retention model – venues or counterparties support replay only within a defined rolling window or retention limit, which improves operational control and system scalability, but requires firms to align on what recovery guarantees are and are not available.

The FIX Recommended Practices for 24x7 sessions also make clear that replay and resend policies should be defined alongside the numbering model. In continuous environments, the operational question is not only whether sequence numbers continue across days, but also how far back recovery is supported, how out-of-range resend requests are handled, and when a session should be re-established rather than recovered.

Accordingly, FIX supports truly continuous operation using existing protocol mechanisms, but firms should document and agree their chosen model in advance so that sequence behaviour, replay limits, and recovery expectations are unambiguous.

FIX sessions may remain open across multiple days or weekends if counterparties choose to operate that way, but doing so requires clear agreement on sequence number management, replay scope, operational monitoring, and the circumstances in which a session should be re-

4 https://fixtrading.org/packages/fix-recommended-practices-24x7/

established rather than recovered. The key objective is deterministic and auditable recovery, not simply preserving an uninterrupted connection.

In practice, firms may support replay only within a defined retention window or message range. That is a valid operating model, provided the limits are documented in advance and consistently enforced. Where a resend request falls outside the supported recovery scope, the preferred response should preserve clarity about session state and recovery guarantees. For that reason, the aforementioned recommended practices favour ending or re- establishing the session when recovery cannot be completed consistently.

Message resend limits and replay behaviour should be adapted for 24-hour trading by defining explicit retention boundaries, block-sizing, and operational thresholds in advance. Continuous sessions do not imply unlimited replay. Instead, counterparties should align on how far back messages will be retained for recovery, how resend requests will be chunked or capped, and what happens when a requested range is no longer available.

A Sequence Reset in Gap Fill mode is appropriate when messages are intentionally omitted from resend processing, for example because they are administrative or otherwise not meant to be replayed. It should not be used as a general substitute for unavailable messages outside the agreed replay range, as that can blur the distinction between an intentional gap fill and a failure to complete recovery. Where the requested messages cannot be recovered within the agreed policy, the safer standard response is to terminate or re-establish the session so that both sides have an unambiguous view of session state.

Below is guidance from the DTCC 5 on key FIX fields for Universal Trade Capture (UTC) 24x5 trade procession FAQ site:

• TradeReportID(571)

Sending Entities through FIX or MQ must successfully complete the current processing day and balance with UTC before beginning to submit Next Trade Date trades. The TradeReportID(571) must sequentially start at 1 for the next trade date. Additionally, a Sending Entity that is a FIX user must disconnect and then reconnect the FIX engine before submitting trades for the next processing day. This is required so that the Sending Entity can recycle their FIX session following completion of their current processing day.

• ClearingBusinessDate(715)

Starting in June 2026, the FIX field ClearingBusinessDate(715) will be included in the UTC real-time output (UTCO) message across all clients. This change supports the expanded capabilities. All clients must add the ClearingBusinessDate(715) to their processing logic. Clients participating in 24x5 trading must use this tag to ensure trade IDs are unique, avoiding issues with potential duplicates. These clients must also accept two business clearing dates and balance only the current business date. All clients that receive real-time output are required to test and confirm that their systems can properly process this FIX tag. See the UTC Common Trade Fix Output Format containing ClearingBusinessDate(715) in the UTC Release section of the Learning Center. • TradingSessionID(336)

FIX field TradingSessionID(336) will be required for all Sending Entities that participate in overnight trading session. See the UTC Common Trade Fix Input Format containing the new FIX Tag 336 in the UTC Release section of the Learning Center. Non-24x5 Sending Entities that elect to include TradingSessionID(336) , where its use is optional, must

5 https://www.dtcc.com/initiatives/Content/1-utc_faqs/1_utc-faq.htmQ

populate the tag with a valid value as defined in the UTC Common Trade FIX Input Format . Submitting an incorrect value results in trade rejection.

Furthermore, the following points were confirmed by DTCC on 3 September 2026 and affect how TradingSessionID(336) is populated in practice.

• Custom values. DTCC has defined its own values for TradingSessionID(336) covering four brackets: pre-market, regular, post-market and overnight. These extend beyond the enumerations shown in the session table earlier in this document. Overnight processing controls at NSCC are triggered from this tag, so it is load-bearing rather than informational.
• TradingSessionSubID(625) is not consumed. NSCC processing reads TradingSessionID(336) only. A submitter populating TradingSessionSubID(625) gains nothing on the clearing leg, although firms may still prefer a single population convention across trading and clearing rather than maintaining two.
• No agreed mapping yet. As at September 2026 there is no one-to-one mapping between the DTCC values and the FIX enumerations. Establishing that mapping is joint work between DTCC and this working group. Appendix A sets out the comparison as it currently stands. Terminology used here: TradingSessionID(336) identifies a session, and TradingSessionSubID(625) identifies a phase within that session; a phase always identifies the session it belongs to. On this basis the US business day is a single Day session (pre- market, open, continuous, close, post-market), followed by the Overnight session, which begins at the change of business day.
• The submitter determines the session. The session is supplied by the submitting firm rather than derived by NSCC. NSCC sits after the execution chain and the execution timestamps it receives are not consistently reliable for this purpose, so the determination rests with the party best placed to know in which session the trade occurred.
• Settlement differs by session. A trade in the post-market session carries the same trade date and clearing date. A trade in the overnight session posts to the next clearing date once the sending entity has completed its end-of-day processing (see Appendix B). For example, a trade submitted at 9:05 p.m. ET on Thursday 3 September 2026, after the sending entity’s end-of-day close, carries TradeDate(75) and ClearingBusinessDate(715) of 4 September 2026 and settles on T+1. As Monday 7 September 2026 is the Labor Day holiday, settlement occurs on Tuesday 8 September 2026.
• Keep in mind that the inbound TradeReportID(571) must sequentially start at 1 for a process date. Trades received after the Sending Entity processes the Good Night message for Next Trade Date must start with Sequence 1 . There are plans to add additional fields to the UTC input message format in a later phase of UTC modernization

Upgrading FIX gateways without downtime in a continuous market is an operational problem with multiple valid technical solutions depending on firm topology and deployment model.

Firms should document their approach as part of the session operating agreement with counterparties, including notification procedures and recovery expectations.

6Corporate Actions & Market Controls

In a continuous or near-continuous trading model, corporate actions create operational risk because overnight trading may occur before custodians, clearing firms, OMSs or back-office systems have reflected the event. The risk is that market participants may have inconsistent views of positions, share quantities or reference data, particularly during events such as splits or reverse splits.

A practical approach used by some overnight venues is to halt order entry and trading for securities subject to disruptive corporate actions. Halt information may be communicated through reference data files with reason codes and, in some cases, by email or other operational notification channels rather than through the market data feed. Members also observed that markets with corporate actions are not generally operating on a 24/7 basis, while markets with 24/7 trading tend to list instruments (such as derivatives or token) where the impact is less direct. It was noted that in tokenised markets, a custodian or CSD- equivalent may coordinate a lock with order books, pausing trading while a token rebase occurs and then communicates when trading can resume.

For example, Nasdaq proposes to halt trading in affected securities from 8:00pm to 9:00pm ET on the day immediately preceding the market effective date of the corporate action. The security would be halted through the overnight trading session and resume trading through the Nasdaq Halt Cross at 8:00am ET on the effective date of the corporate action. Further details can be found here:

https://www.nasdaq.com/docs/global-trading-hours-corporate-actions-faqshours- corporate-actions-faqs

FIX Extension Pack 299 6 supports communication of a corporate-action reference price where a reference price, such as a settlement or closing price, changes due to a corporate action event.

Exception handling should be explicit where a corporate action is expected but has not yet been processed by a custodian, OMS, clearing firm or related system. Venues and participants should define how orders are halted, rejected, cancelled, resumed or otherwise controlled, and how participants will be notified that trading can resume.

A universal non-trading window may be useful for maintenance, reference data updates and critical corporate actions, but the group did not agree that a single global window is feasible or desirable across all markets. Market structures, asset classes, regulatory obligations and post-trade dependencies differ.

The more practical near-term approach is for venues to publish clear halt, pause, reference data and exception-handling practices, with harmonisation where possible.

6 https://fixtrading.org/packages/ep299/

7Appendix A – DTCC / NSCC and FIX session values compared

This appendix compares how the DTCC / NSCC Universal Trade Capture format and the FIX session model described in this document each express the same US trading day. It is included as a practical reference for firms submitting to both, and reflects DTCC’s description of its own model as at 3 September 2026.

It illustrates one market implementation and does not constitute a recommended approach. As at the date of publication there is no agreed one-to-one mapping between the two sets of values. The composite resolutions in the final column are a proposed convention pending joint work between DTCC and this working group.

Notes:

1. The NSCC overnight session begins at 8:00 p.m. ET and does not recognise the exchange

maintenance pause, because ATSs trade through that window.

2. NSCC reads TradingSessionID(336) only, so the phase column has no effect on clearing

and is shown to illustrate what the FIX model is able to express.

3. The 4:00 p.m. to 8:00 p.m. window maps through the Day session rather than the Evening

session, because the US trade-date boundary falls at 8:00 p.m. and the post-market session carries the same trade date and clearing date.

8Appendix B – DTCC, the trade lifecycle and why TradingSessionID(336) carries clearing weight

8.1 Introduction

This appendix sets out, from first principles, what DTCC is, where the FIX trading leg ends and the clearing leg begins, and why the session field and the sending entity’s processing-day roll together determine the clearing date, the netting bucket, the point at which the trade guarantee attaches and the date on which settlement occurs. It is written for readers with less familiarity with the clearing leg of a transaction: FIX connectivity engineers, middle office, clearing operations and product teams.

It describes one market implementation, the US 23/5 structure, and does not constitute a recommended approach. Appendix A carries the session-value comparison; this appendix explains the mechanism behind it.

8.2 The same day in three vocabularies

Three systems describe the same 24 hours. DTCC uses four flat strings. The FIX session model uses a two-dimensional scheme: a session identifier, TradingSessionID(336), plus a phase within it, TradingSessionSubID(625). Laying them on one timeline makes the mismatch visible.

Figure B1: The same trading day expressed in three vocabularies

8.3 What DTCC is and why it matters

The Depository Trust & Clearing Corporation is the post-trade infrastructure for US cash equities. Three parts of it matter here.

• NSCC, the National Securities Clearing Corporation, is the central counterparty. It novates locked-in trades, nets them through Continuous Net Settlement (CNS), guarantees completion and calls Clearing Fund margin.
• DTC, The Depository Trust Company, is the securities depository. It holds securities in book-entry form and settles them against money, delivery versus payment (DVP), so neither side bears principal risk.
• Universal Trade Capture (UTC) is NSCC's real-time trade intake pipeline. Exchanges, ATSs and qualified special representatives submit locked-in trades to UTC, and UTC returns real-time output (UTCO) confirming acceptance or rejection.

Note the acronym collision: throughout this appendix UTC in the DTCC sense always means Universal Trade Capture. Where Coordinated Universal Time is meant, it is written out.

Why DTCC speaks FIX. DTCC adopted FIX message syntax as an input and output format for UTC. The rationale is adoption cost: every submitting firm already runs FIX infrastructure for the trading leg, so reusing the wire format lowers the barrier to connecting. The consequence, which this appendix exists to explain, is that DTCC populates standard FIX tag numbers with its own value sets and its own processing semantics, defined in DTCC's UTC record layouts rather than in the FIX specification. The messages look like FIX. The dictionary is DTCC's.

8.4 The trade lifecycle: where FIX lives, where DTCC takes over

On the trading leg, FIX is the common language: orders (MsgType(35)=D), executions (MsgType(35)=8) and session status (MsgType(35)=h). Once a trade is matched and locked in, the record crosses into DTCC's domain through UTC. From that point the governing documents are NSCC's rules and record layouts, not the FIX specification.

Figure B2: Lifecycle from order to DVP settlement

The structural point is a change of role, not of format. On the trading leg, session tags are descriptive metadata about an execution. The moment the record crosses into UTC, TradingSessionID(336) becomes a processing instruction. NSCC sits last in the chain and cannot reliably reconstruct the session from execution timestamps it did not generate, so it delegates the determination to the submitter, makes the field mandatory for overnight participants, and rejects invalid values rather than defaulting silently.

8.5 One tag, two jobs

The same pair of fields is consumed differently on each side of the boundary. This asymmetry is the root of the mapping problem.

Figure B3: The trading leg reads session and phase together; the clearing leg reads TradingSessionID(336) alone

Read the two columns against each other. The trading side is a two-dimensional model: session identity plus phase within it, enumerated in the FIX standard, with timing published by each venue. The clearing side is one-dimensional: four flat strings, with the phase discarded. Translation from FIX to DTCC loses information harmlessly. Translation in the reverse direction is not possible without reference data, because a post-market string alone cannot tell you whether the venue was in continuous trading or in an auction. Any bridge should therefore be defined in the lossy direction only.

8.6 Why the session label carries weight

The purpose of tag 336 is identification of overnight trades to apply overnight session controls. The clearing date itself moves with the sending entity’s own processing cycle: completion of end-of-day processing is what moves the entity to the next processing date, so trades submitted before that close post to the current clearing date and trades submitted after it post to the next. The clearing date then determines everything that follows. Consider one overnight print at 9:05 p.m. ET on a Thursday, submitted before and after the sending entity has completed its end-of-day processing.

Figure B4: The fork, one overnight print at 9:05 p.m. on Thursday. Blue, left: the sending entity has not yet completed end-of-day processing, so the trade posts to the current clearing date. Red, right: after end-of-day processing is complete, the trade posts to the next clearing date

Same print, same tag. The sending entity’s close of processing, not the clock, moves the clearing date. Three consequences hang off that date.

• Netting. CNS builds one net position per member per security per clearing date, so the date decides which net the trade lands in and what the member delivers or receives.
• Guarantee. The NSCC trade guarantee attaches by processing cycle, so the date determines when central counterparty protection begins.
• Margin. Clearing Fund requirements are computed from open positions per date.

Two failure modes follow. A wrong TradingSessionID(336) means wrong or missing overnight session controls and rejection risk. Mis-sequenced end-of-day processing posts trades to the wrong clearing date, moving the obligation and the risk, and nothing downstream repairs it. By the time a misclassified trade sits in the wrong CNS net, the correction path is a cancel and resubmit against a clearing day that may already be balanced.

8.7 The mapping direction and the bridge

As at the date of publication there is no agreed one-to-one mapping between the DTCC values and the FIX enumerations. Appendix A sets out the comparison; the composite column there is a proposed convention and not a ratified standard. Three bridge options are available to the group, and they are not mutually exclusive.

Figure B5: The dialect boundary and the three bridge functions every submitter implements

Figure B6: Bridge options

A sensible sequencing would be option 1 immediately, option 3 as the standards deliverable and option 2 as a DTCC migration path. Adding the literal DTCC strings to the FIX TradingSessionID(336) enumeration is not recommended, because it would embed one market's conflation of session and phase into the global standard.

Resolution. Appendix A maps the 8:00 p.m. to 9:00 p.m. window as TradingSessionSubID(625)=7 (Quiescent). Quiescent accurately describes the exchanges, which are paused, but it does not describe the ATSs, which match continuously through that hour and are the entities actually submitting those trades. On that reading the composite for the window would be 6 + 3 rather than 6 + 7. Either way the DTCC value is the overnight string, so clearing is unaffected, but the two readings disagree about what a submitter should populate on the trading leg. The group’s resolution is that the window carries three separate statements rather than one composite: ATS prints are 6 + 3; the exchange quiescent state travels as a status on TradingSessionStatus(35=h) and is never stamped on a trade; and order acceptance by a paused exchange is venue-defined, for example 6 + 3 queued for the overnight open, 6 + 7 targeting the quiescent phase itself, or 1 plus a phase to activate the next day. This is also the clearest illustration of why a composite key is fragile: the 4:00 p.m. to 8:00 p.m. window is mapped to 625=5 (Post-trading) as a labelling convention, yet matching there is continuous, so a venue legitimately reporting 1 + 3 in that window makes the composite ambiguous. It is the strongest argument for anchoring any translation in a published time-and-venue rule rather than in 625 values.

8.8 From the tag to DVP settlement

The tag itself never touches settlement. Its effect does, through a chain of derivations that runs in one direction only: the submitter’s TradingSessionID(336) and the sending entity’s end-of-day processing cycle together set the ClearingBusinessDate(715) at NSCC, which determines the CNS net the trade joins, which determines the date on which DVP settlement occurs at DTC. For regular-way trades the trade date and clearing business date are aligned, since the entity closes its day shortly after 8:00 p.m. ET; as-of trades submitted after the date has rolled are the exception.

Figure B7: The derivation chain. It runs one way, and nothing downstream repairs a wrong session value

DVP, delivery versus payment, is DTC's settlement mechanism. It makes the securities movement and the money movement conditional on each other, which eliminates principal risk. CNS nets each member's obligations into a single receive or deliver per security per settlement date, with NSCC as counterparty. Securities move by book entry at DTC and money settles net at end of day through the DTCC cash settlement process. Institutional allocations confirmed through affirmation platforms settle DVP at DTC against the same date discipline. Every one of those steps keys off the clearing date that the session value selected at submission time.

8.9 Worked example

Figure B8: An overnight execution traced from match to settlement

8.10 Summary points

• The 8:00 p.m. ET business-date roll, not midnight, is the organising fact of the US 24- hour structure.
• DTCC borrowed FIX syntax for UTC but owns its own dictionary. The tag numbers match; the semantics do not.
• On the trading leg, TradingSessionID(336) and TradingSessionSubID(625) describe where in the day an execution happened. At NSCC, TradingSessionID(336) identifies overnight trades for session controls; the clearing date rolls when each sending entity completes its end-of-day processing, and that date drives the CNS net, the guarantee, margin and the DVP settlement date.
• The submitter owns session determination. Build the translation at the edge, validate before the wire, and reconcile on ClearingBusinessDate(715) together with TradeReportID(571).
• The mapping is lossy from FIX to DTCC and undefined in reverse. A durable fix needs either a published time-and-venue convention or a native clearing-bucket concept in the FIX standard.

9Appendix C – Tag glossary for 24-hour trading

This glossary is role-oriented and complements the field table in the Orders, Order Types & Trade Lifecycle section, which covers order-validity fields in specification detail. The entries below state what each field decides in a 24-hour context and, where the two legs differ, how each one reads it.

Figure C1: Fields that carry 24-hour meaning