Introducing

Understanding Trade Eligibility

May 26, 2020

The process of generating aggregate bars is more complex than it might seem. Users often encounter difficulties when attempting to replicate our Open, High, Low, Close, and Volume values from our tick data APIs. This is a common challenge, especially when comparing our data to other popular sources like Yahoo Finance or Bloomberg. Additionally, users may notice discrepancies between real-time trades coming in through our WebSocket connection and the High or Low values provided by our Aggregates or Snapshot endpoints.

These discrepancies stem from specific ‘Sale Conditions’ rules, as outlined in the UTP and CTA plan specifications. These rules must be followed to calculate aggregate values accurately.

We've put together resources to explain these concepts and help clear up any confusion that may arise from these technical details.

Wondering what the UTP and CTA are? Great question! You can refer to our “Understanding the SIPs” blog article to learn more about how data flows from exchanges to us and then to our customers.

CTA Plan

The CTA plan specification provides a detailed 93-page explanation of how price data is disseminated. To make it easier, we’ve highlighted some of the key points:

• Sale Condition: Refers to the sale condition tied to a trade. It also explains how these sale conditions influence the calculations of Open, Last, High, and Low prices, both on a Consolidated and Participant basis.

The sale conditions mentioned are the raw codes, not the ones we provide in our real-time and historical tick APIs.

To create aggregates that reflect the entire market, you should follow the Consolidated Update guidelines. If you’re focusing on aggregates specific to individual exchanges, the Participant Update guidelines should be applied.

Four key notes can impact how the OHLC (Open, High, Low, Close) values are calculated. These notes act as conditions within the sale conditions.

• Note 1: YES (it should update the values), if it is the only qualifying last trade, or if it’s the participant’s first qualifying last trade. Otherwise, NO.
  • This applies to the Market Center Opening Trade and determines whether the condition updates the price of the last qualifying trade.
• Note 2: YES, if it is the only qualifying last trade. Otherwise, NO.
  • This note also determines if the condition updates the price of the last qualifying trade.
• Note 3: YES, if it is the only qualifying last trade, if it is from the same participant as the previous last, or if it is from the listing market for that security. Otherwise, NO.
  • This is specific to sold last trades (late-reported trades).
• Note 4: YES, if it is the first or only qualifying trade of the day. Otherwise, NO.
  • This note determines if the condition updates the open price. In cases of multiple Market Center Opening Trades, the latest MOC trade takes precedence.

Multiple conditions can apply to each trade, so what happens if these conditions contradict each other?

• If all Sale Conditions indicate that the trade qualifies, it will be included in the calculations.
• If any one of the Sale Conditions indicates ‘NO’, the trade does not qualify, and the ‘NO’ takes precedence, excluding the trade from calculations.
• If all Sale Conditions indicate that the trade qualifies but one includes a Sale Condition with deviating criteria (as in Notes #1, #2, #3, or #4), the trade will still qualify, with the ‘Note Criteria’ taking precedence to include the trade in the calculations.

That is the TLDR for the CTA’s specification regarding Sale Conditions and their eligibility to be included into the OHLC aggregates. If you still yearn for more information, check out pages 62-64 of the following document: https://www.ctaplan.com/publicdocs/ctaplan/notifications/trader-update/CTS_BINARY_OUTPUT_SPECIFICATION.pdf

UTP Plan

Like the CTA specification, the UTP plan has its own rules and regulations regarding the eligibility of trades to update aggregates. While the CTA Plan specification pertains to updating the OHLC values, the UTP plan uses these conditions to determine when to update the HLCV or High, Low, Close, and Volume values.

The UTP Sale condition matrix is available on our Conditions and Indicators page. This spec answers most questions asked about the eligibility for trades to update the volume value.

Similar to the CTA matrix, this table outlines the eligibility of each value to be updated based on two sets of guidelines: the Consolidated Processing Guidelines and the Market Center Processing Guidelines.

• The Consolidated Processing Guidelines pertain to the consolidated tape, specifically the UTP SIP feed.
• The Market Center Processing Guidelines apply to individual participants, such as exchanges.

If your goal is to create aggregates representing total market volume, follow the Consolidated Processing Guidelines. For aggregates representing each exchange individually, use the Market Center Processing Guidelines.

Much like the CTA plan, certain conditions apply to other conditions. These superscript values appear in some table cells and are defined below:

1. UTDF Subscribers should only update the field values if the trade is the first or only last-sale-eligible transaction from any UTP participant of the trading day.

• This means that recipients should only update the field if the trade is the first or last eligible transaction of the trading day.
  

1. UTDF Subscribers should update the consolidated last sale field if the trade is received before the End of Last Sale Eligibility (16:00:10). After this message is received, the transaction will only update the market center’s specific last sale value, not the consolidated one.

• Data recipients should update the last sale if the trade is received before the EOLS message, which marks the close of the trade-reporting window for consolidated last-sale eligibility.
• Under the UTP plan, participants (exchanges) must report trade transactions that may impact the last sale price within 10 seconds of the normal market close. This message is sent 10 seconds after the primary market’s close message (Page 34).

1. Data Recipients maintaining individual market center open values should use the “Q” value as the official market center opening value and adjust their data displays accordingly.

• This indicates that if the recipient is tracking the participant’s open values, they should use the ‘Market Center Official Open’ condition code and follow the associated rules.
  
  

Additional notes to keep in mind when making these adjustments:

• For the sale condition modifier “M” (Market Center Close Price), UTDF subscribers should be aware that this value is available to all UTP participants but may not be supported by all. If a UTP participant does not provide this sale condition code, UTDF subscribers should continue displaying the final eligible last sale trade as the closing price for that market center.
• The “M” sale condition modifier will update the last sale price for the market center, but not for the consolidated market. If the market center responsible for the consolidated last sale price submits a separate “M” transaction, the two last sale values might not match.
• For the sale condition modifier “Q” (Market Center Open Price), UTDF subscribers should note that this value is available to, but may not be supported by, all UTP participants.
• When updating High/Low/Last statistics, if a trade record includes multiple sale conditions and any one of those conditions indicates a “no” for an update, that “no” takes precedence, and no update will occur for the related statistical value.
  

For more information, refer to pages 42 - 47 of the following document: https://www.utpplan.com/DOC/UtpBinaryOutputSpec.pdf

Each trade condition, their definitions, update rules, and CTA/UTP mappings can now be found in our Conditions API endpoint:

{
   "asset_class": "stocks",
   "data_types": [
    "trade"
   ],
   "id": 2,
   "name": "Average Price Trade",
   "sip_mapping": {
    "CTA": "B",
    "UTP": "W"
   },
   "type": "condition",
   "update_rules": {
    "consolidated": {
     "updates_high_low": false,
     "updates_open_close": false,
     "updates_volume": true
    },
    "market_center": {
     "updates_high_low": false,
     "updates_open_close": false,
     "updates_volume": true
    }

At Polygon.io, we consider both the CTA and UTP specifications when calculating the aggregate bars we provide. We adhere to the consolidated update guidelines of both plans to ensure accuracy. If you’re looking to recreate these bars from our tick data, these are the guidelines you’ll need to follow.

Our system is designed to account for every condition applied to a trade, delivering the most precise data possible. Polygon normalizes the conditions between the SIPs into a unified list. You can find the condition codes you need to follow on our Conditions and Indicators page, or access them via our API through our Condition Mappings endpoint.

If you ever have any additional questions, concerns, or suggestions, please don’t hesitate to contact us. We’re always happy to help any way we can.

• 

  Jack Bell

  jack

  Read More