Direct Answer
Exchanges do not guarantee that trade prints are final when first published. Three types of post-publication events can change the official record. A late print is a trade that is reported to the tape after a delay, it occurred at the time indicated by the exchange timestamp but arrived in the published data stream later than expected. A corrected print replaces a previous print with updated data (e.g., the price or volume was wrong in the original report). A cancelled print (also called a "busted trade") rescinds a previously reported transaction entirely, treating it as if it never occurred for settlement purposes.
In real-time systems, these events require buffering and re-evaluation: a signal computed on a print that is later cancelled must be treated with caution, and a signal that depended on the cancelled print's contribution to volume or price may need to be recomputed. In historical databases, these events require storing multiple versions of each print, the original and any subsequent corrections, with timestamps for when each version was known, so that a historical replay sees exactly the data that was visible at each decision point.
Key Takeaways
- Condition codes identify print type: CTA/UTP condition codes distinguish regular trades, late prints (code "L"), out-of-sequence prints (code "Z"), corrected trades, and cancellations. Filtering by condition code is the primary mechanism for excluding non-standard prints from signals and bars.
- Corrections have a time window: Exchanges can correct or cancel a trade within a defined window, typically up to end of day or T+1 under CTA/UTP rules. After the window closes, the trade is permanent in the official record even if later found to be erroneous.
- Real-time impact differs from historical impact: In real time, a late print may trigger a false breakout signal; a cancel may make the "breakout" disappear. In historical data, the vendor may have applied corrections and your bar history may not match what live traders saw at the time.
- LULD circuit breaker executions are scrutinized: Trades executed during limit-up/limit-down price band violations are frequently reviewed by exchanges and may be busted. Live systems that fill near price band limits should hold signals provisional until the trade print confirmation window closes.
- Out-of-sequence prints affect bar construction: A print that arrives at 10:05 but has an exchange timestamp of 09:55 belongs in the 09:55 bar, not the 10:05 bar. Most bar-building systems use receipt time for bar assignment, incorrectly placing the print in the current bar. Correct systems use exchange timestamps for bar assignment.
- Volume must be updated on cancel: A cancelled print must be subtracted from the running volume total. If a 500,000-share block print is busted at 10:30 AM after being initially reported at 10:15, the volume figures for the 10:15-10:30 bars are overstated until corrected.
- Cleaning vendors apply corrections in hindsight: Historical market data vendors apply all known corrections to their datasets before distributing. This means historical cleaned data will not match what a live system saw in real time, because the live system did not know about corrections when they mattered for signal computation.
- Signal robustness to correction events can be tested: By replaying historical data in the raw (uncorrected) state and comparing signal outputs to the cleaned state, you can measure how sensitive your strategy is to late and corrected prints, and decide whether the difference is material enough to require real-time correction handling.
Core Concepts
Late Prints: Definition, Causes, and Handling
A late print is a trade execution that was valid and final at the time it occurred but whose report to the consolidated tape was delayed beyond the regulatory reporting window. Under FINRA trade reporting rules (Rules 6380A, 6380B, and 6282) and other SRO rules, trades must be reported within 10 seconds of execution. Late prints are marked with condition codes "L" (late report, regular trade) or "U" (late report, odd lot) in the CTA specification.
Causes of late prints include: high-volume periods where trade reporting queues build up, block trades negotiated off-exchange that are delayed in reporting, system glitches at the reporting member firm, and inter-market sweep orders that settle across multiple venues before final reporting. Late prints are more common during high-volatility periods (earnings announcements, market-wide events) when exchange matching engines are processing at peak rates.
For real-time signal computation, the key question is: should a late print trigger a recalculation of any signal that was computed before the late print arrived? For tick-by-tick signals (VWAP deviation, momentum), a late print that belongs to a past interval should be applied to that past interval's calculation if you have the infrastructure to maintain a mutable state for recent intervals. For bar-based signals computed at the bar close, a late print arriving after the bar closes may or may not warrant bar reconstruction depending on its size relative to the bar's total volume.
The practical approach for most systematic strategies is: filter late prints by checking the condition code field before including any print in signal computation. Late prints with condition code "L" or "U" are included in volume aggregation for the session (they are valid transactions) but should be assigned to their original exchange-timestamp interval, not the receipt-timestamp interval. Bars built with exchange-timestamp assignment will correctly place late prints; bars built with receipt-timestamp assignment will misplace them.
Corrected Prints: The Exchange Amendment Process
A corrected print replaces a previously published trade with updated data. The common corrections are: wrong price (fat finger or encoding error), wrong volume, wrong exchange, and wrong condition code. Under CTA/UTP rules, the correction message references the original print's sequence number or trade identifier, so systems can match the correction to the original and replace it.
Corrections arrive via specific message types: in Nasdaq ITCH. This is a "Trade Cancel" message followed by a new "Trade" message if the correction involves a different price; in the SIP consolidated feed, corrections carry specific condition codes. The processing pipeline must maintain a lookup of recent prints by their trade identifier, and when a correction arrives, update or void the relevant record.
The operational risk of corrections is that any signal or order fired based on the original (incorrect) print may have already been acted upon. If a print reports 100,000 shares at $50.00 and triggers a volume breakout signal, and 30 seconds later a correction arrives showing the actual volume was 1,000 shares at $50.00, the signal was false. The strategy may have already submitted an order. The correction cannot undo the order, it can only inform the strategy that the trigger was based on incorrect data.
The frequency of corrections varies by market condition. During normal sessions, corrections are rare, typically less than 0.01% of prints are corrected. During high-volatility events, during opening and closing auctions, and during technical outages, correction rates can spike significantly. A strategy that is sensitive to individual large prints should treat all initial prints as provisional for a short window (5-30 seconds) before committing to a signal based on them.
Cancelled Prints (Busted Trades) and Their Settlement Effects
A cancelled print is a trade that the exchange has determined should not have occurred, typically because it was executed at a price far outside the market (a "clearly erroneous execution") under exchange rules. Under NYSE and Nasdaq rules, a clearly erroneous execution is one that occurs at a price more than a specified percentage away from the consolidated last sale at the time of execution. The threshold varies by reference price band and trading session, not by a flat per-tier percentage: during regular market hours, numerical guidelines generally range from 3% (stocks priced above $50) to 10% (stocks priced $25 or below), with wider thresholds during pre-market and post-market sessions.
When a trade is busted. It is removed from the official record and from settlement. Counterparties to the busted trade are unwound, their positions revert to the pre-trade state. This means a trader who appeared to have bought 10,000 shares at a 20% discount in a flash crash event may find the trade cancelled, leaving them with no position and no fill at the favorable price.
For historical data, cancellations present a storage challenge. Most data vendors store only the final, official tape, after all cancellations and corrections have been applied. This "clean" history does not reflect what traders saw in real time during the original events. A historical backtest that uses cleaned data cannot simulate a strategy that was sensitive to the uncancelled prints, because the raw data no longer exists in the vendor's distribution. Point-in-time storage solves this: storing each version of the tape as it was seen in real time, with cancellations stored as separate events rather than retroactive deletions.
In practice, cancel volumes are tiny relative to total tape volume. The more significant operational concern is that the first appearance of a large print, before it is known to be a candidate for cancellation, can trigger risk systems, signal generators, and manual observations. Engineering teams must decide how long to buffer a potentially cancellable print before treating it as confirmed: typically 5-60 seconds for intraday events, up to end-of-day for prints near price band limits.
Out-of-Order Message Sequencing
Beyond late prints (which are out-of-order in time), market data messages can also arrive out-of-order in sequence. Feed protocols assign sequence numbers to each message. If messages arrive in order 1, 2, 4, 3, 5 (where 3 arrives after 4), a naive processing pipeline that handles each message as it arrives will process message 4 before message 3, potentially computing an incorrect signal if 3 and 4 were related events (e.g., 3 was a quote update that preceded the trade in 4).
Handling out-of-order messages requires either a buffering window (hold messages for N milliseconds and sort by sequence number before processing) or an optimistic approach (process in receipt order, re-process when an out-of-order message arrives to correct state). For most systematic strategies where the signal horizon is seconds or longer, a 10-50 ms sort buffer is invisible to the strategy but ensures correct message ordering. For sub-millisecond strategies, even a 10 ms buffer is unacceptable, and out-of-order message handling must be designed into the architecture from the start with lock-free data structures and careful event ordering.
Worked Scenario
A real-time intraday strategy uses a "volume surge" signal: fire a buy when a single print's volume exceeds 10× the 20-period average print volume. During a normal trading session, the team observes a signal firing on an apparent 500,000-share print that turns out to be a data encoding error corrected 45 seconds later.
- Original event: At 10:23:14 ET, a print arrives for 500,000 shares at $45.20. The 20-period average print volume is 3,200 shares. The volume is 156× the average, well above the 10× threshold. The signal fires. A market buy order for 1,000 shares is submitted.
- Correction arrives: At 10:24:01 ET (47 seconds later), a correction message arrives replacing the 500,000-share print with 5,000 shares at $45.20. The actual volume was 5,000 shares, just 1.6× average, well below the 10× threshold.
- Post-trade assessment: The buy order partially filled at $45.23 before the correction arrived. The strategy now holds an unintended position opened on a false signal.
- Design fix: The team implements a "confirmation delay" for prints above 50× average volume: don't fire the signal until the print has been confirmed for 60 seconds (i.e., no correction or cancel has arrived). This eliminates most false triggers from encoding errors and late-night block prints reported incorrectly, at the cost of 60 seconds of execution delay for the small number of genuine volume spikes.
- Residual risk: The 60-second confirmation window still leaves exposure to corrections that arrive more than 60 seconds after the original print. The team adds a secondary risk rule: if a correction arrives within 5 minutes that would have prevented the signal, close the position at market price regardless of P&L.
Measurement Framework
| Measurement | Question to Answer |
|---|---|
| Late print rate (% of daily prints) | What fraction of prints in your feed carry late-report condition codes, and is this rate normal? |
| Correction rate (% of daily prints) | How often do corrections arrive, and is the rate elevated during specific sessions or market conditions? |
| Correction arrival lag (seconds, median) | How quickly after the original print do corrections typically arrive, how long must you wait before treating a print as stable? |
| Cancel rate (% of daily prints) | How often are prints cancelled outright? Is this rate higher near LULD price band boundaries? |
| Signals on later-corrected prints (% of signals) | What fraction of your live signals historically fired on prints that were subsequently corrected or cancelled? |
| Bar reconstruction frequency (bars/day) | How often does a late or corrected print change a bar that was already closed and acted upon? |
Common Failure Modes
Treating All Incoming Prints as Final
A live signal engine that processes each print message the moment it arrives and immediately fires orders on any signal it triggers is vulnerable to late and corrected prints. This is particularly dangerous for signals that key on single large prints (block trade detection, volume surge signals, price breakout triggers) because a single erroneous large print can cause an outsized, committed position before the correction arrives.
The fix is a configurable confirmation delay proportional to print size. Normal prints (below 10× average volume) can be acted on immediately. Unusual prints (above 50× average or at extreme price levels) should be held for a configurable window before triggering downstream signal logic. Most strategies can tolerate 5-30 seconds of additional latency for extreme prints without meaningfully degrading performance.
Using Cleaned Historical Data to Calibrate a Live System
A team calibrates their volume-surge signal thresholds using a cleaned historical dataset (provided by a vendor who has applied all known corrections retroactively). The cleaned data shows a much lower frequency of large prints than the raw tape did in real time, because many apparent large prints were corrections or cancellations that the vendor removed. The signal threshold calibrated on cleaned data is therefore set too high, it will miss some genuine volume surges that would have appeared in the raw real-time feed.
Always calibrate live-firing signal thresholds against raw historical data (before corrections) to ensure the thresholds represent what the live system will actually encounter. Use cleaned data for return calculations (where you want to know the true economic outcome), and raw data for trigger calibration (where you want to know what the live system will see).
Misassigning Late Prints to the Wrong Bar
A 1-minute bar builder that assigns each print to the bar whose receipt time falls within the bar's window will misplace out-of-sequence prints. A print that executed at 10:05:45 but arrived in the feed at 10:08:30 will be assigned to the 10:08-10:09 bar instead of the 10:05-10:06 bar. This means the 10:08-10:09 bar has inflated volume and the 10:05-10:06 bar has understated volume. For volume-sensitive signals calibrated in historical research (where bars were built with correctly ordered exchange timestamps), the live system will see different bar characteristics and the signal will behave differently than calibrated.
Not Accounting for Weekend and Holiday Trade Report Delays
Some block trades negotiated off-exchange or executed via delayed reporting (e.g., certain bond-related equity transactions, after-hours block trades) are reported with the exchange timestamp of when they occurred even when that time falls outside regular session hours. On Monday morning, the Sunday night and weekend trade reports can appear in the feed simultaneously with regular Monday session trades, causing a burst of late-timestamped prints that may appear as anomalously high weekend volume if processed without checking the exchange timestamp against the expected session calendar.
Frequently Asked Questions
What is a "busted trade" and who decides to bust it?
A busted trade is a trade execution that an exchange has determined qualifies as "clearly erroneous" under its rules and rescinds from the official record. The exchange's market operations team (or an automated surveillance system) initiates the review. Counterparties to the trade can petition for a bust within a specified time window. The exchange rules define the price deviation threshold that qualifies a trade as clearly erroneous, typically 5-10% away from the prevailing market price at the time of execution. Both sides must be notified; in some cases, both must agree (for large block prints) before the exchange will bust.
How do exchanges handle clearly erroneous executions during flash crashes?
During a flash crash (a rapid, extreme price move over a short period), many trades may execute at prices far from "fair value." Exchanges review these trades and may bust those that fall outside the clearly erroneous execution rules. However, not all flash crash prints are busted, only those meeting the specific percentage threshold at the time of execution. Traders who sold at the flash crash low and had their trades busted received no price improvement; traders whose sells at the low were not busted kept their losses. This selective cancellation creates controversy because it can benefit certain participants (high-frequency traders who bought at the low and had their fills confirmed) while other participants have their opposing trades busted.
Are corrections and cancellations included in real-time data feeds?
Yes. The CTA/UTP consolidated feed includes cancel and correction messages as distinct message types. Data vendors that distribute real-time feeds should pass these messages to subscribers so that downstream systems can update their state. Whether a specific data vendor's API exposes these messages depends on their implementation, some vendors process corrections internally and deliver only the corrected values, while others pass the raw correction messages. Verify with your data vendor whether correction and cancel messages are available in their feed, and whether you need to subscribe to a specific message type or data channel to receive them.
How long after a trade can an exchange cancel it?
The clearly erroneous execution review window varies by exchange but is generally short, trades must be reviewed and busted within a few hours of execution under NYSE and Nasdaq rules. For inter-market busts (where multiple exchanges must coordinate), FINRA has jurisdiction and the window is slightly longer. After the window closes, trades are final regardless of how erroneous they appear. However, individual counterparties can still mutually agree to cancel a trade even after the exchange window has passed, though this requires direct bilateral coordination and is less common.
Do high-frequency traders have an advantage in avoiding busted-trade losses?
HFT firms with fast data feeds may observe a potential flash crash or circuit breaker trigger milliseconds before slower participants, giving them the ability to pull their limit orders from the book before the erroneous trades occur. Whether this constitutes an unfair advantage is a regulatory and ethical debate. In terms of data engineering, the practical implication is that strategies without low-latency data feeds may see their orders fill at prices that are subsequently busted, while faster participants avoided the fill entirely. This is one reason that LULD circuit breakers, which pause trading when prices move too fast, were designed to protect slower participants from extreme one-sided executions.
How do I handle a correction that arrives after my bar has already closed?
There are two approaches. The first is to mark the affected bar as "needs recomputation" and re-run any signals that were computed from it. This requires stateful signal tracking, knowing which signals depended on which bars. The second is to ignore corrections that arrive after a bar has closed, accepting that a small number of bars are slightly inaccurate. For most daily-bar strategies, the second approach is acceptable because corrections are rare and their impact on daily bars is typically tiny. For minute-bar strategies where a single large corrected print can meaningfully change a bar's volume and VWAP, the first approach is preferable but requires more complex state management.
What condition codes indicate a print should be excluded from normal bar computation?
Under the CTA Plan specification, the key exclusion conditions include: "C" or "E" for error/cancelled trade, "T" or "U" for extended hours (if your bars are regular-hours-only), "Z" or "27" for out-of-sequence (which should be re-slotted to the original time, not the receipt time), and any condition code combination that includes the "no last sale" or "not eligible for last sale" flag. The specific codes change with CTA Plan updates. Always refer to the current CTA Plan "Appendix C" for the definitive list of condition codes and their "last sale eligible" status, as this is the official definition of which prints should be included in price and volume calculations.
Is it possible for a correction to arrive the next day?
Yes, though it is uncommon. Under CTA/UTP rules, the review window for clearly erroneous executions closes by end of the trading session in most cases, but certain types of corrections, particularly for block trades reported via the FINRA Trade Reporting Facility (TRF), can arrive T+1 or later. Data vendors typically apply any corrections received after market close during their end-of-day processing, and the corrected values appear in next-day historical data downloads. This is one reason why the historical data you receive from a vendor the day after a session may differ from what you saw in the real-time feed during the session, overnight corrections were applied.
Why do corrections matter more for volume-weighted calculations than for closing prices?
A closing price is usually determined by a specific auction or by the last qualifying print, so a corrected trade in the middle of the session often leaves it unchanged. A volume-weighted average consumes every included print with its size, so a corrected price or a revised quantity changes the result for the whole period. Anything derived from that average, including execution benchmarks and any signal built on it, inherits the change, which is why recomputation policy matters most for these measures.
References
- CTA Plan: CTS Pillar Multicast Output Binary Specification (condition codes including cancel and correction types)
- SEC: Order Approving the National Market System Plan to Address Extraordinary Market Volatility (Release No. 34-67091, 2012): Limit Up-Limit Down Rule (LULD), the mechanism for preventing clearly erroneous executions in US equity markets
- FINRA Rule 11890: Clearly Erroneous Transactions (the standard for trade busts)
- Kirilenko, A., Kyle, A. S., Samadi, M., & Tuzun, T. (2017). "The Flash Crash: High-Frequency Trading in an Electronic Market." Journal of Finance, 72(3), 967-998. (Analysis of erroneous executions during the May 6, 2010 flash crash)
- Nasdaq ITCH 5.0 Protocol Specification (cancel and correction message types at the exchange level)
Educational Disclaimer
Exchange rules on clearly erroneous executions, condition code definitions, and review window timelines change periodically. Verify current rules with the relevant exchange and FINRA before designing production risk and correction-handling systems.