If your platform does anything with UK hiring — eligibility checks, right to work flows, sponsor licence validation, or immigration cost modelling — you need an accurate model of how the UK Points-Based System (PBS) actually works under the hood. The name implies a dynamic scoring model. The reality is closer to a deterministic constraint-satisfaction problem.
This post maps the actual decision logic so you can model it correctly.
System Architecture: Not a True Points Auction
Australia's GSM (General Skilled Migration) system is genuinely points-based: candidates accumulate scores across weighted categories, rankings are generated, and the top scorers receive invitations from a fixed pool. Scores in one dimension can compensate for deficits in another.
The UK PBS works differently. It's threshold-based with structured trade-offs, not a continuous scoring model. For the Skilled Worker visa — the primary work route — the decision tree looks like this:
MANDATORY (all must pass):
├── Approved sponsor exists → 20pts
├── Job at RQF3+ skill level → 20pts
└── English language requirement met → 10pts
SALARY FLOOR (must reach 70pts total via one of):
├── Salary >= general threshold (£38,700) → 20pts
├── Salary >= going rate x 0.8 AND (job on ISL OR PhD relevant) → 20pts
└── New entrant rate applies AND salary >= reduced threshold → 20pts
Key engineering insight: The mandatory block is strictly conjunctive — all three must be true. The salary block introduces conditional branches, but each branch is itself binary (not weighted). There is no partial credit; you cannot compensate for a missing sponsor with a higher salary.
This means your eligibility model should be implemented as a decision tree or rule engine, not a linear scoring function.
Salary Threshold Data Model (2026)
The salary requirement has two components that must both be satisfied:
def salary_eligible(offered_salary: float, going_rate: float,
on_isl: bool, has_phd: bool, is_new_entrant: bool) -> bool:
GENERAL_THRESHOLD = 38700
NEW_ENTRANT_THRESHOLD = 30960 # approximate — verify per SOC code
# New entrant path
if is_new_entrant:
floor = min(going_rate * 0.8, NEW_ENTRANT_THRESHOLD)
return offered_salary >= floor
# ISL / PhD trade-off path
if on_isl or has_phd:
reduced_going_rate = going_rate * 0.8
floor = max(reduced_going_rate, GENERAL_THRESHOLD * 0.8)
return offered_salary >= floor
# Standard path
return offered_salary >= max(GENERAL_THRESHOLD, going_rate)
Note: The going rate is per-SOC code. The Home Office publishes a table of occupation codes with their going rates; this table is the authoritative source and gets updated periodically. Your system should treat this as a versioned dataset, not a hardcoded constant.
Sponsor Licence as a Prerequisite State
The approved_sponsor flag in the mandatory block deserves special attention. An employer either holds a valid sponsor licence or does not — but licence status can change:
- Active — can assign Certificates of Sponsorship (CoS)
- Suspended — cannot assign CoS; existing sponsored workers in a grey area
- Revoked — cannot assign CoS; sponsored workers' leave may be curtailed
For eligibility calculations, model sponsor status as a time-indexed property, not a static boolean. A worker might be eligible today on the basis of an active sponsor and ineligible tomorrow if that licence gets revoked.
The UK Government publishes a register of licensed sponsors. If you're building a live eligibility tool, you should sync against this data — or use ImmigrationGPT which maintains a parsed copy of the full register with 125,000+ companies.
Occupation Code Classification
The RQF3+ skill level requirement is a property of the occupation code (SOC 2020), not the job title. The Home Office maintains a list of eligible occupation codes. Your system needs to map from job title/description → SOC code → RQF level → eligible/ineligible.
This mapping is non-trivial:
- The same job title can map to multiple SOC codes depending on sector
- Some codes are split between RQF3+ and below based on duties
- TIDES (the SOC lookup tool) is the official reference, but requires interpretation
Store the occupation code alongside the eligibility decision for auditability.
Route-Specific Constraint Tables
The Skilled Worker visa is the main route, but the PBS covers multiple routes with different constraint sets:
| Route | Key Distinguishing Constraint |
|---|---|
| Global Talent | Endorsement from designated body replaces salary/sponsor requirements |
| Graduate | No salary floor; no sponsor needed; time-limited (2 years, 3 for PhDs) |
| Scale-up | Salary >= £36,300; sponsor only required for first 6 months |
| Senior/Specialist | No salary cap upward; no ISL trade-off available |
If your system needs to suggest the optimal route for a given profile, build a multi-route resolver — evaluate each route's constraint set independently against the candidate profile.
Monitoring Threshold Changes
The PBS is a live regulatory framework. Salary thresholds changed significantly in 2024 and were reviewed again in 2025. The Immigration Salary List is reviewed periodically by the MAC (Migration Advisory Committee). Occupation code classifications change with SOC revisions.
For production compliance systems, treat threshold data as configuration that changes on a known schedule — not as hardcoded constants. Implement a versioning strategy so you can answer "what were the rules on date X?" for audit purposes.
ImmigrationGPT indexes official GOV.UK policy pages and provides an interface for rule lookups, reducing the overhead of tracking upstream changes yourself.
Summary
The UK PBS is best modelled as:
- A conjunctive mandatory block (all-or-nothing)
- A conditional salary floor with structured trade-offs
- A versioned dataset for going rates, ISL membership, and SOC eligibility
- A time-indexed sponsor status lookup
Build it as a rule engine with auditable decisions and version-controlled thresholds — not a static scoring function.
This post covers the technical architecture of the UK PBS for engineering and HR platform purposes. It is not legal advice. UK immigration rules change frequently — always validate against official GOV.UK sources for production systems.
Top comments (0)