Linking public contracts to beneficial ownership records

The real case: Slovakia

Slovakia learned this the hard way. Vahostav-SK was the country's largest construction firm and had won several large state highway contracts. In 2015 it faced bankruptcy, its restructuring risked leaving hundreds of subcontractors largely unpaid, and the police investigated. Its ownership was traced through shell companies in New Zealand and Cyprus and on to five private persons based in Costa Rica. The public record had named the company on the contract and left the people behind it in the dark.

The case drove reform. In November 2015 Slovakia set up the Register of Public Sector Partners, requiring companies that want public contracts to disclose their beneficial owners before public money moves. That is the real case, and it is cited below. Everything else in this piece is labelled as a composite example.

A composite example, labelled

To show how the fix works mechanically, take a simplified chain that is explicitly a composite example: a city spends fifty million dollars on a new hospital wing. The procurement record names the buyer, a City Health Authority, and the supplier, Acme Infrastructure Ltd, with a value of $50,000,000 awarded in 2025. Anyone can look up the winning supplier's exact name. That is not the same as knowing who profits.

A company cannot get rich. Only the people who own it can. The fifty million went to Acme, but a company is a vessel: the money makes someone richer, a human being or several who own or control it, often sitting behind holding companies and trusts. That hidden set of real people is what beneficial ownership means: not who signed the contract, but who ultimately profits from it.

The project record itself is not thin. OC4IDS, the Open Contracting for Infrastructure Data Standard, tracks the whole life of an infrastructure project with climate-finance, sustainability and value-for-money modules, and it can carry beneficial owners on each party. But that field is only as good as what was collected, and in most disclosures it sits empty. The public trail stops at the supplier company.

The move that works: match the identifier, not the name

The obvious way to connect the two records fails. Match the company by name and you hit the name trap: a clerk types "Acme LLC", the ownership registry holds "ACME Limited", a third system says "A.C.M.E. Infra". One company, four spellings. Text matching produces false matches, missed matches and duplicate entities. You never reliably reach the owner that way.

The move that works is matching a shared organisation identifier instead. The Legal Entity Identifier (LEI) is the clean global example: a unique 20-character alphanumeric code for one legal entity, issued under the Global Legal Entity Identifier Foundation (GLEIF). The procurement record gives the supplier a scheme and an ID; the ownership record can carry the same official identifier on its entity. When both use the same scheme and the same ID, the join is a lookup, not a guess. Where no LEI exists, a national company-register identifier works the same way, as long as both datasets use it.

The placeholder identifier used in this piece, DEMO0000DEMO0000DEMO, is not a real LEI, so no real entity is attached to the composite chain.

Following the ownership tree

The identifier does one precise thing: it establishes that the supplier on the receipt and the entity in the ownership data are the same organisation. That opens the right tree. From there, relationship records in the Beneficial Ownership Data Standard do the climbing, rung by rung: the supplier at the base, a cross-border parent above it, a trust above that, and a controlling person at the top, each rung recorded as direct or indirect, with the share held.

Three separate things must not be conflated as you climb: matching (the identifier proves one organisation, not a chain of them), declared ownership (the register records what was declared, by a source, on a date, which may be incomplete) and misconduct (nothing in a join proves a crime). A join raises a question; it does not answer one.

What the joined data measures, once it interoperates

Once the two books interoperate, this stops being a one-off expose and becomes a standing check. Three numbers, recomputed every month, describe a market's exposure: the share of contract value held by the top owner, the number of "competing" bids that resolve to common owners, and the share of value with no disclosed owner.

A composite example shows what that check would measure. Take a year of emergency procurement: thirty non-competitive contracts awarded fast to ten companies with different names and different addresses. Read the receipt book alone and it looks like a healthy, diverse market responding to a crisis. Run the identifier join across all ten and the same controlling person sits behind every one. Diverse on paper, one owner underneath.

The three composite figures for that example are 61 percent of contract value held by the top owner, 7 competing bids that resolve to common owners, and 44 percent of value with no disclosed owner. They are illustrative, not findings about any market.

The honest claim

LEIs do not cover every supplier, registers go stale, and some ownership is hidden on purpose. Joined data surfaces risk patterns that merit investigation, patterns like common ownership, undisclosed conflicts and concentration. It does not establish wrongdoing. A flagged owner means "investigate here", never "guilty".

The data

Technical note

For readers who work with the schemas directly: OC4IDS 0.9.5 carries project-level parties with an identifier object, and suppliers appear via contracting processes; a beneficial owners field sits on each party. BODS 0.4 records Entity, Person and Relationship statements, with a recordType discriminator, recordDetails, and an identifiers array. Both were checked against the published documentation in June and September 2026. The field paths describe where such disclosure can live in the standards; they are not a claim about any published record.