Who is actually driving? The account is verified. The driver is not.

Gig platforms run background checks, verify documents, and prompt for selfies. All of it binds a vetted person to an account. None of it binds a vetted person to the shift being worked right now. That gap has an open marketplace, and its price is measured in safety incidents rather than chargebacks.

The ride where nothing looked wrong

The app shows a name, a photograph, a rating of 4.9, and a silver Toyota. The silver Toyota pulls up. The plate matches. The passenger gets in, glances at the driver for about a second and a half, the same way everyone does, and looks back at their phone. The trip completes. The rating gets tapped. Nothing about the experience registers as unusual, because almost nothing was.

The one thing that was unusual is that the person driving is not the person in the photograph, has never been background checked, may not hold a licence, and is paying the account holder a weekly fee for the privilege. The account holder is at home. They passed every check the platform asked for, honestly, some months ago. They will take the next selfie prompt themselves.

This is not a hypothetical constructed to make a point. In an April 2025 investigation, the Tech Transparency Project reported identifying around eighty Facebook groups with a combined membership of more than eight hundred thousand users, in which delivery and rideshare accounts were openly advertised for rent, with group names stating the purpose in plain language. Not a dark web market with an onion address. Facebook groups, searchable, with join buttons.

Be careful with the numbers here, because this topic attracts unsourced claims. Membership of a group is not the same as an active rental, one person can belong to several groups, and a widely circulated claim that one in four gig workers rent out their accounts has no published platform data or academic study behind it that I can find. What the investigation establishes is not a prevalence rate. It establishes that the market is large enough to be organised in the open and untroubled by enforcement, which is a different fact and quite bad enough.

Why is this a safety problem rather than a fraud problem?

Most platform integrity work is framed around money. Someone is stealing promotions, laundering payments, or inflating deliveries, and the loss lands in a finance line item where it can be measured, budgeted against, and traded off. Account renting does not work like that. The platform still takes its cut. The rider still pays. The delivery still arrives. On the ledger, a rented shift and a legitimate shift are identical.

The cost surfaces somewhere else entirely, and it surfaces rarely and catastrophically rather than constantly and cheaply. It arrives as an assault in a vehicle, an unlicensed driver in a collision, a person entering a home to deliver groceries who was never screened, or alcohol handed to a minor by someone the platform has no record of. And when it arrives, the platform's own records confidently name a person who was not there.

That last part deserves a moment. Every incident response, insurance claim, police enquiry and civil suit begins by asking the platform who was working. The platform answers with total confidence and complete accuracy, in the sense that the answer is exactly what its systems recorded. The answer is also wrong. There is no flag, no anomaly, no confidence interval. The system was never designed to represent the possibility that the account and the human had come apart.

Regulators have noticed this specific failure. In 2019, Transport for London declined to renew Uber's London licence, citing among its reasons a pattern in which unauthorised drivers had uploaded their own photographs to other drivers' accounts and then carried passengers. The company contested the decision, made changes, and licences were subsequently granted on appeal. The point that survives all of that legal back and forth is that a licensing authority treated the account to human binding as a condition of operating, not as an internal product metric.

Why do selfie checks not solve this?

Every major platform runs some form of real time identity check: a prompt, at unpredictable intervals, asking the driver to take a selfie that is compared against the enrolled photograph. This is a genuinely reasonable idea and it does catch the lazy version of the fraud. It is also structurally defeatable in four distinct ways, and it is worth walking through all four, because each one points at a different missing property.

The account holder is standing right there

The most common defeat requires no technology at all. Rental arrangements are frequently local and frequently between people who know each other. The prompt appears, the renter hands the phone over, the owner takes the selfie, the phone comes back. Total elapsed time: eight seconds. The check verified, correctly and truthfully, that the enrolled human was near the phone at that moment. It did not and could not verify who would be driving thirty seconds later.

The check is a photograph, and photographs are now cheap to synthesise

Where the owner is not available, injection attacks against selfie capture flows have industrialised. Rather than holding a picture up to a camera, the attacker feeds a synthetic video stream directly into the application, bypassing the physical camera entirely. Identity verification vendors report substantial and rising volumes of these attempts, and their own published figures should be read as vendor telemetry with the usual caveats about methodology and incentive. The direction of travel is not in doubt even if the exact counts are.

The device is rented along with the account

Device fingerprinting is often proposed as the answer. It binds the account to a specific phone, so a login from an unfamiliar device raises a flag. Now consider what is actually being rented. In many arrangements the phone goes with the account, because that is far simpler for everyone involved. The device signal is perfectly stable. It is stable and wrong, which is worse than absent, because it feeds a confidence score that is now confidently incorrect.

Behavioural detection punishes the wrong people

The remaining approach is to look for patterns: driving styles that change, hours that shift, routes that do not fit history. This is probabilistic in a domain where the base rate is low and the cost of a false positive is somebody's rent. A worker who buys a new car, changes shifts to fit childcare, or moves neighbourhood produces exactly the signals the model is looking for. Talk to drivers about deactivations and you will hear a great deal about this, and the anger is justified. A control that suspends honest workers to catch dishonest ones is not a good control, it is a tax collected from the wrong people.

Put the four together and a pattern emerges. Each check verifies something true about the account, the device, or a moment. None of them verifies the thing that matters, which is a property of the human at the wheel for the duration of the work.

What is the missing primitive?

Name it precisely: per shift binding. Proof that the enrolled human, the one who was actually background checked, is the person going online for this shift, established at the moment work begins and re established at unpredictable intervals while it continues.

The analogy that gets this across is a stadium. Buying a ticket in your name and passing a bag search at the gate is onboarding: it happened once, at a boundary, and it was thorough. But if the venue only checks at the gate, then whoever holds the ticket stub is inside for the evening, and the stub is transferable. A wristband that has to be shown at each bar, checked against the wearer rather than the stub, is a different control, and it is the one that actually governs who is in the venue at ten o'clock.

Now the precise version. Binding needs four properties, and each one is chosen to close one of the four defeats above.

• It happens at go online, not at onboarding. The check is tied to the start of work, which is the moment the platform's liability begins, rather than to a registration event that happened months ago.
• It repeats unpredictably during the shift. This is what removes the value of a helpful account owner standing nearby at the start. Passing one check is easy to stage. Passing a check at 21:40 in the middle of a delivery run, without the owner present, is not.
• The comparison happens on the device, and nothing biometric is stored. The face is matched locally against a locally held reference, and what leaves the phone is a one way key and a signed assertion. There is no template in a platform database. This matters enormously for regulator acceptance and, as I will argue below, for worker acceptance too.
• It produces a receipt the worker holds. The output is not just a boolean in the platform's risk engine. It is a signed artifact the worker owns, which turns the check from something done to them into something they possess.

What the check looks like in practice

// Going online is a signed continuity event, not a session start.
POST /shift/online
{ "worker_id":  "wk_5512",
  "platform":   "delivery-co",
  "shift_start":"2026-09-07T17:02:11Z",
  "vehicle":    "plate_XY19KTR",
  "mode":       "glance" }        // fresh on-device face match

-> { "shift_id": "shf_9d20",
     "bound":    true,
     "assurance":"glance",
     "receipt":  "rcpt_a71c...",  // Ed25519, verifies offline
     "recheck_schedule": "random, 1-3 per 4h" }

// Mid-shift recheck. Fails closed: no proof, no new dispatch.
POST /shift/shf_9d20/recheck
-> { "bound": false, "reason": "no_response", "action": "dispatch_paused" }

The important design decision is in that last response. A failed recheck does not accuse anyone of anything and does not deactivate an account. It pauses new dispatch and asks for a check. A driver who was in a tunnel, or whose phone was on the dashboard mount while they carried a package up three flights of stairs, completes the check and carries on. The response to a missing proof should be proportionate, because most missing proofs are ordinary life rather than fraud.

What does the shift lifecycle look like with binding?

Two rows in that table are doing most of the work. The mid shift recheck is what collapses the rental market's economics, because a rental is only worth paying for if it reliably yields a full shift. And the last row is what makes the whole thing acceptable to the person being checked, which is the part most proposals in this space get wrong.

Why would a driver agree to any of this?

This question is not an afterthought and it should not be answered defensively. Gig workers have excellent reasons to be suspicious of any new identity check. They have watched verification requirements arrive repeatedly, always framed as safety, and experienced them as one more mechanism that can deactivate them without explanation and without appeal. Any proposal that ignores this will be correct in theory and dead on arrival.

So the design has to earn it, on four specific counts.

It has to be fast and work on a cheap phone. An on device match that takes two seconds on a four year old Android is a design requirement, not an optimisation. If the check is slow, it eats earnings, and a control that eats earnings will be defeated by the people it is applied to, entirely rationally.

It has to be presence, not surveillance. This is the distinction that has to be defended in detail rather than asserted. There is no continuous camera. There is no session recording, no keystroke capture, no productivity score, no additional location collection beyond the dispatch data the platform already has. There are a small number of discrete moments at which a face is matched locally, and the rest of the shift is unobserved. The difference between a control that fires at defined moments and a system that watches continuously is the difference between a passport check and a tail.

There must be no biometric database. If a platform holds face templates for a million workers, that database is a permanent liability, an obvious target, and in several jurisdictions a substantial legal exposure. Matching on the device and storing only a one way key means there is no template to breach, subpoena, or sell. This is also the honest answer to a worker who asks what happens to their face, and it is the reason the answer can be short.

The receipts must belong to the worker. This is the part that turns the whole proposition around. A driver working three apps currently gets verified three times, pays for it in time, and owns nothing at the end. If the output is a signed history of verified shifts that the worker holds in their own wallet, then it is an asset. It can be presented to the next platform to shorten onboarding, to an insurer, or to a licensing authority. We have argued the general form of this idea in the piece on the verified work passport, and gig work is where it bites soonest, because gig workers are the people who currently re prove themselves most often for the least return.

Reverse the framing and the incentive changes completely. A check that only protects the platform is a cost imposed on the worker. A check that produces something portable is a trade.

Honest limits

Here is what this does not do, stated plainly.

• A determined pair can still defeat it some of the time. If the account owner rides along, they can pass every recheck. This does not eliminate renting, it makes it require the owner's continuous presence, which destroys the economics for most arrangements without destroying all of them.
• Enrolment remains the bottleneck. If the renter is present at sign up and enrols their own face against someone else's documents, every subsequent check will pass faithfully. Onboarding integrity is a prerequisite for this and is a genuinely hard problem in its own right, currently under active attack from injection based document and selfie fraud.
• Family sharing is real and is not always fraud. A shared household vehicle and two adults working one account is a common arrangement, sometimes born of immigration status or credit constraints. Enforcement that treats every such case as criminal will do harm. The right response is a supported path to a second verified account, not a deactivation.
• False negatives will happen. Poor light, a mask, a cracked lens, a hand full of pizza boxes. This is why the failure mode must be a paused dispatch and a retry rather than an accusation.
• It is a reference design, not a shipped platform integration. The primitives here exist and are demonstrated in the labs, but no rideshare or delivery app currently runs this. Treat the code above as an illustration of the flow, not a drop in.

What to do this week

If you work on trust and safety, policy, or engineering at a platform:

1. Ask what your logs would say. Take a real incident from the last quarter and trace exactly which artifact identifies the worker. If the chain ends at an account identifier, you have found the gap.
2. Search your own platform's name plus the word rent on the major social networks. Do it before someone else does it and sends you the screenshots with a deadline attached.
3. Measure recheck outcomes honestly. Separate genuine failures from ordinary life. If you cannot tell them apart today, that is the first metric to build.
4. Audit your false positive cost. Count deactivations later reversed on appeal, and the median days to reversal. This number is your credibility budget with workers.
5. Move the match on device. Whatever else you do, stop accumulating face templates. It reduces liability and it is the precondition for the worker conversation going well.
6. Design the failure path first. Paused dispatch with an immediate retry, not deactivation. Write the appeal path before the enforcement path.
7. Pilot on the highest consequence handovers. Age restricted deliveries and entry into homes, where the safety argument is unarguable and the volume is manageable.
8. Talk to a regulator early. Licensing authorities are already asking about identity assurance. Arriving with a mechanism and evidence is a materially better position than arriving with a policy document.

The flow is demonstrated in the labs: the rotating contractor demo shows continuity across engagements, and the employee verification demo shows the enrolment and glance check. The developer documentation covers the receipt format and offline verification.

Frequently asked questions

How do gig platforms stop drivers from renting out their accounts? By binding each shift to the enrolled human rather than to the account. Going online requires a fresh on device face match, repeated at unpredictable points during the shift, producing a signed receipt. A renter cannot produce it without the account holder physically present throughout, which removes most of the value of renting.

Is renting a rideshare or delivery account illegal? It breaches the terms of service of every major platform and can invalidate insurance coverage for a trip. Depending on jurisdiction it may also involve driving without appropriate licensing or insurance, and can carry immigration and tax consequences for both parties. The specific legal position varies by country and city.

What did the Tech Transparency Project find about gig accounts? In an April 2025 investigation it reported identifying roughly eighty Facebook groups with more than eight hundred thousand combined members, many of which openly advertised rental of delivery and rideshare driver accounts. Group membership indicates the scale of the marketplace, not the number of rented shifts.

How do drivers get around random selfie checks? Most commonly the account holder is nearby and simply takes the selfie themselves, which takes seconds. Where they are not, attackers inject synthetic video directly into the capture flow, bypassing the physical camera. Device checks fail too, because the phone is usually rented along with the account.

Does per shift verification mean the platform is watching me all day? No. It is a small number of discrete checks: one when you go online, and occasional rechecks. There is no continuous camera, no keystroke capture, and no productivity scoring. The face match runs on your own phone and no biometric template is uploaded or stored by the platform.

Does this store my face in a company database? No, and that is the point of doing the match on the device. The comparison happens locally against a reference held on your phone. What leaves the device is a one way key and a signed receipt, neither of which can reconstruct a face. There is no central template store to breach or subpoena.

What happens if the check fails when I am working legitimately? A well designed flow pauses new dispatch and asks you to retry, rather than deactivating you. Failed checks are usually ordinary life: bad light, a cracked lens, a phone on a mount. Deactivation should require a pattern reviewed by a human, with a documented appeal.

Sources

1. Tech Transparency Project, April 2025 investigation into Facebook groups advertising rental of gig platform driver and delivery accounts: techtransparencyproject.org
2. Transport for London, licensing decisions and private hire regulation, including the 2019 decision on Uber London Limited and subsequent appeals: tfl.gov.uk
3. New York City Taxi and Limousine Commission, for hire vehicle licensing and driver requirements: nyc.gov/site/tlc
4. Directive (EU) 2024/2831 on improving working conditions in platform work: eur-lex.europa.eu
5. European Union Agency for Cybersecurity, guidance on remote identity proofing and attacks against it: enisa.europa.eu

A background check tells you who opened the account. It says nothing about who is driving tonight.