24-Hour Markets: FIX, DTCC and TradingSessionID(336)

01The new US trading day

The SEC has approved exchange proposals (Nasdaq, NYSE Arca, 24X) extending equity trading to roughly 23 hours a day, five days a week, from Sunday 9pm ET to Friday 8pm ET. Several ATSs already operate through the night. The SIPs, NSCC and DTC have announced extended operating hours to match, with a one-hour technical pause from 8–9pm ET, Monday through Thursday, on the exchanges.

02One trading day, 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.

Two things to notice. First, DTCC’s day has four segments where FIX 336 has two: the resolution DTCC needs lives in tag 625 on the FIX side. Second, the segment boundaries do not line up with any single FIX field. PRE, REG and PST are all phases of one FIX Day session, while OVN spans a window in which FIX would distinguish a quiescent exchange phase from continuous ATS trading. There is no one-to-one mapping on 336 alone; a faithful translation needs 336 and 625 together, or a time-and-venue rule.

03What DTCC is and why it matters

The Depository Trust & Clearing Corporation is the post-trade utility for the US capital markets, the holding company for two SEC-regulated subsidiaries that between them stand behind essentially every US equity trade.

• NSCC (National Securities Clearing Corporation) is the central counterparty. Through novation it becomes the buyer to every seller and the seller to every buyer, guarantees trade completion, and nets the day’s activity through Continuous Net Settlement (CNS) into one net position per member, per security, per settlement date. Netting routinely compresses gross obligations by well over 90 percent.
• DTC (The Depository Trust Company) is the central securities depository. It holds eligible 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: in this guide UTC in the DTCC sense always means Universal Trade Capture, not Coordinated Universal Time.

Why DTCC speaks FIX. DTCC adopted FIX message syntax as an input and output format for UTC. The business rationale is adoption cost: every submitting firm already runs FIX infrastructure for the trading leg, so reusing the wire format lowers the integration barrier. The consequence, and the source of the problem this guide 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.

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

On the trading leg, FIX is the lingua franca: orders (35=D), executions (35=8), session status (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.

The structural point: on the trading leg, session tags are descriptive metadata about an execution. The moment the record crosses into UTC, tag 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.

05Tag primer: 336 and 625 as FIX defines them

In the FIX specification, sessions and phases are a two-level model. TradingSessionID(336) names the session; TradingSessionSubID(625) names the phase within it. Venues publish start and end times via TradingSessionList(35=BJ) and signal transitions with TradingSessionStatus(35=h).

In the US 23×5 structure the 4–8pm window is a phase of the Day session (336=1, 625=5), not an Evening session, because the US trade-date boundary falls at 8pm and the post-market window carries the same trade date and clearing date as the day. The overnight window is the Night session (336=6). 625 is optional in the standard. This guide recommends populating it anyway: a consumer cannot distinguish an unpopulated 625 from a venue that does not support it.

06DTCC’s 336: same tag number, different dictionary

DTCC defines its own TradingSessionID(336) values in the UTC Common Trade FIX Input Format, covering four brackets: pre-market, regular, post-market and overnight (rendered here as PRE, REG, PST, OVN). These are authored in DTCC documentation, outside FIX governance, and extend beyond the FIX enumeration. Key operating facts, per DTCC’s published Universal Trade Capture 24×5 documentation:

• 336 is required for all sending entities participating in the overnight session. Firms that do not participate in 24×5 may populate it optionally, but an incorrect value causes trade rejection.
• NSCC consumes 336 only. TradingSessionSubID(625) is not read on the clearing leg.
• The submitter determines the session. NSCC does not derive it from timestamps.
• Overnight processing controls at NSCC trigger from this tag. It is load-bearing, not informational.
• From June 2026, ClearingBusinessDate(715) is included in UTC real-time output for all clients; 24×5 participants must use it to keep trade IDs unique and must balance two concurrent business dates.
• TradeReportID(571) must restart at 1 for each new processing date, and FIX submitters must disconnect and reconnect their FIX engine between processing days, a legacy constraint that sits awkwardly beside the FIX community’s 24×7 no-daily-reset session practices.

Why does a session label carry this much weight? Because at NSCC the session determines the clearing date, and the clearing date determines everything else.

Three consequences hang off that fork. 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: NSCC’s trade guarantee attaches by processing cycle, so the date determines when CCP protection begins. Margin: Clearing Fund requirements are computed from open positions per date. A misreported session is not a reporting blemish; it moves real money and real risk. Nothing downstream can repair a wrong 336: 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.

07One tag, two jobs

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

Read the two columns against each other. The trading side is a two-dimensional model: session identity and phase within it, enumerated in the FIX standard, with timing defined by each venue. The clearing side is one-dimensional: four flat strings, phase discarded. Forward translation from FIX to DTCC loses information harmlessly. Reverse translation is impossible without reference data, because PST alone cannot tell you whether the venue was in continuous trading or an auction. Any bridge must therefore be defined in the lossy direction only.

08The mapping and the bridge

As of publication there is no agreed one-to-one mapping between DTCC’s values and the FIX enumerations; establishing one is joint work between DTCC and the FIX 24-Hour Markets Working Group. The comparison below reflects DTCC’s published description of its model. The composite column is a proposed convention, not a ratified standard.

The NSCC overnight session begins at 8:00pm ET and does not recognize the exchange maintenance pause, because ATSs trade through it. Note a composite-key subtlety: mapping the 4–8pm window to 625=5 (Post-trading) is a labeling convention; matching there is continuous, so if a venue legitimately reports 1 + 3 in that window the composite becomes ambiguous. This is the strongest argument for anchoring the translation in a published time-and-venue rule rather than in 625 values.

A sensible sequencing: option 1 immediately, option 3 as the standards deliverable, option 2 as DTCC’s migration path. Adding the literal PRE/REG/PST/OVN strings to the FIX 336 enumeration is not recommended: it would bake one market’s session-and-phase conflation into the global standard.

09From tag to DVP: how 336 reaches settlement

The tag itself never touches settlement. Its effect does, through a chain of derivations. DVP, delivery versus payment, is DTC’s settlement mechanism making the securities movement and the money movement conditional on each other, eliminating principal risk. The settlement date on which that simultaneous exchange happens is T+1 of the clearing date, and the clearing date is whatever 336 said it was.

For completeness on the settlement mechanics: 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; money settles net at end of day across 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 tag selected at submission time.

10Worked example

11Tag glossary for 24-hour trading

12Takeaways

• The 8pm ET business-date roll, not midnight, is the organizing fact of US 24-hour market structure.
• DTCC borrowed FIX syntax for UTC but owns its own dictionary. Tag numbers match; semantics do not.
• On the trading leg 336/625 describe where in the day an execution happened. At NSCC, 336 decides which clearing date a trade belongs to, 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 715 + 571.
• The mapping between the two vocabularies is lossy FIX→DTCC and undefined DTCC→FIX. A durable fix needs either a published time-and-venue convention or a native clearing-bucket concept in the FIX standard.