Ask three feeds who issued a bond and you can get three different answers. The market data vendor keys on a ticker, the filings source keys on a registrant name, and the alternative-data provider keys on whatever string the scraper found. Each is internally consistent. Stitched together, they are not. This is the entity resolution problem, and in finance it is rarely as small as it first looks.
Identifier sprawl
The first surprise is that there is no single identifier everyone agrees on. There are several, and they do not line up.
- LEI identifies a legal entity, but a company can hold many LEIs across subsidiaries, and one operating business can sit under several legal parents.
- CUSIP and ISIN identify a security, not the issuer. A firm with twenty bond lines and three share classes has dozens of these, all tracing back to one company you actually care about.
- Ticker is convenient and treacherous. It is exchange-scoped, it changes on rebranding, and it gets reused. A ticker that meant one company in 2014 can mean a completely different one now.
- Internal IDs from a prior system, an acquired desk, or a spreadsheet someone still maintains.
So security identifiers describe instruments, legal identifiers describe entities, and neither alone tells you that two rows are the same business. Issuer matching is the work of collapsing that sprawl into one answer.
Names make it worse. “Meta Platforms”, “Facebook, Inc.”, “FB” and “META” can all point at the same issuer, while “Delta” might be an airline, a faucet maker, or a fund, depending on the feed. Corporate actions then move the ground under you. Mergers fold two issuers into one. Spin-offs split one into two. A renamed entity keeps its CUSIPs but loses its ticker, and the filing trail switches registrant mid-stream.
Building the resolution layer
The fix is a dedicated layer in your financial data infrastructure whose only job is to decide what counts as one entity, and to record why. We build it around a golden record: a single canonical entity that every incoming identifier maps to.
The mapping is not a one-time join. It is a set of rules and a maintained crosswalk:
- Deterministic matching first, on the identifiers that are meant to be authoritative, with checks for the known failure modes like reused tickers and shared LEIs.
- Probabilistic matching for the rest, scoring name similarity, domicile, sector and security overlap, with a threshold below which a human reviews rather than the system guessing.
- Survivorship rules that decide, when two sources disagree on a field, which value wins. The filing might be authoritative for legal name, the market feed for the active ticker, and the registry for domicile. Those choices are written down, not improvised per query.
- Time-awareness, so the crosswalk knows that a ticker meant one issuer before a date and another after. Entity resolution that ignores point-in-time correctness will happily merge the pre-merger and post-merger companies, which is exactly the kind of leakage a backtest should never see.
Every resolved link carries lineage back to the source row that justified it, so an analyst or an auditor can see the chain rather than trust a black box.
The cost of getting it wrong
This is not housekeeping. Get entity resolution wrong and the error does not announce itself, it aggregates. An exposure report that treats a parent and its subsidiary as two names understates concentration, and you breach a limit without knowing. A backtest that silently merges a reused ticker pulls in returns from a company that did not exist yet, and the strategy looks better than it ever was.
The wrong answers here are confident ones. A resolution layer with a golden record, explicit survivorship and time-aware crosswalks is what keeps “the same company” actually the same, in the report and in the backtest, and not just in the demo.