# Feed Handlers and Normalization > Feed handlers connect to exchange data feeds and convert each venue's format into one standard internal format. Learn the design, symbol mapping and common pitfalls. Source: https://learn.tradelabsai.com/programming/feed-handlers-and-normalization/ Track: Programming and Data · Level: Advanced · Updated: 2026-10-03 Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice. Cite as: TradeLabs Learn, "Feed Handlers and Normalization", https://learn.tradelabsai.com/programming/feed-handlers-and-normalization/ Every exchange publishes market data in its own format. One sends JSON over WebSocket with prices as strings; another sends compact binary messages over multicast; a third names the same instrument differently and uses a different time unit. A feed handler is the component that connects to one venue's feed, decodes its messages and converts them into a single standard internal format. Everything downstream, from bar builders to strategies, then works with one consistent model regardless of where the data came from. ## What a feed handler does | Task | Example | |---|---| | Connect and subscribe | Open the WebSocket or join multicast groups, log on, subscribe to symbols | | Decode | Parse JSON, FIX or binary messages. See [Binary Protocols](https://learn.tradelabsai.com/infrastructure/binary-protocols/) | | Validate | Check sequence numbers and message integrity. See [Sequence Numbers, Dropped Packets and Out-of-Order Messages](https://learn.tradelabsai.com/programming/sequence-numbers/) | | Recover | Request snapshots or replays after gaps | | Normalise | Convert to the internal format: instrument ID, side, price, size, timestamps | | Publish | Pass normalised events to the rest of the system. See [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/) | | Monitor | Report latency, message rates, gaps and disconnects | ## Normalisation: the details that matter | Field | Venue differences | Normalised form | |---|---|---| | Symbol | BTCUSDT, BTC-USDT, XBT/USD, tBTCUSD | Internal instrument ID with a mapping table | | Price | String, float, integer in ticks, scaled integer | One consistent numeric type | | Size | Base units, contracts, lots | One unit, with contract size known | | Side | "buy", "B", 1, "bid", or aggressor flags | One enumeration | | Time | Seconds, milliseconds, microseconds, nanoseconds; local or UTC | UTC nanoseconds | | Event type | Trade, quote, book delta, status | One set of event types | **Example: Two venues, one trade** Venue A sends a trade as JSON: symbol "BTC-USDT", price "64250.5", size "0.012", side "sell", time in milliseconds 1790000000123. Venue B sends a binary trade message: instrument code 17, price as an integer 642505 with a scale of 1 decimal, quantity 12 in units of 0.001, aggressor flag 2 meaning seller, timestamp in nanoseconds. After normalisation, both become the same structure: instrument BTC/USDT spot, price 64250.5, size 0.012, aggressor sell, time in UTC nanoseconds, plus a venue tag. A strategy comparing prices across venues never needs to know their formats. ## Price representation Floating point numbers cannot represent many decimal prices exactly, so 0.1 plus 0.2 does not equal exactly 0.3. For research this rarely matters, but order prices must be exact multiples of the tick size. Many systems store prices as integers in tick units or as scaled integers and convert only for display. See [Tick Size and Tick Value](https://learn.tradelabsai.com/futures/tick-size-and-tick-value/). ## Symbol and reference data A reference data service holds each instrument's details: venue symbols, tick size, lot size, contract multiplier, trading hours and status. Feed handlers use it to map and scale values. Keeping it current is critical, because venues add, delist and change instruments frequently. See [Contract Specifications](https://learn.tradelabsai.com/futures/contract-specifications/). ## Design principles - **One handler per venue,** isolating venue specific quirks. - **Fail loudly** on unknown message types or fields rather than guessing. - **Keep the raw message** or a raw log for debugging and replay. See [Market Data Replay](https://learn.tradelabsai.com/programming/market-data-replay/). - **Timestamp on arrival** as well as keeping the venue's timestamp. See [Timestamps, Time Zones and Daylight Saving](https://learn.tradelabsai.com/programming/timestamps-and-time-zones/). - **Measure latency** from venue time to publish time. See [Exchange vs Receive Timestamps and Latency Measurement](https://learn.tradelabsai.com/programming/latency-measurement/). ## Build or buy Writing feed handlers for a few crypto exchanges is a manageable project. Covering many traditional exchanges with binary multicast feeds is a large engineering effort, which is why firms often buy normalised data from vendors or use open source libraries that already support many venues, such as CCXT for crypto REST and WebSocket APIs. ## Frequently asked questions ### What is a feed handler? Software that connects to a venue's market data feed, decodes its messages and converts them into a standard internal format for the rest of a trading system. ### Why is data normalisation needed? Each venue uses different symbols, units, number formats and timestamps; normalisation lets strategies treat data from all venues the same way. ### Should prices be stored as floats? For research floats are usually fine, but for order prices many systems use integers in tick units to avoid rounding errors. Next, learn how sequence numbers keep feeds reliable in [Sequence Numbers, Dropped Packets and Out-of-Order Messages](https://learn.tradelabsai.com/programming/sequence-numbers/). ## Continue learning - Next lesson: [Sequence Numbers, Dropped Packets and Out-of-Order Messages](https://learn.tradelabsai.com/programming/sequence-numbers/) - Previous lesson: [Order Book Feeds: Snapshots and Incremental Updates](https://learn.tradelabsai.com/programming/order-book-feeds/) - Related: [Order Book Feeds: Snapshots and Incremental Updates](https://learn.tradelabsai.com/programming/order-book-feeds/): How exchanges publish order book data as snapshots and incremental updates, and how to build and maintain an accurate local order book in code without errors. - Related: [WebSocket Market Data Streams](https://learn.tradelabsai.com/programming/websocket-market-data-streams/): How WebSocket streams deliver live trades, quotes and order book updates. Learn subscriptions, heartbeats, reconnecting safely and handling gaps in Python. - Related: [Sequence Numbers, Dropped Packets and Out-of-Order Messages](https://learn.tradelabsai.com/programming/sequence-numbers/): Sequence numbers let trading systems detect lost, duplicated or out of order messages. Learn how gap detection, recovery and duplicate handling work in practice. - Related: [Binary Protocols](https://learn.tradelabsai.com/infrastructure/binary-protocols/): Why exchanges use compact binary protocols for market data and orders. Learn how ITCH, OUCH and SBE work, how they compare with JSON and FIX, and decoding basics. - Related: [Message Queues](https://learn.tradelabsai.com/infrastructure/message-queues/): Message queues pass market data, signals and orders between trading components. Learn pub sub and queues, tools like Kafka, Redis and ZeroMQ, and design trade offs.