UK Points-Based Immigration 2026: The Data Dependencies Powering Correct Eligibility Checks

If your platform handles UK hiring, onboarding, or immigration compliance, the Points-Based System is the underlying framework governing whether overseas workers can legally take a job. This post focuses on the data side: what inputs drive a correct eligibility determination, where those inputs come from, and where they break.

The 70-point structure and why it matters for code

Every Skilled Worker application requires exactly 70 points. The split is fixed:

• 50 mandatory points — Certificate of Sponsorship (20), eligible skill level (20), English language (10). These cannot be substituted.
• 20 tradeable points — met through salary at or above threshold, optionally combined with Immigration Salary List status or PhD indicator to trade down to a lower salary floor.

The mandatory/tradeable distinction is important for eligibility logic. The 50 mandatory points are binary checks: a CoS exists and is valid; the SOC code maps to RQF Level 3 or above; the English language condition is satisfied. You don't need to calculate anything — you verify.

The tradeable 20 points involve thresholds and lookups. That's where the data complexity lives.

The two-threshold salary check

Salary eligibility is determined by two values, and the applicant must meet whichever is higher:

1. General threshold: £38,700 (current as of 2026)
2. Going rate for the SOC code: published by the Home Office in the Skilled Worker appendix, derived from ONS ASHE data

Your eligibility function looks roughly like:

def salary_is_eligible(salary, soc_code, on_immigration_salary_list, has_phd):
    going_rate = get_going_rate(soc_code)
    general_threshold = 38700

    # If on ISL or has PhD, salary can trade down to 70% of going rate
    # but floor is always 30960
    if on_immigration_salary_list or has_phd:
        effective_minimum = max(going_rate * 0.70, 30960)
    else:
        effective_minimum = max(going_rate, general_threshold)

    return salary >= effective_minimum

This is a simplification — there are new entrant rates and further rules for specific cases — but the core logic holds. The critical data dependency is get_going_rate(soc_code), which needs to be sourced from the current Home Office published tables, not estimated or hardcoded.

Where the Home Office data lives (and when it changes)

The going rates and the Immigration Salary List are published in the Immigration Rules Appendix Skilled Worker. They're updated when the Home Office makes rule changes — these have been annual or more frequent since 2024.

There's no API. The data lives in a mixture of HTML tables and linked documents on GOV.UK. If you're building tooling that depends on current thresholds, you need a scraping or ingestion pipeline pointed at the appendix pages, with a change-detection layer.

Key URLs to monitor:

• https://www.gov.uk/guidance/immigration-rules/immigration-rules-appendix-skilled-worker
• https://www.gov.uk/guidance/skilled-worker-visa-going-rates-for-eligible-occupation-codes

The SOC 2020 code system introduced new codes alongside the old SOC 2010 ones. Some job titles that appeared clearly in one version don't map cleanly to the other. The Home Office published crosswalk guidance, but it's not exhaustive, and HR systems that haven't been updated may still be issuing CoS forms with deprecated SOC codes.

The sponsor register dependency

The other data source that drives eligibility is the sponsor register — the Home Office's live list of organisations approved to issue Certificates of Sponsorship.

The register is published as a downloadable CSV at https://www.gov.uk/government/publications/register-of-licensed-sponsors-workers. It updates at irregular intervals — roughly weekly in practice, occasionally more frequently after enforcement actions.

For any eligibility check that includes "can this employer sponsor this worker," you need:

1. The employer to appear in the register
2. The employer's licence status to be "Active" (not Suspended, not Revoked)
3. The licence type to include the right route (Worker, not Student or Temporary Worker)

A company can have an active licence but be approved only for specific routes. A biotech firm might hold Worker and Senior or Specialist Worker permissions but not Temporary Worker. Checking only for presence in the register, without checking the applicable routes, can produce false positives.

The SOC code mismatch problem

The most common compliance error in CoS issuance is SOC code selection based on job title rather than job duties. HR systems often present a dropdown that maps job titles to SOC codes — but job titles aren't standardised, and a "Software Engineer" at one company is a "Technical Lead" at another, which maps to a different SOC code with a different going rate.

The downstream effect: a CoS issued with the wrong SOC code may assert a going rate that doesn't match what the Home Office will apply when assessing the application. If the actual going rate for the correct SOC code is higher than what the CoS stated, the application may be refused on salary grounds even when the employer thought they were compliant.

Building a validation step that flags likely SOC mismatches — based on common title patterns and their typical code mappings — reduces this risk, but requires maintaining a job-title-to-SOC mapping that tracks Home Office guidance updates.

New entrant rates

Applicants who are "new entrants" can qualify at 70% of the going rate, subject to a floor of £30,960. The new entrant criteria are:

• Under 26 at the time of application
• Switching from a Student or Graduate visa
• Working towards professional qualification through the role

These conditions are mutually exclusive with a PhD trade-down — you can only apply one discount. New entrant status is self-reported at application stage and is expected to align with the CoS details; inconsistencies trigger scrutiny.

What breaks at scale

The failure modes in PBS compliance tooling tend to cluster around:

• Stale going rate data — going rates updated annually or more; cached values drift
• SOC code mismatch — CoS issued with wrong code, application assessed against different going rate
• ISL status not reflected — a job is added to or removed from the Immigration Salary List; checks use old data
• Sponsor register lag — a company's licence is revoked mid-hire cycle; tooling still shows them as active

None of these are unsolvable engineering problems. They're data freshness and validation gaps. The most robust approach is treating the Home Office published sources as the authoritative data layer, ingesting them on a schedule, and running comparisons against what's been cached.

For a real-time employer licence check, immigrationgpt.co.uk provides a search interface over the current sponsor register — useful for spot-checking during due diligence workflows.

---

UK immigration rules change frequently. This post reflects the rules as of July 2026. Always verify against current Home Office guidance before relying on any eligibility logic in production systems.