The gap
The driver who onboarded isn't always the driver behind the wheel.
Onboarding identity can drift from operating identity
Driver substitution — one driver's credentials onboarded, a different driver actually driving — is invisible to a platform that only checks identity once at signup.
A submitted photo doesn't confirm a live match
Without liveness and face-match at the trigger moment, a platform can't tell a legitimate driver from a substituted one using the same uploaded credential.
Safety and insurance inquiries need a per-trip record
When a safety incident or insurance claim raises the question of who was actually driving, a platform without a signed per-trip identity record has nothing to produce.
Capabilities
Identity verification at the carrier and driver onboarding boundary
Carrier principal identity at vendor signup
Government-issued ID captured in-session for the motor-carrier principal at the moment they vendor-onboard onto the platform. Selfie capture for liveness + face match against the document portrait. The signed identity assertion is the platform's primary key for the carrier record.
Driver identity at trip assignment
When a driver is assigned to a trip, the platform can require a fresh Stile session against the driver's CDL or other government ID. Liveness + face match against the document portrait defeats the most common driver-substitution pattern: one driver onboarded onto the platform, a different driver actually driving the load — caught at the assignment moment when the verification trigger fires.
Cross-platform continuity via audit pointers
Each verification produces a per-identity audit pointer. When a carrier or driver re-onboards (after suspension, after authority change, after a name change of record), the platform's onboarding system sees the prior pointer alongside the fresh-session result and can make the continuity decision the platform's compliance configuration calls for.
How it works
How a vendor-onboarding verification flows
Configurable per platform. Carrier principals are verified at signup; drivers can be verified at signup, at first trip, or per-trip depending on platform policy.
- Step 01
1. Trigger
Platform invokes Stile when the carrier principal or driver completes the onboarding form, accepts a trip, or hits a configured re-verification milestone.
- Step 02
2. Capture
Government ID (driver's license, CDL, state ID, or US-issued mDL) captured in-session. Selfie capture in the same session for liveness + face match. The user explicitly approves attribute release before any data leaves their device.
- Step 03
3. Verify
OCR + barcode cross-reference for physical credentials; ISO/IEC 18013-5 signature verification for mDL. Liveness scoring + face match against the document portrait. Spoof signals weighed into the eligibility decision.
- Step 04
4. Signed assertion
Signed webhook fires with the eligibility decision, jurisdiction, and audit pointer. The platform's compliance system reads the full identity assertion from the verification-result API and persists the audit pointer as the carrier or driver record's identity primary key.
Proof
Every trigger leaves a signed record.
A safety incident or insurance-claim question over who was actually driving arrives whenever it arrives. Every completed verification already has a signed identity assertion waiting.
Outcome
See the vendor onboarding flow for your platform.
Tell us where carrier and driver verification should trigger — we'll map the configuration.
Vendor onboarding scenarios + Stile coverage
The verification scenarios platforms most commonly trigger Stile against. Each scenario is configurable; the rule of thumb is that the higher the financial or safety exposure, the more frequent the re-verification cadence.
| Scenario | What Stile verifies | What's released to the platform |
|---|---|---|
| Carrier principal at vendor signup | Government ID + liveness + face match | Verified identity assertion + jurisdiction + audit pointer |
| Driver at vendor signup | Government ID (often CDL) + liveness + face match | Verified identity + age-tier eligibility + jurisdiction + audit pointer |
| Driver at first-trip assignment | Fresh session against the claimed identity | Trip-level audit pointer linked to the driver record |
| Driver at per-trip assignment (high-risk routes) | Fresh session at platform-policy threshold | Trip-specific audit pointer for the platform's safety log |
| Re-verification after suspension lift | Fresh session against the claimed identity | Audit pointer linked to the suspension record + the new active-vendor record |
| Authority-of-record change for the carrier | Fresh session against the newly claimed principal | Audit pointer chained to the prior verification-result for continuity |
FAQ
Carrier and driver identity verification — buyer questions
Same primitive (identity-of-record verification), different buyer. The load-board page describes the matching-platform context where carriers and brokers meet. This page covers any platform that vendor-onboards carriers or drivers as part of its onboarding flow. The capability is the same; the trigger surface and the audit-shape configuration differ.
Both. The default flow verifies the driver once at onboarding and references the audit pointer for subsequent trips. Platforms with higher per-trip exposure (high-value cargo, hazardous loads, regulated commodities) configure per-trip re-verification — a fresh Stile session at trip assignment that produces a trip-specific audit pointer. The platform's compliance team selects the cadence; Stile produces the verification primitive at whatever cadence is requested.
Driver substitution — where one driver's credentials get used by a different driver — is defeated by liveness + face match against the document portrait at the verification moment. If the verification trigger fires at trip assignment (rather than only at onboarding), the substitution is caught before the load moves. Catching substitution after the load has moved is a different problem (in-cab biometrics, telematics) that Stile does not address.
Stile's hosted widget embeds inside the existing onboarding flow as a discrete capture step — typically inserted after the corporate-authority form and before the platform's downstream onboarding decisions. Platforms that prefer to avoid the iframe embed can use the external-link option: send the verification link via the existing communication channel and receive the signed assertion via webhook. Either path produces the same audit pointer.
Per session: the signed webhook event, the eligibility decision, the jurisdiction, and the per-session audit pointer. The full identity assertion is reachable via the verification-result API. Source documents are retained per the operator's configured retention policy — see the security page for the per-account retention configuration. The audit pointer is the artifact the platform's compliance team produces during inquiry; the platform's separate corporate-authority and safety-score data sources combine with that artifact to form the full carrier or driver record.
Get started