Matching Is Now Employing: What the October 2026 Right to Work Rules Mean for Platforms

For as long as the gig economy has existed, platform businesses have leaned on a single structural claim: we are not the employer, we are the marketplace. The contract is between the customer and the provider. We take a cut for introducing them. The people who do the work are in business on their own account, and their compliance is their own affair.

From 1 October 2026, that claim stops working — at least for the purposes of illegal working liability.

Section 48 of the Border Security, Asylum and Immigration Act 2025 comes into force on that date, confirmed by the Commencement No. 4 Regulations laid on 24 June 2026. A draft revised Code of Practice on preventing illegal working followed on 30 June. Together they redraw the boundary of who counts as an "employer" under the Immigration, Asylum and Nationality Act 2006 — and marketplaces are squarely inside the new line.

The definitional change

The old regime was narrow and, from a policy standpoint, almost comically easy to design around. Right to work checks attached to a contract of employment. Structure your labour any other way and the duty simply didn't arise.

The new section 14A extends "employer" to cover a person who engages an individual:

• under a contract of employment;
• under a worker's contract;
• as an individual sub-contractor; or
• through an online matching service that provides the details of an individual service provider to potential clients or customers.

That last limb is the one platform operators need to sit with. It doesn't ask whether you pay the worker. It doesn't ask whether you set the price, control the schedule, or hold the contract for services. It asks whether you passed the individual's details to a customer. On the current drafting, providing the details is itself enough to constitute employment for right to work purposes.

If your business model is "we surface providers to buyers," you are an employer of every provider you surface.

What's at stake

The penalty framework isn't new, but the population it now applies to is dramatically larger:

• Civil penalties of up to £60,000 per worker. Per worker. For a marketplace with a five-figure supply side, the arithmetic gets alarming very quickly.
• Criminal liability in cases of deliberate breach — up to five years' imprisonment and an unlimited fine.
• Business closure orders, and for sponsor licence holders, revocation.

The changes are not retrospective. A civil penalty can only be imposed on in-scope arrangements that commence on or after 1 October 2026. That is a genuine relief for anyone with a large existing supply side — but it is also a trap, because "commence" is doing a lot of work in that sentence and the boundary between a continuing arrangement and a new one is going to be fought over.

The statutory excuse, and why it's harder than it looks

The defence against a civil penalty is the same as it has always been: perform a compliant right to work check and retain the evidence. For platforms, though, "compliant" now carries three requirements that will each require engineering work.

1. A written contract with prescribed terms, before work starts

Where a business is not the direct employer, the statutory excuse depends on having a written contract in place before the work or service commences, containing terms and conditions prescribed by the Home Office. Not a clickwrap terms-of-service update after the fact — a contract that exists before the first job is accepted, containing specific language.

2. The check itself, through the right channel

Three routes remain: the Home Office online service via a share code, a manual check of original documents, or a digital identity verification provider.

The third route has a new gate. From 1 October, where a business relies on a digital verification service provider to establish a statutory excuse, that provider must be registered on the Office for Digital Identities and Attributes (OFDIA) register — and specifically authorised for right to work checks, not merely for identity verification generally. The Code renames these providers "Right to Work Digital Verification Service Providers" (RtW DVSPs) partly to force this distinction.

This is worth stating bluntly, because a lot of platforms have already integrated an identity vendor and will assume they are covered: being an identity provider is not the same as being an RtW DVSP. Check the register. If your vendor isn't on it with the right authorisation, your statutory excuse evaporates.

3. Imposter controls, on an ongoing basis

This is the requirement that will surprise people most, and it flows directly from substitution.

A right of substitution — the ability of a provider to send someone else to do the job — is the classic drafting device that establishes genuine self-employment. It is ubiquitous in platform contracts precisely because it defeats the personal-service test. The Code notes that such a right will exist wherever the individual is engaged under a contract for services.

Under the new regime, that device now generates obligations rather than dissolving them. If substitution is permitted, the check must extend to the substitute. And the platform must maintain proportionate systems and processes to ensure that the person actually doing the work is the person whose right to work was checked. The Code offers five suggested mechanisms, including access passes, facial verification technology, and periodic re-verification of identity.

In other words: a one-time onboarding check is no longer sufficient. Platforms are being asked to build continuous identity assurance into the work itself. Whoever picks up the shift, enters the building, or opens the app to accept the job must be provably the same person who passed onboarding.

The supply-chain tail

New section 15A extends civil penalty liability beyond the party holding the direct contractual relationship with the worker. Where labour reaches an end client through a chain — subcontractor to subcontractor, or platform to agency to individual — liability may travel up.

The Code suggests this is intended to bite mainly where the Home Office cannot identify the party with the direct relationship. That is a meaningful limitation, but it is cold comfort: if a link in your chain is opaque, undocumented, or simply gone by the time an enforcement visit happens, the identifiable party at the top is the one holding the penalty notice. Contractual protections — audit rights, evidence-sharing obligations, indemnities, notification duties — become the only real mitigation, and they need to be in place before October, not negotiated after an enforcement action.

The paradox nobody has resolved

Here is the awkward part, and it deserves more attention than it is getting.

Everything the new regime asks a platform to do — verify identity, gate access to work, control and check substitutes, run facial re-verification at intervals, hold a compliance file on each provider — is control. And control is the raw material of employment status.

The Government is explicit that these immigration changes are not intended to alter employment law. But employment status has never turned on what a contract says; it turns on how the relationship operates in practice, day to day. A platform that dutifully implements every requirement of the new Code will, by the end of it, look considerably more like an employer than it did before — and will have created an extensive documentary record of exactly how much oversight it exercises.

That record is discoverable. The compliance you build to avoid a £60,000 immigration penalty is the same compliance a claimant's solicitor will point to in an employment tribunal arguing for worker status, holiday pay, national minimum wage and pension auto-enrolment.

There is no clean way out of this. But it does mean the right to work project cannot be run purely as an immigration workstream. It needs employment law sitting at the table from the start, because the design decisions — how substitution is handled, how much re-verification is imposed, how deactivation works — carry status consequences that will outlive the immigration exposure.

And the discrimination duty running underneath

A separate draft Code, on avoiding unlawful discrimination while preventing illegal working, is coming into force alongside. The core requirement: checks must be applied consistently to everyone, including British and Irish citizens. No assumptions based on nationality, ethnicity, accent, surname, appearance, or how long someone appears to have lived in the UK.

For platforms this is a product design constraint, not an HR policy. If your onboarding flow branches — if some providers hit a verification step and others sail past it based on any signal correlated with a protected characteristic — you have built discrimination into your funnel and left an audit trail proving it. A uniform flow, applied to every provider, is both the compliant design and the defensible one.

What to do between now and October

1. Map the supply side. Every category of individual who provides work or services through your platform: employees, workers, individual subcontractors, substitutes, agency-supplied labour, providers introduced but not contracted.
2. Audit your identity vendor. Are they on the OFDIA register? Are they authorised specifically for right to work checks? If not, start procurement now.
3. Rewrite the contracts. Prescribed terms, in place before work commences. This is a legal drafting exercise with a hard deadline, and it needs to land before your engineering deadline, not after.
4. Design the imposter controls. Decide now whether you are doing periodic re-verification, at-work facial verification, access passes, or some combination — and build it. This is the longest lead-time item on the list.
5. Take advice on status. Before you finalise the design, not after. See the paradox above.
6. Instrument the record-keeping. Evidence retention, repeat-check diarising for time-limited leave, and a clean audit trail per provider. Retention runs for two years after the engagement ends, and this is a new processing purpose that your privacy documentation almost certainly does not yet cover.

The caveat that matters

The Code is still in draft. More importantly, the Employer's Guide — the document that will actually contain the worked examples showing how liability falls in real business models — has not yet been updated. Every commentator writing about this, including this one, is reasoning from a definitional framework without the illustrations that will determine how it lands in practice.

That's not a reason to wait. Twelve weeks is not long to procure a verification provider, redraft a supply-side contract, and ship continuous identity assurance. But it is a reason to build for the principle rather than the letter, and to expect the detail to move.

This post is a summary of a developing legal position and is not legal advice. If you operate a platform in the UK, take specialist immigration and employment advice on your own arrangements.