The Stocks tab ranked 522 names at capture and marked 100 of them as outperforming the benchmark basket. The engine runs a full scan every six hours, so that shortlist changes overnight without anyone at your firm deciding it should. Somewhere between the ranking and an order there has to be a step where the firm's own constraints are applied, and on this board that step does not exist.
That is not a criticism of the module. A screening engine cannot know what your firm is restricted on, and it would be worse if it pretended to. What matters is that the absence is explicit in your workflow rather than assumed, because the last column on every scored row is an Action column containing a TRADE button, and the distance from a rank to a live order is one click.
The board has no state for a name you may not own
Walk the row from left to right. Asset, Type, Price, Mkt Cap, Vol 24h, Score, Conviction, Phase, then the return columns, then Action. There is nowhere for a suppression flag to live. A restricted name looks identical to an unrestricted one and sorts to exactly the same place, which means the restriction cannot be discovered by reading the board more carefully. It has to be applied from outside.
The toolbar carries controls that partially narrow the universe. There is an exchange selector reading All Exchanges at capture, a country selector reading All Countries, a search box, a Filters panel and a Templates control. Those are venue and universe filters. They are not entitlement filters, and treating them as though they were is the specific mistake that puts a restricted ticker in front of a portfolio manager at eight in the morning.
The practical shape of the control is therefore a reconciliation, run on a schedule, that takes the engine's output and the firm's lists as two inputs and produces a third artefact that is the only list anyone on the desk is permitted to read.
Three lists, three different suppressions
The lists get bundled into one word in conversation and they do not behave alike, so the reconciliation has to treat them separately or it will over-suppress in one direction and under-suppress in the other.
The restricted list is a hard block. The firm is in possession of something, or is engaged on something, and the name cannot be traded in any direction by anyone. The reconciliation output for a restricted hit is removal, not a warning, and the removal happens before the list reaches the desk. A portfolio manager who can see that a restricted name scored 93 this morning has already been handed information that is awkward to have.
The watch list is an escalation, not a block. The name may be traded with pre-clearance, or in limited size, or only in one direction. The reconciliation output is a flag and a routing rule, and the name stays on the list with its constraint attached. Removing watch list names entirely is the common over-correction and it silently biases the sleeve, because watch lists are not randomly distributed across sectors.
Personal trading conflicts are the third and they are the one that generates the most friction for the least frequency. A name a covered person holds is not restricted for the fund, but the sequencing rules almost certainly apply, and the reconciliation is where that is caught rather than at the point of execution. Run it against the personal holdings register on the same schedule as the other two, not on request.
Run it before the ranking is read, not after
Order of operations is the whole control. If the reconciliation runs after a manager has read the board and formed a view, you are relying on someone accepting that their best idea of the morning has been deleted. That is a behavioural control, which is to say it is not a control.
Run it against the raw engine output on a fixed cadence tied to the scan schedule, and publish the reconciled list as the desk artefact. The unreconciled board is then an operations input rather than a research surface, and access to it can be scoped accordingly. The engine's six hour cadence is convenient here because it gives you a natural cycle to attach the job to rather than an arbitrary one you have to defend.
Two mechanical details are worth setting up once. First, match on a stable identifier rather than on the displayed symbol. The board carries symbols like 0GP7 and 0GQU alongside conventional tickers, so a string match against a restricted list keyed on US tickers will miss the rows that most need catching. Second, run the reconciliation on the full ranked universe rather than only the top decile, because a name that ranks 60th today ranks 6th next week and you want the mapping already resolved rather than resolved under time pressure.
Logging a suppression so attribution survives
The reconciliation deletes names, and deleted names leave no trace unless you deliberately keep one. Six months later the strategy's performance is discussed in a review, and the only version of the shortlist anyone can produce is the reconciled one. The strategy's record and the engine's record have quietly become the same document, which means you can no longer answer the one question that actually matters, which is whether your constraints cost you anything.
The fix is a suppression log written at the moment of suppression, holding the date, the identifier, the rank and score at suppression, which list caught it, the direction of the constraint, and the name that took its slot in the sleeve. That is six fields and it can be a row appended by the same job that does the reconciling, so it costs nothing to maintain and it is contemporaneous, which is the property that makes it worth anything in a review.
Track the suppressed names forward as a shadow book at the weight they would have carried. Do not report that shadow book as performance and do not let it near a client document, because it is a portfolio that could not have been held. Its purpose is diagnostic: it converts the cost of compliance from an argument into a number, and a number can be discussed with a board.
When the suppressed name is the one that worked
It will happen, and the review meeting where it happens is the reason the log exists. A name the firm was restricted on ran forty percent while the substitute did nothing, and someone asks why the fund did not own it.
With a suppression log the answer takes thirty seconds. The name entered the shortlist on a given date at a given score, it was caught by the restricted list because of a specific mandate, it was replaced by a specific substitute chosen by the documented next-in-rank rule, and here is the year to date cost of all such suppressions across the sleeve. That is a process working correctly and being able to prove it.
Without the log the answer is a reconstruction, assembled after the fact from whatever anyone remembers, and reconstructions have a tendency to look like excuses regardless of how accurate they are. The asymmetry is worth internalising. A contemporaneous record of a decision you made for a good reason is a defence. The same decision described from memory is a liability, and the difference between the two is a six field row appended by a job that already runs.
One last item belongs in the same log. Record the substitution rule itself and the date it was last changed. Next in rank is defensible. Next in rank unless the manager preferred something else is not a rule, it is discretion with a rule's name on it, and the review will find that out faster than you expect.