Data Methodology & Refresh Schedule

Sources

HM Land Registry — CCOD and OCOD

The ownership records behind every search come from two HM Land Registry open datasets:

• CCOD — Commercial and Corporate Ownership Data. Registered titles in England and Wales whose proprietor is a UK-incorporated company or other corporate body.
• OCOD — Overseas Companies Ownership Data. The equivalent for proprietors incorporated outside the UK, with an added country-of-incorporation field.

Both are published by HM Land Registry under the Open Government Licence v3.0, and we attribute accordingly. Coverage is England and Wales only. A field-by-field breakdown is in CCOD data explained.

Companies House

Company and director lookups use the Companies House public API. These are made at search time, not cached from a periodic import, so the corporate position reflects the register as it stands when you run the search. This is what makes director search possible: the API resolves a person's name to their appointments, and those companies are then checked against the ownership data.

The Gazette

Owner profiles draw on The Gazette, the UK's official public record, for insolvency and corporate notices. This provides context on the corporate status of a proprietor that the ownership dataset alone cannot give.

Refresh schedule

One point deserves emphasis because it is routinely misunderstood: publication cadence is not the same as currency. Even a freshly published file lags reality, for two compounding reasons. A transfer must be applied for and registered before it can appear anywhere, and registration itself takes time after completion. Then the monthly publication cycle adds its own delay.

The practical consequence is that a recent transaction may be absent from an entirely current dataset. For anything where the date of ownership matters, the register is the source, not the dataset.

Processing pipeline

The raw files are not directly queryable at the speed a search tool needs, so each release goes through the following.

1. Ingestion

Each dataset is downloaded and parsed row by row. Malformed rows — which do occur, largely because address free-text contains characters that break naive CSV parsing — are handled defensively rather than aborting the load. A failure to retrieve one dataset does not prevent the other from loading.

2. Normalisation

This is where most of the retrieval quality is decided. For every row we derive normalised forms alongside the originals:

• Company registration numbers are upper-cased with spaces, hyphens and parentheses removed. Crucially, leading zeros are preserved — 00123456 is a different company from 123456, and stripping zeros is the classic cause of a false nil return.
• Proprietor names are upper-cased and trimmed for indexed comparison.
• Addresses and postcodes are upper-cased and trimmed.

Normalisation is applied identically to stored data and to incoming queries. That symmetry is the point: a query normalised differently from the index will silently fail to match.

3. Indexing

Normalised columns are indexed for the query patterns the tool actually serves — exact lookup on registration number, and substring search across names, addresses and postcodes. Substring matching on a dataset of this size needs trigram indexing to be viable; without it, name and address search degrades into a full table scan.

4. Matching at query time

The four search types behave differently by design:

Name search is deliberately tuned toward recall. In due-diligence work a missed holding is usually more costly than a candidate you discard after checking — but that choice puts the confirmation step on you, which is why every name match should be reconciled against the registration number, proprietor address and proprietorship category.

5. Result limits

Result sets are capped per search to keep response times predictable. For very large portfolios this means a single query may not return every title, and a genuinely exhaustive extract requires narrowing by entity or working from the source files. See bulk property data export.

Known limitations

These are inherent to the source data, not artefacts of our processing, and they are the ones worth citing explicitly if you rely on a result in formal work.

• England and Wales only. Scotland and Northern Ireland are separate registers.
• Registered land only. Unregistered land appears in no dataset.
• Corporate proprietors only. Property held by private individuals is out of scope by design.
• Registered, not beneficial, ownership. Nominees and corporate trustees are indistinguishable from owners.
• No charges, covenants, boundaries or lease terms. Register and title-plan matters.
• Short leases absent. Interests not requiring registration do not appear.
• Sparse price paid. Recorded only where captured; blank means "not recorded", not "no consideration". Never a valuation.
• Registration lag. Discussed above; material for date-sensitive questions.
• Address text is not normalised at source. Register transcriptions vary, and some entries are descriptive rather than postal.
• Title-to-property is not one-to-one. One title can cover many addresses; one building can carry many titles.

The due-diligence implications are worked through in what CCOD does and does not tell you.

Corrections and data queries

We do not hold the source records and cannot amend the register. If an entry appears wrong, the correction has to come from the registry that published it — HM Land Registry for title and proprietor data, Companies House for company and officer data. If you believe we have processed or displayed something incorrectly, or you need methodology detail for citation, see press and data requests.

Where to go next

• CCOD data explained — the field reference.
• Press and data requests
• Companies House vs Land Registry
• Frequently asked questions