The gap
A signup form field isn't proof of who's on the other end of a match.
A name field doesn't confirm the principal
Anyone can type a name into an onboarding form. Without a government-ID capture at signup, there's no way to confirm the principal signing up is the principal actually operating the account.
Uploaded credential images can belong to someone else
A stolen or borrowed ID uploaded at signup looks identical to a legitimate one to a manual reviewer. Liveness and face-match are what separate the two.
Identity-laundering surfaces after the fraud, not before
By the time a platform's fraud team notices a pattern of ghost accounts, the damage is done. A signed identity assertion at signup is what lets the pattern get caught earlier.
Capabilities
Identity verification for the principals on each side of a load-board match
Principal identity at signup
Government-issued ID captured in-session for the motor-carrier principal or broker authority signatory at the moment they sign up to the load board. OCR plus barcode cross-reference returns the credential's issuing state and a signed identity assertion the operator's onboarding system uses as a primary key.
Liveness + face match against the document portrait
The portrait on the captured ID is matched against an in-session selfie under passive liveness scoring. Defeats the most common identity-laundering pattern in logistics: someone else's credentials uploaded at signup by a different person, then used under a different identity inside the platform. Sub-second result, no UX detour.
Re-verification on identity-of-record changes
When the federal filing's principal-of-record changes (a new authority owner, a new MC# transfer), the load board can trigger a fresh Stile session against the new claimed identity. The audit pointer ↔ verification-result mapping lets the platform link the new session to the prior one for continuity.
How it works
How a principal verification flows on a load board
Configurable per platform. The default is at signup; some operators trigger verification at later onboarding milestones their compliance team selects.
- Step 01
1. Trigger
Platform invokes Stile when the motor-carrier principal or broker authority signatory completes the onboarding form. Trigger can also fire at later onboarding milestones the operator's compliance team selects.
- Step 02
2. Capture
Government ID (driver's license, 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 resolves the credential's issuing state and document number; 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 full identity assertion (legal name, DOB hash, document-number hash, jurisdiction) is reachable via the verification-result API for the operator's onboarding system to consume.
Proof
Every signup leaves a signed record.
A dispute over who was actually behind an account arrives whenever it arrives. Every completed signup already has a signed identity assertion waiting.
Outcome
See the onboarding flow for your load board.
Tell us where verification should trigger in your onboarding flow — we'll map the configuration.
Onboarding scenarios + Stile coverage
The verification scenarios load-board operators most commonly trigger Stile against. Each scenario can be configured independently — different ruleset, different threshold, different release attribute set.
| Onboarding scenario | What Stile verifies | What's released to the operator |
|---|---|---|
| Motor-carrier principal at signup | Government ID + liveness + face match | Verified identity assertion + jurisdiction + audit pointer |
| Broker authority signatory at signup | Government ID + liveness + face match | Verified identity assertion + jurisdiction + audit pointer |
| Driver registration on the platform | Government ID (often CDL) + liveness + face match | Verified identity + age-tier eligibility + jurisdiction + audit pointer |
| Authority-of-record change on the federal filing | Fresh session against the newly claimed principal | New audit pointer linked to the prior verification-result for continuity |
| Re-signup after account suspension | Fresh session against the claimed identity | Audit pointer the operator's onboarding system can compare against its suspension records |
| Periodic re-verification (per operator policy) | Fresh session at the configured cadence | Updated assertion + audit pointer chained to the prior session for the same vendor |
FAQ
Load-board operator verification — buyer questions
Operator-side. Stile produces the identity assertion (the human is who they claim to be); the FMCSA data — MC#, DOT#, authority status, insurance filings — is a separate dataset the operator's onboarding system consumes from the federal SAFER / L&I sources directly. Stile does not pull, sync, or distribute FMCSA records. The two are joined platform-side via the verification-result audit pointer keyed against the operator's vendor record.
Stile only verifies people. The authority — MC#, broker bond, operating status — is a corporate-level attribute the operator validates separately. What Stile contributes is the identity-of-record assertion for the human signing the federal filing or onboarding form: the principal-of-record for a motor carrier, the authority signatory for a broker, the driver for a driver registration. The operator joins those identity assertions to the corporate authority data to make its onboarding decision.
Yes via the returning-user pattern. The first verification produces a per-identity audit pointer; if the same principal verifies on a second platform under your operator account, Stile can return the prior audit pointer alongside a fresh-session result, letting the second platform's onboarding system make the cross-platform link. Cross-operator re-use is not enabled by default — that requires explicit operator-to-operator data-sharing configuration.
The defence is a combination: (a) liveness against the in-session selfie defeats credential-image upload by a non-principal; (b) face match against the captured document portrait defeats credential-swap fraud where someone else's ID is uploaded; (c) the per-identity audit pointer lets the platform's fraud team link new signups to suspended-account records. None of this catches every laundering pattern — it raises the floor against the most common ones.
Median ~3 seconds end-to-end on a modern smartphone for a document-capture flow: capture (1.5s) + server-side OCR/liveness/face-match (1.2s) + webhook delivery (~50ms). The latency mostly lives in the capture step, which the operator controls via the SDK's UI. Operator-side conversion testing typically shows signup drop-off concentrates at document capture, not the verification step.
Get started