Tracking Changes in the UK Sponsor Register

The register of licensed sponsors is published as a snapshot. Each release replaces the previous one. There is no added date, no removed date, no version number in the rows, and no changelog.

This means the most commercially interesting information in the register is not in the register. It is in the difference between two copies of it, and only somebody who kept the previous copy can see it.

Why the deltas matter more than the snapshot

A snapshot answers "who holds a licence today". The deltas answer questions that are far more actionable:

• New licences. An organisation that has just been granted a licence has recently decided, deliberately, that it intends to sponsor. It has paid a fee, nominated key personnel and accepted compliance duties. Frequently there is a specific role already in mind, and the vacancy has not yet been widely advertised.
• Removals. A sponsor disappearing from the register is a material event for anyone employed by or applying to it, and it can indicate a surrender, an expiry or a revocation.
• Rating changes. A move from A rating to B means the sponsor is on an action plan following a compliance concern. A move back is a resolution.

None of that is visible in a single file.

The traps in a naive diff

Diffing two CSVs sounds trivial. Doing it in a way that produces trustworthy numbers is not, and the failure mode is a stream of phantom changes that destroys confidence in the whole exercise.

Name changes read as add plus remove

If an organisation is written slightly differently between two publications, a raw diff reports it as one removal and one addition. Nothing happened, but the changelog now shows two events.

At the scale of the register, small inconsistencies in punctuation, legal suffixes and casing generate enough of these to swamp the genuine changes. Matching has to run on a normalised form of the name, not the raw string.

Multiple rows per organisation

A sponsor licensed for several routes has several rows. If a sponsor gains or loses a route, a row-level diff reports an addition or removal even though the organisation's presence has not changed at all.

Deciding what a "change" means, at the row level or the company level, has to come before the comparison, not after.

Republication is not change

Registers are republished on their own schedule, and a new file does not imply new content. Comparing files without checking whether the underlying source date moved produces a lot of confident reporting about nothing.

Store the source date alongside each version, and compare on that.

Ordering and formatting drift

Row order, column order, encoding and line endings all vary between publications. A diff that is sensitive to any of those reports differences that do not exist. Compare parsed records on a stable key, never the file bytes.

What a usable change record needs

To be worth acting on, each detected change should carry:

• the organisation, in a normalised identity that persists across versions;
• the type of change: added, removed, rating changed, route changed;
• the two source dates being compared, not just the detection date; and
• enough context to distinguish a genuine event from a formatting artefact.

The last point is the one that gets skipped, and it is the reason most homemade change feeds are quietly abandoned after a few months. Once a feed has cried wolf a dozen times, nobody reads it.

The history problem

There is a hard constraint worth stating plainly: you cannot reconstruct history you did not record.

If you start tracking the register today, your first useful delta arrives at the next publication, and a year of trend data arrives in a year. There is no archive to backfill from, because each publication overwrote the last.

That is the single strongest argument for using a maintained dataset rather than starting your own pipeline, and it is also the reason to start recording versions now even if you do nothing with them yet. The cost of storing a file is nothing. The cost of not having stored it is a year.

Rating changes deserve separate handling

Additions and removals get most of the attention, but rating movements are arguably the sharper signal, because they are evaluative rather than administrative.

A sponsor moving to a B rating is on an action plan and cannot assign new certificates until it is resolved. For a job seeker mid-application, or a recruiter with candidates in process, that is immediately relevant. For an analyst it is a compliance indicator at organisation level.

Treat it as its own change type rather than folding it into a general "updated" bucket.

What we do

VisaAtlas stores every register version with its source date, matches organisations on a normalised identity so name formatting does not generate phantom events, and classifies changes by type. That change history is what powers our public new sponsors view, and it is included in the commercial dataset with the source dates attached.

See the dataset, its versioning and its metadata →

Sources and verification

This article was checked on 26 August 2026 against:

• GOV.UK: register of licensed sponsors, workers; and
• Sponsor guidance Part 1: apply for a licence, for licence ratings and action plans.

The register's publication schedule and file format are set by the Home Office and have changed before. A change detected between two versions reflects the published data, which can itself lag the underlying decision.