How to Track Supply-Chain Exposure After a Company Delists
August 28, 2026
Altsets
Research by Altsets Research
Keep company identity, historical security symbols, relationship dates, and current tradability separate so delisted or private counterparties do not disappear from supply-chain research.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- Toyota Industries code 6201 appears in the supplied Tesla network even though its shares were delisted on June 1, 2026 after a going-private transaction.
- A durable supply-chain model needs stable company identity plus separate relationship and security timelines so delisting does not create survivorship bias.
A company can disappear from the stock exchange without disappearing from the supply chain. That creates a data problem for investors who use tickers as company identifiers. The supplied Tesla network contains a structural upstream node labeled 6201, the former securities code of Toyota Industries.
Toyota Industries completed a going-private transaction and its shares were delisted from the Tokyo and Nagoya stock exchanges on June 1, 2026. The economic entity can still exist after the ticker stops trading. A historical supply-chain system therefore has to track the company separately from its security symbol.
Tickers identify securities, not permanent companies
A ticker or exchange code can change because of delisting, acquisition, merger, going-private transaction, exchange transfer, share-class change, corporate reorganization, and symbol change. If a relationship database uses the ticker as the permanent identity, the network can break when one of those events occurs. Historical research becomes especially vulnerable. A relationship observed under code 6201 should not vanish from history merely because Toyota Industries later became private.
The relationship and the security answer different questions
The supply-chain relationship asks whether Toyota Industries is connected to Tesla in the mapped network. The stock code asks whether an investor can currently trade Toyota Industries shares under that identifier. Those questions can have different answers. After June 1, 2026:
- the former public security was delisted;
- the company entity continued;
- historical relationships still need to resolve to the same company;
- current portfolio screens should know that the security is no longer publicly tradable.
This separation is important for both human research and backtests.
Why this matters for historical analysis
Suppose an investor reconstructs a Tesla supplier network from 2025. Toyota Industries was still publicly listed at that date. A point-in-time backtest may legitimately include the security.
Now suppose the same code is resolved using today's security master. If the entity has simply been deleted because it delisted, the historical network becomes incomplete. That is survivorship bias. The correct system preserves the old security mapping while keeping the company entity alive.
First-seen and last-seen relationship fields help
Altsets' relationship-serving layer tracks first and last observed relationship periods alongside supplier and customer identities. Those fields solve a different problem from security status. They help answer whether the commercial edge itself was observed during the test period.
A robust historical model therefore needs at least two timelines: the relationship timeline and the security/listing timeline. A relationship can persist across a delisting. A security can remain listed after a particular relationship ends. The two should not be conflated.
Going private does not make a counterparty irrelevant
A private supplier can still be economically critical to a public customer. For a Tesla investor, a supplier's public listing status matters for whether the supplier can be traded directly. It does not determine whether a disruption at that supplier can affect Tesla. This is why supply-chain risk screens should include private and formerly public entities rather than only current stock tickers.
Entity resolution matters when names change too
Delisting is only one example. The same logic applies when a company: changes legal name, merges into another entity, spins out a division, changes ticker, maintains multiple listings, and has local-language and English names. A stable entity key should resolve those identities before any portfolio or network comparison. Otherwise the same company can appear as multiple nodes or disappear from historical snapshots.
A repeatable delisting-safe workflow
- Resolve the company to a stable entity identifier.
- Store ticker and exchange code as time-varying security attributes.
- Preserve historical symbol mappings.
- Track first and last observed relationship periods separately.
- Mark current tradability independently from economic relevance.
- Keep delisted and private counterparties in risk networks.
- Exclude them from a tradable basket only when the strategy requires listed securities.
- Reconstruct historical portfolios using the security status that existed at the test date.
Toyota Industries is a clean example because code 6201 is visible in the supplied Tesla network while the company is no longer publicly listed under that security.
The point-in-time backtesting guide explains the broader anti-leakage framework. The Tesla supplier-network analysis explains the role of Toyota Industries within the visible supplier-function map.
For entity and relationship methodology, read the Altsets supply-chain data methodology. Browse Supply-Chain Data Use Cases for other historical and portfolio workflows.