Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save architectureman/12738c8084a425b0dd8a9bd50bb07e2c to your computer and use it in GitHub Desktop.

Select an option

Save architectureman/12738c8084a425b0dd8a9bd50bb07e2c to your computer and use it in GitHub Desktop.
Cboe PITCH Protocol for Order Management Systems

Cboe PITCH Protocol for Order Management Systems

Introduction

This document provides guidance for Order Management System (OMS) developers working with the Cboe Australia Titanium Multicast Depth of Book (PITCH) protocol. It details how to properly interpret, process, and manage order information from the PITCH feed for effective order tracking and execution management.

Overview of Cboe PITCH Protocol

The Cboe Australia Multicast PITCH protocol delivers real-time market data including:

  • Symbol information
  • Full depth of book quotations
  • Order execution information
  • Market status updates
  • Auction data

The protocol uses a multicast delivery mechanism with gap recovery capabilities to ensure complete and reliable market data. It's important to note that PITCH is a data feed protocol only and cannot be used for order entry. For order entry, refer to Cboe's FIX or BOE specifications.

Feed Architecture

Cboe Australia PITCH feeds are delivered through three primary multicast feeds:

  • Feed A (Primary Data Centre)
  • Feed B (Primary Data Centre)
  • Feed E (Secondary Data Centre)

Each feed is "Gig-shaped" (requiring 1 Gbps bandwidth) and provides identical market data content with independent packet framing. For optimal reliability, clients should:

  1. Connect to multiple feeds (ideally A and B)
  2. Implement feed arbitration to recover from packet loss
  3. Establish a connection to the Gap Request Proxy (GRP) for requesting missed messages
  4. Connect to the Spin Server to obtain complete order book snapshots when needed

Message Sequencing and Recovery

Sequence Numbering

All PITCH messages are delivered with a sequenced unit header containing:

  • Message length
  • Message count
  • Unit ID (identifying the symbol range)
  • Sequence number

Sequence numbers increment by one for each message within a symbol unit. Tracking these sequence numbers is essential for detecting missed messages.

Gap Recovery

When a sequence gap is detected, your OMS should:

  1. Cache subsequent messages that arrive out of sequence
  2. Connect to the Gap Request Proxy (GRP) via TCP/IP
  3. Request the missing sequence range
  4. Apply recovered messages in sequence
  5. Process cached messages once recovery is complete

Gap requests have limitations that your OMS must manage:

  • Maximum 100 messages per request
  • 320 requests per second limit
  • 1,500 requests per minute limit
  • 100,000 requests per day limit
  • Requests must be within 1,000,000 messages of the current sequence

Spin Recovery

For larger gaps or initial connection, use the Spin Server to obtain a complete order book:

  1. Connect to the Spin Server via TCP/IP
  2. Request a spin of the current order book (includes Trading Status, Add Order, Calculated Value, and Auction Update messages)
  3. Buffer real-time messages received during the spin
  4. Apply the spin data to establish your base order book
  5. Apply buffered messages once the spin is complete

Key Message Types for Order Management

Order Lifecycle Messages

These messages are critical for tracking orders throughout their lifecycle:

Add Order (0x37)

  • Represents a new visible or undisclosed order on the Cboe book
  • Contains unique Order ID, side, quantity, symbol, price, and optionally a participant ID (PID)
  • For undisclosed orders, quantity will be zero

Order Modification Messages

  • Order Executed (0x38): Reports visible order executions
  • Order Executed at Price (0x58): Reports auction executions
  • Reduce Size (0x39): Reports partial cancellation
  • Modify Order (0x3A): Reports changes to price or quantity
  • Delete Order (0x3C): Reports order removal from the book

Trade Messages (0x3D)

  • Reports executions of non-displayed orders and off-exchange trades
  • Critical for tracking executions that don't affect the visible order book
  • Includes symbols, quantities, prices, execution IDs, and trade types

Trade Break (0x3E)

  • Reports cancellation of a previously reported execution
  • References the original execution ID

Market Status Messages

Your OMS should track these messages to understand market conditions:

Trading Status (0x3B)

  • Indicates current trading status for a security
  • Status values include:
    • C = Closed
    • A = Pre-market
    • T = Trading
    • M = MOC Trading
    • P = Post-market
    • H = Halted
    • S = Trading suspended
    • O = Pre-Open (for auctions)
    • E = Pre-Close (for auctions)

Auction Messages

  • Auction Update (0x59): Provides current auction information during pre-auction periods
  • Auction Summary (0x5A): Reports auction results, including price and executed shares

Administrative Messages

These messages help maintain system integrity:

Unit Clear (0x97)

  • Instructs clients to clear all orders for a specific unit
  • Only sent during rare recovery events

End of Session (0x2D)

  • Indicates the end of the trading session for a unit

Order ID Management

Order ID Format

  • 8-byte binary field in Little Endian format
  • Day-specific identifier assigned by Cboe
  • Can be converted to base-36 to match FIX or BOE acknowledgements:
    • Example: Binary value 05 40 5B 77 8F 56 1D 0B → base-36 value 631WC4000005

Matching Order IDs Across Protocols

To correlate PITCH Order IDs with FIX/BOE Order IDs:

  1. Convert the decimal (base-10) value to a base-36 value
  2. No padding is required
  3. Example: Decimal 288958144494319104 → base-36 27174309PSLC

Trade and Execution Tracking

Execution ID Format

  • 8-byte binary field in Little Endian format
  • Day-unique identifier for each execution
  • Can be converted to base-36 (9-character, zero-padded) to match FIX or BOE execution reports:
    • Example: Binary value 34 2B 46 E0 BB 00 00 00 → base-36 value 0AAP09VEC

Complete Execution View

To build a complete view of all executions:

  1. Combine all Order Executed messages (for visible order executions)
  2. Add all Trade messages (for hidden and undisclosed order executions)
  3. Remove any executions referenced in Trade Break messages

Special Order Handling

Undisclosed Orders

  • Identified by an Add Order message with quantity = 0
  • Executions reported via Trade messages, not Order Executed
  • Fully executed undisclosed orders will receive a Delete Order message

Iceberg Orders

  • Visible portion reported with Add Order message showing display quantity
  • Visible executions reported with Order Executed messages
  • Hidden portion executions reported with Trade messages
  • When visible portion is exhausted, replenishment shown with new Add Order (with new Order ID)

Multi-Day Orders (GTC/GTD)

  • Re-appear each morning as new Add Order messages
  • Time priority is maintained within a price level
  • May be deleted at start of day if expired or affected by corporate actions

Auction Processing

Auction Types

  • Opening/Intra-day Auction (O): Market open and scheduled intraday auctions
  • Closing Auction (C): End-of-day auction
  • Halt Auction (H): Auction following a trading halt

Auction Message Flow

  1. Pre-auction: Trading Status changes to "O" (Pre-Open) or "E" (Pre-Close)
  2. Auction Updates: Auction Update messages report indicative price and volume
  3. Auction Execution:
    • Order Executed at Price messages for visible orders
    • Trade messages for undisclosed orders
    • Reduce Size or Delete Order messages for affected orders
  4. Auction Summary: Final auction statistics including price and volume

Implementation Considerations

Order Book Synchronization

  • Start each day with a fresh order book (no orders)
  • Process Add Order messages for multi-day orders at market open
  • Use Spin Server for mid-day recovery
  • Track sequence numbers to detect gaps
  • Use Gap Request Proxy for small gaps
  • Maintain heartbeats to keep connections alive

Data Integrity

  • Track sequence numbers within each unit
  • Buffer out-of-sequence messages
  • Recover from gaps using GRP or Spin Server
  • Ensure field decoding follows proper data types and formats
  • Handle unknown message types gracefully

Performance Optimization

  • Implement fast lookup by Order ID
  • Consider using hash tables for order storage
  • Pre-allocate memory for high-volume sessions
  • Optimize gap detection and recovery
  • Implement efficient feed arbitration for A/B feeds

Appendix: Message Field Data Types

  • Alphanumeric: Left-justified ASCII fields, space-padded on the right
  • Binary: Unsigned fields using Little Endian convention
  • Binary Price: 8-byte binary fields with 7 implied decimal places (denominator = 10,000,000)
  • Bit Field: Fixed width fields with each bit representing a Boolean flag
  • Printable ASCII: Left-justified ASCII fields in the range 0x20-0x7E
  • Binary UTC Timestamp: 8-byte unsigned values representing nanoseconds since the epoch

Appendix: Error Handling

  • Missing Sequences: Request via Gap Request Proxy
  • Large Gaps: Use Spin Server for full recovery
  • Disconnections: Reconnect and use Spin Server
  • Malformed Messages: Log and skip to next message
  • Unknown Message Types: Ignore but maintain sequence tracking
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment