Delisting risk gets treated as an operational nuisance until the day it is a liquidation on a deadline you did not set. Then it becomes the item at the top of the review, and the questions are always the same three. Why was the position that concentrated on one venue. When did we know. Who decided to wait.
All three have good answers, but only if the answers were written before the announcement. A policy that names this event converts a scramble into an execution, and the drafting is not hard. What makes it hard is that nobody writes the clause until they have needed it once.
What a delisting row actually is
Read the delistings stream carefully before drafting anything, because the policy language has to match the event as it is reported rather than as it is imagined.
At capture the stream showed 100 of 100 rows, every visible one from Binance, each typed ANNOUNCEMENTS_DELISTING and each carrying a pair: SYS/USDT, PHB/USDT, MLN/USDT, FARM/USDT, ATA/USDT, AI/USDT, AEUR/USDT, XLM/USDT. Dates clustered on 05/22/26 and 05/27/26.
Two things follow immediately. The event is a market being withdrawn, not an asset ceasing to exist. XLM/USDT appearing in a delisting stream means one pair on one venue, and a policy written as though a delisting kills the asset will produce absurd forced sales. The unit of the event is the pair, and the policy has to be written at that granularity.
The second is about coverage. On the visible rows the MCap, Liquidity, Chain and Conf% columns were all empty. The feed is telling you an announcement happened. It is not sizing your exposure, valuing the position, or telling you where else the asset trades. Every one of those is your system's job, and the policy should say so rather than implying a tool does it.
The concentration clause, and how to make it bind
The clause that actually prevents the problem is the one about concentration, and it should be stated as a hard cap with a measurable denominator.
Draft it in terms of tradable venue coverage rather than venue count. A position whose entire tradable liquidity sits on one venue is a different exposure from one that trades on four, and the number of venues where a pair merely exists is not the same as the number where you could exit at size. So the cap is on exposure to assets for which fewer than a stated number of eligible venues carry meaningful depth, and eligible has to point at your venue schedule rather than at the whole market.
Set the cap so it binds before the event, which means deriving it from exit arithmetic rather than picking a round number. If the policy requires an exit within a stated number of trading days, and participation is capped at a stated share of daily volume, then the maximum position for any asset is those two multiplied by its daily volume. That formula, rather than a fixed percentage, is what belongs in the document, because it adapts as liquidity changes and it forces someone to look up a volume figure before sizing.
Defining the trigger so it fires on a date
Delistings arrive as a sequence, and a policy that does not say which step starts the clock will produce inconsistent behaviour across the desk.
There are usually at least four candidate dates. The announcement. Suspension of deposits. Cessation of trading. Final withdrawal of the asset from the venue. Each one has a different meaning for you, and only the first is what a listings feed reports, since the delisting rows carry an announcement type and a date.
Draft the trigger on the announcement, because it is the earliest and the most reliably observable, and define the required action relative to it in trading days. Then add the deposit suspension as a secondary trigger with a stricter action, because deposit suspension is the point at which moving inventory onto the venue to sell it stops being possible, which is the operational constraint that catches desks out.
Say explicitly what happens when the asset trades elsewhere. In most cases the correct response to a single-venue delisting is not liquidation, it is migration of the exit route. The policy should require the desk to identify an alternative eligible venue and document the depth there within a stated window, and only mandate reduction if that identification fails.
The action window and the override
An action window turns a trigger into behaviour. Without one, the trigger produces an email.
Write it as a default with a deadline. Within some number of trading days of the announcement, the position is either migrated to a documented alternative venue or reduced to a stated residual. The default when nothing is decided must be the conservative branch, because the failure mode here is not bad decisions, it is unmade ones, and the position sits until the window closes on its own.
The override needs three properties and they are all procedural. A named role, not a committee, because committees do not convene inside an action window. A written reason recorded at the time, not reconstructed afterwards. And an expiry, so the override does not silently become the new policy for that position.
One additional clause is worth including and is usually omitted: a cap on how many simultaneous overrides may be outstanding. Delistings cluster, as the capture dates show, and a desk that can override one comfortably can override eight only by ceasing to have a policy.
What the review will ask, and the record that answers it
Write the policy backwards from the review. The record should be able to answer, without anybody reconstructing anything, when the announcement was observed, what the exposure was at that moment, which branch was taken, and who decided.
That implies a specific operational requirement, which is that the feed observation is timestamped and stored rather than read. A delisting row read on a screen and acted on leaves no evidence of when you knew. The same row captured into your own record, with the exposure snapshot attached, answers the hardest question in the review before it is asked.
It also implies that the exposure snapshot has to be taken at trigger time, not at exit time. The number that matters for governance is what you held when the announcement landed, because everything after that is the story of what you did about it. A record that only contains the final trade is a record of the outcome with the decision removed, and that is precisely the shape of file that turns a defensible forced exit into an uncomfortable meeting.