SAPINOVER OS v2.0 :: INITIALIZING...
000%
Sixteen exchanges. Seven hundred and thirty-two liquidity codes. Four incompatible architectures for the same regulatory requirement. What the fee-code taxonomy reveals about market structure, and what the overnight session will look like when it starts.
On November 3, 2025, two amendments to Regulation NMS took effect. Rule 610 cut the access-fee cap for protected quotations from $0.0030 per share to $0.0010. Rule 612(d) added a requirement that exchange fees be determinable at the time of execution. The D.C. Circuit upheld both in October 2025.
The first change compressed rebates. The second changed the shape of exchange protocol messages in a way most market-structure analysis has not caught up to. 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. Sixteen NMS-equity venues published a total of 732 native liquidity codes as of August 2026. Four incompatible architectures split them.
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.
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 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 612(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 a rulebook change: the field or bit already exists and the fee schedule references it. Enumerated architectures require a new code per new fee dimension, and every new code is a 19b-4. A venue's architecture choice partly explains the frequency of its fee-schedule filings.
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.
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 612(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 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 describes 8:00 p.m. to 4:00 a.m.
As of August 2026, no national securities exchange operates between 8:00 p.m. and 4:00 a.m. Eastern. Only three alternative trading systems do: BlueOcean (BOATS), Bruce Markets, and Moon ATS. The Consolidated Tape and UTP plans extend hours on December 6, 2026, and until then the SEC has declined to exempt an exchange from the requirement that the securities information processors be fully functional during the trading session.
The 24X National Exchange applied for such an exemption and was denied. It received a conditional order on August 14, 2026 permitting phased test-symbol trading beginning November 8, 2026, with production launch targeted for December 6 when the SIPs go live in overnight hours. The Texas Stock Exchange went live July 6, 2026, but during regular hours only.
The overnight session, in other words, is unwritten. When it starts, the first exchange to file a 19b-4 that introduces a new liquidity indicator code specifically describing that window will be signaling its intent to compete for the flow that currently rests on three ATSs. That filing is the leading indicator for anyone tracking exchange strategy after December 6. It will land in the Federal Register, on the same page as every fee change and every routing rule amendment, searchable by anyone who chooses to look.
Which is worth remembering: 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.
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.
