How to link private companies and brands to a listed parent company

A posting on a brand's job board, or a technology on the website of a private subsidiary, belongs in a portfolio to a listed parent company. To link those private companies and brands to the parent in a dataset you need three things: a record that states who owns whom, a key that carries the link on every row, and a roll-up that counts each observation once. This guide compares the public records of ownership, sets out a method for building a dated bridge from them, and works one roll-up of brand-level observations to the parent's security, with the fan-out that doubles a total when nobody tests for it.

How do you link brands and private companies to a listed parent in a dataset?

Give every unit you observe, a brand's website or a private company, one stable company key. Find its owner in a dated public record, and store the pair in a bridge table with the listed parent's security identifier, the evidence and the dates the link holds. Then aggregate to the parent first and join to the security second.

The link crosses four levels, and each level has a different kind of key.

• A brand is a name a company sells under. It has a website and often a job board of its own, and no legal existence.
• A subsidiary is a legal entity that another entity owns or controls. When it is a private company it has no listed security of its own.
• The ultimate parent is the legal entity at the top of the chain. Here it is the issuer of a listed security.
• The security is what a portfolio holds, and the level an observation has to reach.

Web data is observed at the first level and wanted at the last. The entry on corporate hierarchy defines the terms, and the guide to the identifiers that make company data joinable says which key names which level. This page covers the links between the levels: where each one is recorded, how to store it and how to add up across it.

Company ownership hierarchy data for a listed parent and its brands: SEC subsidiary lists, GLEIF and OpenCorporates

Three public sources each hold part of a company ownership hierarchy. An SEC registrant files a list of its subsidiaries with its annual report. GLEIF publishes the direct and ultimate parent each legal entity with an LEI reports. OpenCorporates maintains relationship records keyed by jurisdiction and company number. Entity resolution ties each brand and private company to them.

The records define a parent in three different ways, and the difference decides what a roll-up contains.

The SEC's rule on exhibits asks a registrant to list all its subsidiaries, with the jurisdiction of each and the names under which they do business. It allows names to be omitted when the unnamed subsidiaries, considered together as a single subsidiary, would not be a significant subsidiary, so a small subsidiary can be absent from the list.

In the Global LEI System a legal entity reports its direct and its ultimate accounting consolidating parent. The relationship record format describes the child as an entity whose accounts are fully consolidated by the parent, and it has a field for the period of the relationship. An entity can report an exception in place of a parent, and the exceptions format lists the reasons in use: NO_LEI, NATURAL_PERSONS, NON_CONSOLIDATING, NO_KNOWN_PERSON and NON_PUBLIC. Read the exceptions beside the relationships, because a missing parent with a stated reason is information and a missing parent with none is a gap.

UK guidance on people with significant control names holding more than 25% of a company's shares or voting rights among the conditions of control, and section 790C of the Companies Act 2006 defines the relevant legal entity that meets such a condition. A stake of 30% can therefore show as control in one record and as no parent in another. Choose the definition your question needs, which for the activity of a group is usually consolidation, and record which one each link rests on.

OpenCorporates maintains four types of relationship record: control statement, subsidiary, branch and share parcel. Each side is identified by a jurisdiction code and a company number, and the start and end dates are its best estimates, each with a type of at, before or after. Its knowledge base states that the subsidiary relationships are derived from the SEC's archives and the control statements primarily from the UK dataset of people with significant control.

A brand needs one more record, because it is a name and not an entity. The USPTO's status system shows the current owner of a trademark, and a transfer of ownership is recorded through its Assignment Center. The names under which a subsidiary does business, in the SEC exhibit, are the other filed route from a trading name to an entity. Wikidata has properties for a parent organisation or unit and for an owner. Treat a statement there as a lead to confirm in a filed record.

The last step, from the parent to its security, has a public record too. GLEIF's daily ISIN-to-LEI relationship files pair an ISIN with the LEI of its issuer, and they currently include new ISINs issued by the numbering agencies that have joined the programme. The comparison of ISIN, LEI and FIGI covers the identifiers themselves.

A methodology for linking subsidiaries and brands to an ultimate parent company in a database

A sound methodology has six steps. Key every unit you observe, resolve it to a legal entity, find that entity's direct and ultimate parent in a filed record, attach the ultimate parent's security, store each link with its basis, source and dates, and roll up in two stages. Every step leaves a column you can audit.

1. Key the unit you observe. Give each website, job board or brand name one stable company key. A normalised domain is the usual way in, as the entry on domain matching describes.
2. Resolve it to a legal entity. Match a brand to the owner of its mark, or to a name under which a subsidiary does business. Try identifiers first and an exact normalised name with its jurisdiction last, and keep the basis of every match. This step is entity resolution, so test it on a sample you have checked by hand.
3. Find the parent, direct and ultimate. Walk the filed records upward until an entity has no parent, and store both the next entity up and the one at the top. Where the parent is reported as an exception, stop and keep the reason.
4. Attach the security. Give the ultimate parent the identifier your security master is keyed on. Where the issuer has several share classes, link to the issuer and let each security inherit the result.
5. Source and date every link. Record the document, its date and the days between which the link holds. This year's annual report is evidence for this year, and applying it to the years before an acquisition is look-ahead bias.
6. Roll up in two stages. Aggregate observations to the parent, then join the result to one row for each security.

The bridge table that comes out of the six steps has the columns below.

Give the listed company a row of its own with the relation self, so that one join carries the parent and its children alike. Keep a private company with no listed parent in the table, with the parent empty. An unmapped unit that stays visible is a coverage figure, and one that is dropped is a bias nobody can see.

What a brand or subsidiary carries in Fokals data

The Fokals company index holds listed companies worldwide, the brands they own and verified private companies, and each company has one stable company ID. A listed company carries its ticker, MIC, ISIN, LEI and share-class FIGI, and its SEC CIK where it has one. A brand or subsidiary carries the identifiers of its listed parent, so a posting on a brand's job board or a technology on its website arrives with the parent's ISIN on the same row.

Technology Stack (company_technologies) has one row for each company website and technology. The listed securities table (listed_securities) has one row for each equity listing, with the company the listing belongs to. The query below pairs every brand or subsidiary in Technology Stack with its listed parent, by keeping the rows whose company_id is not that of the company the listing belongs to.

select distinct
  t.company_id as child_company_id,
  t.company    as child,
  t.domain,
  l.company_id as parent_company_id,
  l.company    as parent,
  t.isin,
  t.lei
from company_technologies t
join listed_securities l
  on l.isin = t.isin
where l.company_id is not null
  and l.company_id <> t.company_id;

A security that trades on several venues has several rows in listed_securities, which is why the query selects distinct pairs. The result is the first version of your bridge, with the vendor identifier as its basis: each pair is a row to which a filed record and its dates attach. The same identifiers are on every dataset that names a company, from Hiring Activity to Company News, and the data dictionary defines each column. A verified private company that stands alone is keyed by its company ID and its website, and the coverage page describes the companies the index holds.

Worked example: rolling brand observations up to the parent's security

Acme Robotics is an invented company, and every figure in this example is illustrative.

Assumptions:

• Acme Robotics is listed, with one share class and one ISIN. Its shares trade on two venues, so your security master holds two listing rows for that ISIN, one of them marked as the primary listing.
• It sells under two brands, Acme Home and Acme Marine. Each has a website and a job board of its own, and each is a company with its own company ID.
• Acme Marine joined the group on the day Acme Robotics completed its purchase, a date taken from the parent's filing. Your bridge holds that day as the start of the link, and the links of Acme Robotics and Acme Home hold on both days.
• The measure is open_postings from Hiring Activity (company_hiring_daily), on two closed days: one before the completion date and one after it.

On the earlier day the group is Acme Robotics and Acme Home: 46 + 15 = 61. The 9 postings of Acme Marine belong to no security you hold on that day. On the later day the group is all three: 44 + 17 + 11 = 72. The listed entity alone has 46 and 44.

Two shortcuts give other figures, and each looks plausible on its own.

The query below takes neither shortcut. Here parent_link is your bridge and security_master is your own table of securities.

with group_day as (
  -- stage 1: observations to the parent, through the dated bridge
  select b.parent_isin, h.day, sum(h.open_postings) as open_postings
  from company_hiring_daily h
  join parent_link b
    on  b.child_company_id = h.company_id
    and h.day >= b.valid_from
    and (b.valid_to is null or h.day < b.valid_to)
  where b.parent_isin is not null
  group by b.parent_isin, h.day
)
-- stage 2: one row of the master for each security
select m.security_id, g.day, g.open_postings
from group_day g
join security_master m
  on  m.isin = g.parent_isin
  and m.is_primary_listing;

The first stage returns 61 and 72 for the ISIN of Acme Robotics. The second attaches each figure to one row of the master, so the total after the join equals the total before it. Hiring Activity is written once, after each day closes, and is never revised, so a figure computed for a past day stays the figure for that day.

Six checks before you rely on a roll-up

Run these on the bridge and on the first result, and keep the output with the result.

For the join from the security to your master, with the order of keys and a match report, see mapping alternative data to a security master. The guide to point-in-time datasets for back-tests covers the dating of the observations themselves.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.