SAPINOVER OS v2.0 :: INITIALIZING...
000%
Sixteen exchanges. Seven hundred and thirty-two liquidity codes. Four architectures for the liquidity flag and a fifth for the peg price itself. What the fee-code taxonomy reveals about market structure, and what the overnight session will look like when it starts.
In September 2024 the SEC adopted amendments to Regulation NMS. Rule 612 established a $0.005 minimum pricing increment for tick-constrained NMS stocks. Rule 610(c) reduced the access-fee cap from $0.0030 per share to $0.0010. Rule 610(d) added a requirement that exchange fees be determinable at the time of execution. The D.C. Circuit upheld the package on October 14, 2025.
The compliance dates then split, twice. On October 31, 2025 the SEC granted temporary exemptive relief (Release 34-104172) extending Rule 610(c) cap compliance and Rule 612 tick sizes to the first business day of November 2026, and Rule 610(d) only to February 2026. Then on June 11, 2026 the Commission extended 610(c) and 612 a second time, to the first business day of November 2027 (Release 34-105656), and on the same day proposed rescinding Rule 611 and Rule 610(e) outright. The fee-determinability requirement of Rule 610(d) is the one piece of the 2024 package that went operative, on the first business day of February 2026, and it is the piece that matters for the taxonomy in this piece: if a member has to know the fee at fill, the liquidity indicator returned on the execution report has to carry enough information for that. And so the code becomes the fee key.
Every US exchange responded, and two different execution decisions had to be re-encoded. The first was the liquidity flag returned on the execution report. That drives fee pricing at the fill and split into four incompatible architectures across the 732 native codes that 16 venues publish today. The second was the pegged-order price itself: how does a member specify where on the NBBO spread they want their peg to sit? TXSE's FIX Order Entry spec answered that question a fifth way, incompatible with everyone else. So the taxonomy is four plus one, or five if you take "architecture for encoding execution economics" broadly.
The most common answer is to write one code per fee-relevant case. NYSE publishes 141. Arca and American 101 each. National 90. Texas 76. MIAX Pearl 95. Every one is browsable and filterable in the explorer.
Roughly 40% of NYSE's indicators exist only as sub-dollar variants. "A" is Add Regular Limit Order. "AZ" is Add Sub Dollar Execution. "ASP" is Add Limit Order Setting New NBBO with Priority. "ASPZ" is the same, sub-dollar. 58 of NYSE's 141 codes and 178 of the NYSE family's 509 codes are the trailing-Z form. Sub-dollar fills price on a percentage of transaction value rather than per share, so the code has to route them to a different rate line.
MIAX Pearl publishes the industry's only standalone Liquidity Indicator Codes document (v3.0, March 2025). It uses a systematic two-character scheme: the first character encodes role and session (A adds, R removes, E early-session adds, F late-session adds, e and f are removes in those sessions, X routed, O opening); the second encodes tape (A, B, C), display state via case (uppercase displayed, lowercase non-displayed), retail flag, and midpoint peg.
Cboe's four equities venues (BZX, BYX, EDGA, EDGX) share one protocol spec. The liquidity indicator is split across two fields. BaseLiquidityIndicator carries the role (A added, R removed, C auction, W waiting, X routed). SubLiquidityIndicator carries a qualifier (H hidden, I hidden price-improved, J first to join the NBBO, P periodic auction, V visible price improved, m midpoint peg, E RPI liquidity on BYX and EDGX only, S NBBO-setter fee eligible, s set the NBBO but not fee eligible).
The S/s pair is the clearest evidence of the fee-key thesis anywhere in the corpus. Two codes that differ only in case, and the only difference between what they describe is fee treatment. Cboe encoded fee eligibility into the character register.
IEX uses tag 9730 TradeLiquidityIndicator: nine base tokens plus seven appended characters. The base names the role. The suffix qualifies it. MI is Add Non-Displayed Continuous Execution. TL is Remove Displayed Continuous Execution. Base tokens for auctions are X, O, C, H, P. Appended characters include D (executes displayed continuous book interest in a cross), R (retail order removes), A (member adds against a retail order), W (resting order removes against a Post Only), Y (Post Only executes on entry), B (Tape B security), K (peg order removes displayed liquidity).
Composition rather than pre-enumeration. And IEX says outright, in its FIX specification, that tag 9730 is "to be used in conjunction with LastMkt(30) to determine trading costs." Tag 9882 FeeCode carries the away-market fee code on routed fills. The venue documents the same hypothesis this article proposes.
MEMX and LTSE share the MEMO protocol family (LTSE runs on MEMX technology; its service desk lives at help.jsm.memx.com). Their FIX tag 851 LastLiquidityIndType has only four values: 1 Add, 2 Removed, 3 Routed, 4 Auction. Fee-relevant properties live in a separate 2-byte bitset, ExecutionDetailsType (custom tag 21038), with twelve independent bits: OnEntry, NBBOJoiner, NBBOSetter, HiddenQuantity, DisplayedQuantity, MidpointOrder, ImmediateOrder, RetailOrder, TradedAtMidpoint, PriceImprovement, TradedAgainstRetail, TradedAgainstHidden.
An add-side fill can, in one message, set OnEntry + NBBOSetter + DisplayedQuantity + PriceImprovement. Four bits. A downstream cost model reads each independently and prices the fill.
The first four architectures all encode the same execution decision: what happened on the fill. Add or remove? Displayed or hidden? Retail or not? NBBO-setter or not? Sub-dollar or not? Every venue answers those questions on the execution report. Four grammars for the same set of questions.
TXSE changed a different execution decision. Its FIX Order Entry & Drop Copy Specification, based on FIX 5.0 SP2 with custom tags in the 8000-9999 range, encodes pegged-order pricing on a continuous scale. Every other US NMS-equity venue enumerates three separate pegged order types: Primary Peg, Midpoint Peg, Market Peg. Three discrete options, coded as three distinct OrdType values or three distinct ExecInst values. TXSE collapses all three into one message field, referencePriceTarget, and lets a member specify any integer from 0 to 10,000 as basis points from the near touch:
A trader can dial the peg in at any point on the spread. The spec even documents priority behavior under narrow spreads: if a 70% target and a 90% target both round to the same price under a 3-cent spread, arrival time decides. Under a 10-cent spread the 90% order at $10.09 outranks the 70% order at $10.07 on standard price-time. Under sub-$1 stocks the same math applies but valid peg prices are floored to $0.0001 MPV.
The obvious objection is discretionary pegs. Cboe's Discretionary Peg and NYSE Arca's former Discretionary Peg Order (replaced by the Selective Midpoint order in March 2026) already let a peg execute anywhere inside a discretion range. The difference is who chooses the point. A discretionary peg rests at the near touch and lets the venue take the order deeper into the spread when a contra arrives; the venue decides how far, within the range. TXSE's field lets the member set the resting point explicitly, and it is a resting instruction, not a discretion band. It is closer to a limit order whose price floats with the spread than to any existing peg.
The economic implication is subtle. The other four venue families all treat peg execution economics through the liquidity code: an execution at midpoint is a distinct code from an execution at the touch, and the code drives the fee. TXSE moves the decision earlier, into the order-entry message, and prices along a continuum. It is the most different architecture in the corpus, and it is the newest venue on the list. Whether the industry follows TXSE, or whether other operators respond by shipping their own parametric variant, is the venue-strategy question worth watching next.
The most tempting analysis of this dataset is to rank exchanges by code count. Do not do that. NYSE at 141 and MEMX at 4 encode comparable economic detail through different mechanisms. NYSE spells out every combination that maps to a distinct fee line. MEMX crosses 4 values with 12 bits and lets the receiver compose. Both are complete answers to Rule 610(d). Neither is more expressive than the other.
The comparison that DOES survive is architecture-level. Two-field, composed, and bitset architectures make it easier for a venue to add a new fee dimension without expanding a codebook: the field or bit already exists and the fee schedule references it. Enumerated architectures tend to require codebook expansion when a venue creates a new fee-relevant execution state that cannot be distinguished by existing values.
That is a claim about codebooks, not about filings, and the two should not be conflated. Exchanges frequently change rates and tier qualification criteria while retaining the same execution and fee codes. Cboe BZX's SR-CboeBZX-2026-022 revised the qualification criteria for LMP Tiers 1 and 2 in April 2026 without touching the execution-code architecture at all: the codes stayed put and the arithmetic behind them moved. Whether a particular code change requires a rule filing depends on the rules and fee-schedule provisions implicated. A venue's architecture choice shapes how often it must expand its codebook, not whether it must file.
TXSE's parametric peg goes further still: a single 10,001-value field replaces three discrete order types, so adding a new peg placement is not even a spec change. It is a different number in an existing field.
One code per fee-relevant case. Sub-dollar treatment lives in a trailing 'Z' variant. Retail, midpoint, NBBO-setter, tape, and displayed vs non-displayed each get their own row.
Example. NYSE 'AZ' = Add Sub Dollar Execution. 'ASPZ' = Add Limit Order Setting New NBBO with Priority, Sub Dollar.
BaseLiquidityIndicator gives the role (added, removed, auction, routed, waiting). SubLiquidityIndicator gives the qualifier (hidden, price-improved, NBBO-setter, RPI, midpoint).
Example. 'S' = NBBO-Setter fee eligible. 's' = set the NBBO but is not fee eligible. Two codes that differ only in fee treatment.
One field carries a base token that names the role plus an optional suffix character that qualifies it. Composition rather than pre-enumeration.
Example. 'ML' (Add Displayed Continuous Execution) + 'R' (Retail order removes) yields a distinct fee context without a distinct code.
Four coarse values (Add, Removed, Routed, Auction) plus a 2-byte bitset with twelve independent bits. Fee-relevant properties are orthogonal.
Example. OnEntry + NBBOSetter + DisplayedQuantity + PriceImprovement. Four bits set, and a downstream cost model reads each independently.
TXSE encodes peg pricing on a continuous 0 to 10000 basis-point scale rather than three discrete order types. The member picks any point on the spread.
Example. referencePriceTarget = 0 is Primary Peg, 5000 is Midpoint, 10000 is Market Peg, 7000 is 70% of the way from NBB to NBO. Distinct from discretionary pegs: the member sets the resting point, not the venue.
Explore the dataset
The architectures above are the map. The Execution Codes Explorer is the territory: all 732 native liquidity codes across 16 exchanges, each faceted by role, session, display, retail, price position and Rule 610 sub-dollar treatment, each carrying a citation to the protocol spec that defines it. Filter to a single venue for its full dossier: protocol, order-type rule citations and routing strategies. Toggle exact-code search to separate A from a and XA from XAO.
Institutional tier. 732 codes, 19 venues sourced, live against the pipeline.
IEX documents it. Cboe encodes it in case. NYSE splits nearly every indicator into a regular and a Sub Dollar variant because sub-$1.00 fills price on a percentage basis and take a different rate line. The practical implication for anyone modeling routing decisions or venue analytics is that the volume tier selects which rate card applies, and the liquidity code selects the line on that card. A cost model keyed only on month-end ADV bands will misprice at the fill level, because 610(d) requires the fill to already carry the answer.
The corollary is that fee changes and code changes have become the same event. A new fee structure requires a new code path. That is the framing under which the next section reads.
The explorer's venue dossier makes this concrete: filter to a venue and it lays out that venue's protocol citation, its order-type rule citations, and its routing strategies side by side, so the code, the rule that authorizes it, and the fee schedule it feeds are visible in one view.
The 732 codes contain 56 with explicit extended-session semantics. The distribution is not close.
| Venue | Extended-hours codes | What they cover |
|---|---|---|
| MIAX Pearl | 46 | E/F prefixes are Early/Late Session, crossed with tape, displayed vs non-displayed, retail, and midpoint peg. |
| Nasdaq | 5 | '2' added pre-market. '3' removed pre-market. '5' displayed NBBO-improving pre-market. '9' non-displayed adding pre-market. 'i' after-hours closing cross. |
| Cboe (per venue) | 1 | BaseLiquidityIndicator 'W' = waiting for execution at pre-market time per the Hold Early to 7am port setting. |
| NYSE family | 0 | No liquidity indicator specifically encodes an extended-session state. |
MIAX Pearl instrumented extended sessions at the protocol level with 46 codes, added as v2.8 of its Liquidity Indicator Codes document in June 2024 and de-flagged from "Future Implementation" in v2.9. Nasdaq covers pre-market with four codes plus one for the after-hours closing cross. Cboe carries a single indicator, W, tied to a port setting called Hold Early to 7am. NYSE's Pillar spec has none.
One thing all 56 codes have in common: they describe 4:00 a.m. to 9:30 a.m. or 4:00 p.m. to 8:00 p.m. Not one liquidity indicator describes 8:00 p.m. to 4:00 a.m. That word matters. The session field is a different message element from the liquidity indicator, and as the next section shows, one venue family has already coded the overnight session in that field. What has not yet happened anywhere is a liquidity code that describes how an 8 p.m. to 4 a.m. fill gets priced.
As of August 2026, no national securities exchange OPERATES between 8:00 p.m. and 4:00 a.m. Eastern. Four NMS Stock ATSs do: BlueOcean (BOATS), Bruce Markets, Moon ATS, and IBKR ATS, which matches from 8:00 p.m. to 3:50 a.m. But the filings to change that have already been happening for eight months, and several have already been approved.
| Date | Venue | SR / Release | Filing |
|---|---|---|---|
| 2026-01-13 | Nasdaq | SR-NASDAQ-2025-109 / 34-102400 | Filed to extend to 23 hours a day, 5 days a week |
| 2026-04-15 | Nasdaq | SR-NASDAQ-2025-109 / 34-105199 | SEC APPROVED with Amendments 2 and 3 |
| 2026-04-15 | Cboe EDGX | SR-CboeEDGX-2026-019 | Filed to enable 23 hours per day, 5 days per week |
| 2026-05-19 | 24X National | SR-24X-2026-17 / 34-105497 | Immediately effective rule change |
| 2026-05-27 | NYSE Arca | SR-NYSEARCA-2026-53 / 34-105532 | Immediately effective amendment to Rule 7.34-E(T): Overnight Trading Session |
| 2026-06-03 | Cboe EDGX | SR-CboeEDGX-2026-019 / 34-105587 | SEC APPROVED with Amendment 1 |
| 2026-06-22 | NYSE American | (pending) | Filed to extend trading hours |
| 2026-07-24 | IEX | SR-IEX-2026-19 / 34-105959 | Immediately effective: amend hours |
| 2026-08-14 | 24X National | 34-106061 (order) | SEC temporary conditional exemptive relief for overnight trading, effective Jan 24 2027 |
The Dec 6 2026 SIP extension is not the trigger. It is the completion date of a phased rollout that Nasdaq started filing in January 2026 and got approved in April, that Cboe EDGX matched and got approved in June, and that NYSE Arca went immediately effective on in late May. When SIPs light up, the exchange side is ready to switch on the sessions already written into their rulebooks.
The regulator has moved too, and in a direction that makes the fee code matter more, not less. On June 11, 2026 the SEC proposed rescinding Rule 611, the trade-through rule, and Rule 610(e), the locked-and-crossed prohibition, outright. Comments closed August 17. The same day it deferred the tick-size and access-fee-cap amendments a second time, to November 2027. Read those two decisions together. If 611 goes, the protected-quote mechanism that routed orders toward the best displayed price goes with it, and what is left to discipline routing is best-execution obligation plus whatever the fill itself discloses. Rule 610(d) already requires that disclosure to include the fee. A market with less order protection and machine-readable fees on every execution report is a market where the liquidity code becomes the primary evidence of execution quality, per fill, per venue, in real time. That is the environment these 732 codes were built for, whether or not the venues that wrote them saw it coming.
And the protocol side has moved too. NYSE Pillar Binary Gateway Specification v6.0, dated August 14, 2026, defines TradingSessionID as a 3-bit field with eight values, and value 0 is Overnight Trading Session. The remaining values enumerate every combination up through 7 (Overnight, Early, Core and Late). Per-venue applicability columns for NYSE, American, National, Arca and Texas govern which venues accept which values. So the leading indicator this article was written to watch for has already fired at the largest US exchange operator, four months before the SIP catches up.
The other Overnight-eligible codes at protocol level today: MIAX Pearl's 46 pre- and post-market codes with E/F prefixes still describe 4am-9:30 and 4pm-8pm, not the true overnight window; the venue instrumented extended sessions early but not (yet) the tape after 8pm. Nasdaq's five pre-market codes are similar. Cboe's W remains a Hold-Early-to-7am marker. The distinct pattern to watch now is who else moves TradingSessionID or its equivalent to include the 8pm-4am block in the OUCH, BOE and MEMO spec revisions.
The taxonomy that classifies today's 732 codes into four architectures is the same taxonomy that will decide, at protocol level, what the overnight session gets to be. NYSE went first. Whoever ports the pattern to a bitset or a base-plus-suffix architecture next will tell us how the flow will price.
This piece is the reading. The tools below are the doing. The code taxonomy, the overnight thesis and the venue dossiers all run on the same live pipeline.
Execution Codes Explorer
All 732 codes, faceted and sourced. Per-venue dossiers, protocol citations, exact-code search.
Venue Intel
The full venue-structure workbench: filings, regulatory posture, volume, routing and risk by venue.
Overnight Session
The live overnight tape across BlueOcean, Bruce and Moon, where the 8pm to 4am flow actually prints today.
Data Coverage
What Sapinover holds and how it is sourced, from the code corpus to the three-venue overnight pipeline.
Every code, count and rule citation in this piece comes from a document anyone can read. The codes were extracted from each venue's own published protocol specification: NYSE's Pillar reason-code workbook, Cboe's Titanium BOE specification, IEX's FIX specification, MIAX Pearl's liquidity indicator codes document, Nasdaq's OUCH specification, the shared MEMO FIX specification for MEMX and LTSE, and TXSE's FIX order entry specification. Rules, compliance dates and filing references come from SEC releases, Federal Register notices and 19b-4 filings, each linked above.
No confidential, client or non-public information was used. Sapinover maintains a proprietary overnight ATS tape; none of it appears in this article, which is entirely a reading of the public record.
The codes, the per-venue counts and the filing dates are facts, each traceable to a cited document. The framework is ours. No exchange describes itself as using an "architecture", and the five-way classification in this piece is our reading of what the specifications have in common, not a standard any venue recognises. Two venues could reasonably be sorted differently at the margin.
The fee-key argument is a generalisation. IEX documents the relationship explicitly for itself, stating in its own specification that its liquidity tag is used to determine trading costs, and Cboe's fee-eligible and non-eligible code pair is visible in its published schedule. That the same logic holds across every venue is our inference from the pattern, not a claim any other operator has made. The closing argument, that withdrawing order protection while fee disclosure at the fill remains mandatory turns the execution report into the primary evidence of execution quality, is an argument rather than a finding.
Protocol specifications and fee schedules change, sometimes without notice. Counts are stated as of the August 2026 snapshot and should be re-checked against the current specification before they are relied on. Nothing here is investment advice, a recommendation, or a solicitation.
Underlying dataset: 732 liquidity codes extracted from each venue's published order-entry spec, market-data spec, fee schedule, and rulebook where available. Facets, provenance and per-venue counts are in the pipeline's canonical JSON, hashed for change detection. Method follows an additive, faceted design: the native code and its source are never discarded, and unmapped codes carry an explicit reason rather than being dropped.
