Normalising Market Data Across Venues
Two venues describe the same idea with different shapes. A documented intermediate representation is the difference between a comparison and a guess.
Comparison is arithmetic. Normalisation is judgement. The judgement is where cross-venue systems succeed or quietly fail.
What differs between venues
Price scale. Cents versus decimals versus basis points.
Outcome naming. Yes and No, or named outcomes, or numbered ones.
Direction. Some markets are phrased as "above", their counterparts as "below". These are complements and comparing them directly produces a gap of roughly a hundred cents. Yes and No shares.
Threshold convention. Strict versus inclusive. Only matters on an exact tie, and decisive then.
Structure. A binary here, one leg of a multi-outcome set there. Multi-outcome markets.
Time. Different zones, different conventions for what a "daily close" means.
Status vocabulary. Open, closed, settled, resolved, finalised — with different meanings for similar words.
The intermediate representation
Do not compare venue A's record to venue B's record. Convert both into one internal form, then compare that form to itself.
A reasonable form carries: a canonical subject, the publisher and series where applicable, a numeric threshold, a direction, a tie rule, an observation timestamp in UTC, an outcome structure, a price in integer cents, sizes, and an observation time.
Everything venue-specific stops at the boundary. Downstream code sees one shape.
Write it as tested code
Each venue gets an adapter. Each adapter has test cases built from real records, including the awkward ones: the market phrased backwards, the tie at the strike, the multi-outcome set with an "other" leg.
The reason to insist on tests here rather than elsewhere is that normalisation errors are silent. A direction flip does not throw an exception; it produces a confident, well-formatted, completely wrong comparison. Cross-market mistakes.
Keep the original
Store the raw record alongside the normalised one. When something looks wrong six months later, the question is always whether the venue changed or your adapter did, and you cannot answer it without the original.
Refuse rather than guess
Where a record does not fit the representation — an unusual structure, an unparseable threshold, a question whose subject cannot be canonicalised — mark it unmatched and move on.
A pipeline that always produces an answer will produce wrong answers. One that declines is more useful, because its output can be trusted. This is why a well-built gaps table is short. Matching markets across venues.
Version the rules
Normalisation logic changes as you learn. Record which version produced each normalised row, so that a change in your own code is distinguishable from a change in the world.
Without this, an improvement to the matcher looks identical to a market repricing, and any historical analysis you run across the change is quietly broken. Backtesting honestly.
Next
Alerting on price moves without generating noise.
Educational content only. Nothing here is financial advice, a solicitation, or an offer to trade. Prediction markets can move against you and a position can lose its entire value. Where this guide describes a difference between venues it describes a theoretical cross-market edge in observed prices, which is not a profit: fees, spreads, capital lockup, transfer time and differing settlement rules all come out of it first.
Keep reading
Data and Automation · 3 min readDetecting Stale Data Before It Reaches AnyoneA pipeline that keeps running while its source stops updating is worse than one that fails loudly. How to measure freshness and what to do when it slips.
Data and Automation · 3 min readAlerting on Price Moves Without Generating NoiseAn alert that fires constantly is ignored, which makes it worse than no alert. How to define a threshold that reflects significance rather than movement.
Data and Automation · 3 min readRate Limits, Polling, and Not Being a NuisanceA polling schedule that matches where the information actually is will use a fraction of the requests and produce better data than polling everything.
Prices and Probability · 3 min readPercentage Points vs Percent, and Why It MattersA move from 2% to 3% is one percentage point and a fifty percent increase. Confusing the two produces headlines that are technically true and completely useless.