logo
|
Blog
  • Homepage
  • Contact Sales
Insights

Facial Verification Before Delivery: How Can Platforms Prevent Rider Account Sharing?

ARGOS Identity's avatar
Suyeon Yang's avatar
ARGOS Identity,Suyeon Yang
Aug 12, 2026
Facial Verification Before Delivery: How Can Platforms Prevent Rider Account Sharing?
Contents
Facial Verification Before Delivery: How Can Platforms Prevent Rider Account Sharing?What If a Photo Can Pass Facial Authentication?Face Matching and Liveness Detection Serve Different PurposesAuthentication Should Be Secure Without Disrupting RidersPreventing Rider Account Sharing with ARGOS Face AuthA Four-Step Rider Authentication Flow1. Verify Identity During Onboarding2. Re-Authenticate Before Starting Delivery Work3. Trigger Additional Authentication When Risk Signals Appear4. Route Exceptions for ReviewFace Auth Does Not Replace Existing Identity VerificationWhen Should Delivery Platforms Require Facial Authentication?Rider Account Sharing Is Also an Operational RiskThe Key Is Not Just Facial Authentication. It Is the Authentication Policy.Verify the Rider, Not Just the Account

Facial Verification Before Delivery: How Can Platforms Prevent Rider Account Sharing?

Delivery platforms need to know more than who created a rider account. They also need to know who is actually using that account when delivery work begins.

Identity document verification, phone verification, and bank account verification are important during onboarding. They help confirm the identity and credentials of the person creating an account.

But they cannot necessarily prevent a legitimate account from later being shared, rented, sold, or used by someone else.

This is why facial re-authentication before a rider starts working can become an important part of preventing unauthorized account use.

However, simply adding selfie verification is not enough.

If the authentication system only compares facial similarity, someone may attempt to bypass it by displaying the registered rider's photo on another device, using a printed image, or replaying a video in front of the camera.

For facial authentication to work effectively in real-world delivery operations, platforms need to consider not only face matching, but also liveness detection, authentication timing, risk signals, failure policies, and exception handling.

What If a Photo Can Pass Facial Authentication?

Facial authentication typically compares a newly captured face with a previously registered face to determine whether they belong to the same person.

For a delivery platform, this could mean comparing a rider's selfie captured before starting work with the face registered during onboarding.

But facial similarity alone answers only one question:

Does this face look like the registered rider?

It does not necessarily answer another critical question:

Is the registered rider actually present in front of the camera?

Someone who has access to the account holder's photo could display it on another smartphone. A printed image or prerecorded video could also potentially be used in an attempt to spoof the authentication process.

More sophisticated attacks may involve manipulated or synthetic facial content.

That is why rider authentication needs to answer two separate questions:

  1. Is the person being captured the same person who originally registered?

  2. Is the camera capturing a real, live person rather than a photo, screen, or replayed video?

Face matching addresses the first question. Liveness detection addresses the second.

Face Matching and Liveness Detection Serve Different Purposes

Face matching determines whether two facial images belong to the same person.

For example, a platform can compare the rider's face captured during onboarding with a new selfie taken immediately before starting delivery work.

Liveness detection serves a different purpose. It helps determine whether the biometric sample comes from a live person rather than an attempt to spoof the system using a photo, screen, or prerecorded content.

Neither capability alone fully addresses rider account sharing.

Face matching without liveness may leave the system vulnerable to presentation attacks using the registered rider's image.

Liveness without face matching may confirm that a real person is present, but not that the person is the registered rider.

For stronger rider authentication, the two should work together:

Is this a real person? → Is this the registered rider?

This combination allows delivery platforms to verify both the authenticity and identity of the person attempting to start work.

Authentication Should Be Secure Without Disrupting Riders

Some liveness methods require users to perform specific actions, such as turning their head, blinking, or following instructions displayed on the screen.

These methods can be useful in certain high-risk scenarios, but requiring multiple actions every time a rider starts work may create unnecessary friction.

Delivery riders may authenticate outdoors, while moving between locations, or under inconsistent lighting and network conditions.

For this reason, passive liveness detection can be useful for routine authentication.

Passive liveness analyzes the captured facial data and related visual signals without requiring the user to perform complicated actions. This can help detect presentation attacks while allowing legitimate riders to complete authentication through a relatively simple selfie flow.

The appropriate level of authentication should depend on the platform's environment and risk profile.

Routine activity may require only a quick selfie-based check, while suspicious activity can trigger stronger authentication or additional review.

Preventing Rider Account Sharing with ARGOS Face Auth

ARGOS Face Auth enables platforms to compare a user's current facial image with the facial information established during the initial identity verification process.

For delivery platforms, the process can begin during rider onboarding.

The rider submits an identity document and captures their face. The platform can verify information extracted from the ID, check the document, compare the portrait on the ID with the person completing registration, and establish a trusted identity profile.

Once this identity has been established, the registered facial information can serve as a reference for future authentication.

Before starting delivery work, the rider simply captures a new selfie.

ARGOS Face Auth can then compare the current rider with the registered identity, while liveness detection helps determine whether a real person is present during authentication.

If both checks succeed, the rider can proceed.

If the face does not match or a spoofing attempt is suspected, the platform can block the session, request another verification attempt, or route the case for further review.

This creates an authentication layer between the person who registered the account and the person actually performing delivery work.

A Four-Step Rider Authentication Flow

A practical rider authentication system can be structured around four stages.

1. Verify Identity During Onboarding

The platform first establishes the rider's identity using appropriate verification methods, such as:

  • Identity document verification

  • Face matching

  • Liveness detection

  • Phone verification

  • Bank account or payment information verification

The objective is to create an account tied to a verified individual.

2. Re-Authenticate Before Starting Delivery Work

When the rider taps "Start Delivery" or begins a work session, the platform requests a selfie.

The newly captured face is compared with the identity established during onboarding, while liveness detection helps prevent photo or video-based spoofing.

If both checks pass, the rider can begin working.

3. Trigger Additional Authentication When Risk Signals Appear

Not every rider needs to complete the same authentication flow every time.

Platforms can trigger additional authentication when higher-risk activity is detected, such as:

  • Login from a new device

  • Unusual location or access pattern

  • Reactivation after a long period of inactivity

  • Multiple devices accessing the same account

  • Password reset

  • Bank account changes

  • Repeated facial authentication failures

  • Suspicious device environments

This risk-based approach can strengthen security without creating unnecessary friction for every legitimate rider.

4. Route Exceptions for Review

A failed facial authentication does not always mean account misuse.

Poor lighting, camera quality, network conditions, or changes in appearance can affect authentication results.

Clear matches can therefore be processed automatically, while ambiguous or suspicious cases are routed for additional authentication or operational review.

This helps platforms focus manual resources on exceptions rather than reviewing every rider authentication attempt.

Face Auth Does Not Replace Existing Identity Verification

Face Auth should not be considered a replacement for identity document, phone, or bank account verification.

Each method answers a different question.

Verification Method

Primary Purpose

ID Verification

Verify the identity and validity of the person registering

ID-to-Face Matching

Confirm that the applicant is the owner of the submitted ID

Liveness Detection

Detect attempts using photos, screens, or replayed content

Phone Verification

Confirm access to the registered phone number

Bank Account Verification

Verify account ownership or identity consistency

Face Auth

Confirm that the current user is the same person who originally registered

The strongest approach is to connect these methods across the rider journey.

Onboarding verifies who created the account. Face Auth helps verify who is using it now.

When Should Delivery Platforms Require Facial Authentication?

Authentication timing is just as important as the technology itself.

Requiring facial verification too frequently can disrupt legitimate riders. Requiring it too rarely may reduce its effectiveness against account sharing.

Platforms can consider authentication at moments such as:

Authentication Point

Purpose

Initial onboarding

Establish the rider's verified identity

First work session of the day

Confirm who is actually starting delivery work

Login from a new device

Detect potential account transfer or unauthorized access

Return after prolonged inactivity

Reconfirm the account holder

Unusual location or access pattern

Investigate abnormal activity

Password reset

Protect account recovery

Bank account change

Reconfirm identity before sensitive changes

Repeated authentication failure

Investigate possible account sharing or spoofing

This allows platforms to move from a fixed authentication model to risk-based rider authentication.

Low-risk activity can remain fast and simple, while higher-risk events trigger stronger verification.

Rider Account Sharing Is Also an Operational Risk

Unauthorized rider account use is not only an authentication issue.

If the person registered with the platform is different from the person actually performing deliveries, it can create challenges when incidents or disputes occur.

Platforms may have difficulty determining who actually performed a delivery. Insurance or accident-handling processes may become more complicated, and customer information such as addresses and contact details could potentially be exposed to an unregistered individual.

The challenge can become even greater when riders are recruited or managed through partner agencies or local operators.

Even if a partner submits legitimate rider information during registration, the platform still needs a way to determine whether the same individual is actually using the account in the field.

Facial re-authentication before delivery work provides an additional control that connects the registered identity with the person performing the activity.

The Key Is Not Just Facial Authentication. It Is the Authentication Policy.

Adding facial authentication alone does not automatically prevent rider account sharing.

Platforms also need to define:

  • When authentication should be required

  • Which risk signals trigger additional verification

  • How many retries should be allowed

  • What happens after a face mismatch

  • When delivery activity should be restricted

  • Which cases should be escalated for manual review

The objective is not to make every rider go through the strongest possible verification every time.

Instead, platforms can automatically approve clear, legitimate authentication attempts and apply stronger controls only when mismatches or risk signals appear.

Ultimately, preventing rider account sharing requires a connected identity journey:

Onboarding → Pre-Delivery Face Auth → Risk Detection → Additional Verification or Review

ARGOS Face Auth helps delivery platforms verify whether the person attempting to start work is the same person who originally registered, while liveness detection helps identify attempts involving photos, screens, or replayed content.

By combining these capabilities with risk-based authentication policies, delivery platforms can strengthen account security while keeping the authentication experience simple for legitimate riders.

Verify the Rider, Not Just the Account

Want to learn how ARGOS Face Auth can be integrated into your rider authentication flow?

Contact ARGOS Identity to explore a rider account protection strategy tailored to your platform.

Share article
Contents
Facial Verification Before Delivery: How Can Platforms Prevent Rider Account Sharing?What If a Photo Can Pass Facial Authentication?Face Matching and Liveness Detection Serve Different PurposesAuthentication Should Be Secure Without Disrupting RidersPreventing Rider Account Sharing with ARGOS Face AuthA Four-Step Rider Authentication Flow1. Verify Identity During Onboarding2. Re-Authenticate Before Starting Delivery Work3. Trigger Additional Authentication When Risk Signals Appear4. Route Exceptions for ReviewFace Auth Does Not Replace Existing Identity VerificationWhen Should Delivery Platforms Require Facial Authentication?Rider Account Sharing Is Also an Operational RiskThe Key Is Not Just Facial Authentication. It Is the Authentication Policy.Verify the Rider, Not Just the Account

ARGOS Identity

RSS·Powered by Inblog