A ranking engine returns rows. A portfolio holds companies. Those are not the same object, and the gap between them is where a sleeve quietly ends up with twice the exposure its weight file says it has.
The mechanism is dull and entirely mechanical. A company with two listings generates two rows. Both rows carry the same underlying economics, so if the company is strong, both rows score well and both rows rank. A rank-ordered selection takes the top fifteen rows and hands them to a weighting routine, which assigns each row its share of the sleeve. Two rows, two allocations, one company. The weight file balances, every position is inside its individual limit, and the concentration risk is real and undocumented.
The board is keyed on symbols and the symbols do not cooperate
Look at what identifies a row on the Stocks tab. There is an Asset column carrying a symbol badge and a truncated company name, and a Type column reading Stocks. That is the identity information available on the row. There is no exchange column, no ISIN, no internal permanent identifier, and no field anywhere that would let you tell two listings of one company apart or recognise them as the same thing.
The symbols themselves make the problem concrete. On a tab labelled US Stocks the board carried Medivir AB as 0GP7 and Active Biotech AB as 0GQU, both Swedish companies with vendor-style codes rather than US ticker symbols. The same pattern appears on the all-assets board attached to fund rows as 0V1N and 0KQK. Tribhovandas Bhimji Zaveri Limited, an Indian company, sat there quoted at 286.20 dollars.
None of those rows is wrong. Each is a real quote for a real instrument. What none of them tells you is whether the same issuer is also present on the board under a conventional ticker, and a string match on the symbol will never find out, because 0GP7 and a US ticker for the same company share no characters at all.
Four shapes the duplicate takes
They do not all behave alike, and the collapsing rule has to be different for each, so it is worth separating them before writing any code.
The first is the ordinary cross-listing: one issuer, two exchanges, two quotes in two currencies, sometimes with a ratio between them. The economic exposure is identical up to the currency leg, so these must collapse to one line and the currency exposure has to be booked separately rather than netted away.
The second is the depositary receipt, where a US line represents a fixed number of home shares. Same issuer, same economics, different instrument, different liquidity profile entirely. Collapse for exposure purposes, keep separate for capacity purposes, because the ADV of the receipt has nothing to do with the ADV of the home line.
The third is the dual share class, and this one is a genuine judgement call rather than a data problem. Two classes of the same issuer are the same economic exposure with different voting rights and often materially different liquidity and price. They should collapse for issuer concentration and stay separate for everything else.
The fourth is the one this platform makes visible in a way most do not. The crypto tab at capture carried MSTRON, described as MicroStrategy in an Ondo tokenized form, and BMNRON for BitMine Immersion Technologies in the same form. Those are equity exposures appearing under a crypto asset type on a different tab of the same engine. A firm that runs the crypto ranking and the equity ranking as two separate processes, which is the normal arrangement, will not see that the same issuer entered both.
The arithmetic of the error
Work it through on a fifteen name equal weighted sleeve at 6.67 percent per row. One issuer appearing twice produces a 13.3 percent issuer position against a stated 6.67 percent limit. That is a doubling, and it is not visible in any single line of the weight file.
The damage is worse than the headline number because it is selective. Duplicates are not randomly distributed. They cluster in issuers large enough or international enough to maintain multiple listings, which means the doubling lands disproportionately on a particular size and domicile profile. A sleeve with three duplicated issuers out of fifteen rows is not holding fifteen names with three small errors. It is holding twelve names with a systematic tilt toward multi-listed companies, and the tilt was chosen by the data pipeline rather than by anyone in the investment process.
Risk reporting will not catch it if the risk system is fed the same symbol keyed file. Factor exposures computed from that file will be wrong in the same direction, so the model will confirm the portfolio is fine. The error is upstream of every downstream check, which is exactly the class of error worth spending real engineering time on.
Collapsing before weights, not after
The step belongs between the ranked output and the weighting routine, and the sequence is fixed: rank, map, collapse, then weight. Reversing the last two and normalising afterwards produces a sleeve whose weights no longer correspond to the ranking that generated them.
Mapping means resolving every row to a permanent issuer identifier from your own security master rather than from the screen. Symbol, name and exchange are display fields and they change. An issuer level identifier is the thing you actually want to constrain, sitting above the instrument level identifier that you trade on. If your master does not already carry that hierarchy, this is the case for building it, because nothing else in this control works without it.
Collapsing means choosing which of the duplicate rows survives, and the rule should be written down once rather than decided per case. The defensible default is to keep the line with the greatest tradeable liquidity in your own currency and account structure, and to inherit the best rank achieved by any of the collapsed rows. Inheriting the best rank rather than the surviving row's own rank matters: the home line may have generated the signal while the receipt is the line you can trade, and dropping the home line's rank throws away the reason the issuer was selected.
Then log every collapse. Date, the rows that were merged, the identifier they resolved to, which line survived and why. That log is what lets you answer the question of whether the mapping is working, and it is also what turns a silent data behaviour into a documented investment control, which is the form it needs to be in when someone asks.
The exceptions that should not collapse
Two cases will tempt the rule and should be excluded from it explicitly, because a mapping routine that over-collapses is harder to detect than one that under-collapses.
Hedged and unhedged share classes of the same fund are the first. They resolve to the same underlying but they are deliberately different exposures, and merging them deletes the currency decision that is the entire point of holding one rather than the other. The all-assets board carried a fund row described as a Bloomberg commodity index hedged into euros, which is precisely the shape that a naive name match will merge into its unhedged sibling.
The tokenized equity lines are the second, and here the answer depends on what the control is for. For issuer concentration they are the same exposure as the underlying company and must collapse. For counterparty and settlement risk they are emphatically not, because holding a tokenized representation introduces an issuer of the token in addition to the issuer of the equity. A single collapse rule cannot serve both purposes. Run the concentration check on the collapsed view and the counterparty check on the uncollapsed one, and be explicit in the documentation about which view each report was built from.