Bitcoin is BTC on most exchanges, but it is XBT on some, and the trading pairs are formatted differently everywhere. BTCUSDT, BTC/USDT, BTC-USDT, tBTCUSD. These naming inconsistencies seem trivial but they are the first barrier to any cross-platform analysis. A system that compares prices across exchanges needs a mapping layer that translates every platform naming convention into a canonical format.
The challenge gets harder with less established assets. A token might be listed under different contract addresses on different chains, with different ticker symbols on different exchanges. Some exchanges list wrapped versions. Others list native versions. A token called ABC on one exchange might be a completely different project than ABC on another. Reliable cross-platform matching requires a combination of contract address verification, symbol matching, and manual curation.
Timestamp synchronization is another fundamental challenge. Exchanges report timestamps in different formats and with different levels of precision. Some report in milliseconds since epoch, others in ISO 8601 format. Some use UTC, others use local time. And the latency between when a trade occurs and when it is reported through the API varies across exchanges. Aligning data to a common time reference is essential for any cross-platform analysis like arbitrage detection or volume comparison.
Price normalization goes beyond just currency conversion. Different exchanges have different fee structures that affect the effective price. Maker-taker fee models mean the actual cost of a trade depends on whether you are adding or removing liquidity. A price that looks like an arbitrage opportunity might disappear entirely once you account for fees on both sides of the trade.
Order book depth comparison is particularly tricky. Different exchanges report order books at different levels of granularity. Some provide the full order book with individual orders. Others aggregate into price levels. The number of levels provided varies. Comparing liquidity across platforms requires normalizing these different representations into a comparable format, typically aggregated by price level with total volume at each level.
Cross-platform matching for prediction markets adds another dimension. The same question might be listed on Polymarket, Kalshi, and other platforms with slightly different wording, different expiration dates, or different resolution criteria. Matching these requires semantic understanding, not just string matching. A question about central bank rate changes on one platform could be worded very differently on another, but a naive matching algorithm would not recognize them as equivalent.
Data quality scores help manage the reliability gap across platforms. A matching system might assign higher confidence to data from exchanges with better track records for accurate reporting and lower confidence to data from exchanges known for delayed or unreliable feeds. These quality scores can weight the matched data, so that analysis is not disproportionately influenced by low-quality sources.
Deduplication is necessary when the same trade appears in multiple data sources. Aggregators that pull from both direct exchange APIs and third-party data providers can end up counting the same trade twice. Deduplication typically uses a combination of timestamp, price, volume, and trade ID to identify duplicates, but imprecise timestamps and different granularity levels make this harder than it sounds.
The systems that do this well tend to be built iteratively. You start with symbol mapping for major assets, add exchange-specific adapters one by one, build quality monitoring to catch data issues, and slowly expand coverage. There is no shortcut to handling the long tail of edge cases that emerge when you try to create a unified view of a fragmented market.