A listing feed hands your desk a stream of events that all look like the same kind of object. A symbol, a venue, a date. They are not the same kind of object, and the difference between them is not a data quality problem you can fix upstream. It is a policy question your firm has either answered in writing or is answering implicitly, differently, on every desk, every day.
The symptom is easy to spot in a post-trade review. Two PMs saw the same row. One treated it as an investable listing event and put on size. The other treated it as noise and did nothing. Both can defend the individual decision. Neither can point to the document that says which of them was following process, because there is no document, and the feed does not contain one.
What an eligibility policy is actually protecting you from
The naive framing is that a venue schedule protects you from trading bad listings. That is a small part of it. The larger part is dispersion.
If venue eligibility is a judgement call made per event, then your listing strategy has no measurable capacity, no attributable track record, and no reproducible signal set. You cannot backtest it because you cannot state the entry rule. You cannot size it because you do not know how many events per quarter qualify. You cannot explain a drawdown, because when a position goes wrong the honest answer is that somebody thought that one counted, and that answer does not survive an allocator meeting.
The second thing it protects is the delisting side, which is where the absence of a policy costs real money rather than credibility. A venue that is not eligible on the way in should not generate a forced action on the way out, and if your risk process reacts to delisting announcements from venues you never traded the listing on, you have built an asymmetric rule that only ever tells you to sell.
The screenshot shows why the policy has to be written per stream rather than per module. Launches, listings and delistings sit next to each other in the same suite, and the temptation is to write one eligibility rule for the whole thing. A token launch is an on-chain deployment event with no venue at all in the exchange sense. A listing is a venue announcement about an asset that may already exist. Those need separate schedules.
Three tiers, and what each tier authorises
I would not try to build a numeric venue score. Scores invite arguing about the weights. A tier schedule invites arguing about the assignment, which is the argument you actually want to have because it resolves in a meeting and gets written down.
Tier one is a venue where a listing announcement is itself the investable event. The announcement authorises a position under the strategy's standard sizing, without additional sign-off, subject to the usual liquidity and capacity constraints. The suite covers announcements across Binance, Coinbase, Kraken, OKX, Bybit and other venues, and most desks will find their tier one is a short list drawn from the largest of those.
Tier two is a venue where a listing is corroborating evidence but not a trigger. A tier two announcement can promote an asset already on your watchlist, or add weight to a thesis, but on its own it authorises research rather than risk. Practically, this is where most of the exchange universe lands.
Tier three is monitored and not actionable. You ingest it, you keep it for research, you never size off it. The reason to name tier three explicitly rather than simply excluding those venues is that a documented exclusion is auditable and a silent one is not. When somebody asks in six months why the desk missed an event, the answer should be a line in a schedule, not a shrug.
The tests that put a venue in a tier
Four questions decide the assignment, and all four are answerable before you see any particular event, which is the point.
- Does the venue serve a client base your fund can actually trade alongside? A listing that unlocks flow you are structurally unable to participate in is an interesting data point about someone else's market.
- Does the venue announce before it lists, and is that announcement machine-readable and time-stamped in a way you can archive? A venue that lists without a prior announcement generates no tradable window, only a price move you observe after the fact.
- Is the announcement specific enough to resolve to an instrument? A venue that announces a symbol without a chain or a contract reference is generating an entity-resolution problem rather than a signal, and if the resolution has to happen manually then the venue cannot support a systematic rule regardless of its size.
- Does the venue's own behaviour make the announcement conditional? Some announcements are firm, some are subject to conditions the venue reserves the right to change, and those two things should not carry the same tier.
Notice that none of these tests reference historical returns. That is deliberate. If you tier venues by realised performance you will overfit to a handful of events, and you will also have built a policy that changes every time the sample changes. Tier on structural properties, measure returns separately, and treat a persistent gap between the two as a reason to revisit the schedule at the scheduled review rather than mid-quarter.
Writing it down so it survives contact with a live event
The schedule needs to be a table with a version number, an effective date, and a named owner. Venue, stream it applies to, tier, and the date of the last review. If it lives in a chat thread it is not a policy.
It also needs an exceptions path, because a rigid schedule with no exceptions path does not produce discipline. It produces quiet rule-breaking. The path should be short and expensive: an exception requires a named approver, a written reason, and an entry in a log that gets read at the next review. Most desks find that the cost of writing the reason kills nine out of ten exceptions on its own, and the tenth is usually the one that should have been a schedule change.
Set the review cadence to something regular and unrelated to market conditions. Quarterly is defensible. Reviewing after a venue does something dramatic is how you end up with a schedule that encodes last quarter's surprises. The review should look at three things: venues that generated events you did not trade, venues whose events you traded under exception, and venues where the announcement-to-listing behaviour changed since the last review.
The compliance surface most schedules forget
A venue eligibility policy touches at least three other documents, and if you write it in isolation it will contradict them.
The first is your custody and counterparty list. A venue can be tier one for signal purposes and completely unavailable for execution, which is a legitimate configuration but only if it is stated. The schedule should carry a separate column for whether the venue is an execution venue, an information venue, or both, because conflating those two is how a PM ends up with an authorised trade and no route to put it on.
The second is the restricted list. Listing events are exactly the situation where an asset arrives with no prior internal history, so the check that an asset is not restricted has to be part of the entry workflow rather than something the analyst is expected to remember during a live window.
The third is your marketing and reporting language. If the schedule says tier one authorises standard sizing without additional sign-off, then any material describing the strategy has to be consistent with that, and any exception that was granted needs to be visible to whoever writes the quarterly letter. The point of doing this work is that when a listing position goes wrong, and one of them will, the review is about the position rather than about whether anyone was allowed to have it.