Companies House PSC data now needs a freshness rule

Companies House PSC data is now a daily operating input, not a static enrichment table. The public snapshot visible on 4 September 2026 carried a 3 September file date and a morning update timestamp, with contents compiled to the end of the previous day. That makes freshness a rule teams must encode, not a note analysts can remember.

The snapshot is free, JSON-formatted and downloadable as either one large file or split files. It is also overwritten daily and described as unsupported. For a KYB, credit or supplier-risk workflow, that combination creates a simple control question: what exact file did the decision use, and when did a newer file become available?

Bulk files solve a coverage problem. They let a team ingest the full list of persons with significant control provided to the register, then join it to internal customer, vendor or exposure tables. They do not, by themselves, prove that a displayed owner is the latest record at the moment a case is reviewed.

The registry’s broader data products show why this distinction matters. Basic company data is a monthly snapshot, accounts files are added on a daily cadence over part of the week, and PSC data has its own JSON snapshot. A single “Companies House checked” label hides different compilation windows, file formats and legal-use warnings.

• Store the file name, registry timestamp and ingestion timestamp with every PSC fact.
• Set a daily cutoff, for example: decisions after the new morning file lands must use that file or show an override.
• Keep the raw PSC notification identifier where available, so a later API call can test whether the record changed.

The public API exposes PSC lists, statements and several PSC record types through company-number endpoints. It also returns resource headers such as ETags on supported calls. That gives engineering teams a practical pattern: use the bulk file for population-wide refresh, then call the API when a decision needs record-level confirmation.

A useful example is an onboarded company whose PSC changed after the overnight snapshot cutoff. The bulk import may still show yesterday’s position, while the case requires today’s ownership evidence. In that situation, the workflow should record both the snapshot fact and the API check, rather than silently replacing one with the other.

PSC identity verification is now its own compliance signal. A PSC must verify identity and provide a personal code, but the 14-day period depends on the role. A director who is also a PSC provides the code separately for each role, while a non-director PSC uses a birth-month window unless they became a PSC after 18 November 2025.

That means an ownership graph and an identity-verification graph should not collapse into one Boolean field. A person may be a reported PSC, a director, both, newly added, deceased pending probate handling, or inside a verification window. Official management information also treats director and PSC appointment compliance as measured data, reinforcing that status should be modelled explicitly.

• Separate reported control, role type, verification obligation and verification evidence.
• Flag timing windows separately from failures, because a current deadline can be valid without being complete.
• Avoid using the absence of a verification flag as proof that a PSC relationship is false.

Beneficial ownership data works best when treated as statements about people, entities and relationships at a point in time. The standard data-model approach supports source dates, history and conflicting statements. That is a better fit for registry data than a flat owner table that keeps only the latest name and percentage band.

For teams using CompanyProof alongside raw registry feeds, the design question is where evidence lives after the screen moves on. A rejected supplier, a raised credit limit or a manual override may need to be reconstructed months later. Keep the source file, the normalized fact, the transformation version and the decision that consumed it.

A good rule is modest: do not call a PSC fact current unless the system can show the newest available snapshot used at the time, or a later API check for that company. The rule should be visible to operations teams. If an analyst sees “snapshot 2026-09-03, loaded 09:18, API checked 11:42”, they can understand the evidence without reading a data pipeline log.

The same rule should drive stale-fact monitoring. High-risk counterparties can refresh on every material event, while low-risk portfolios can refresh on a scheduled cadence. What matters is that ownership, director and filed-financial facts do not share one arbitrary age limit. Each source has its own rhythm, and the control should reflect that rhythm.