Capabilities
One API for identity, KYC, and onboarding
Configure which evidence each flow requires, capture it through the hosted widget, and consume one signed identity assertion server-side.
What is identity verification? Identity verification confirms that a person is tied to a trusted credential and is present for the session. Stile checks document authenticity, liveness, and face match server-side, then returns a normalized signed assertion the application can act on. Identity verification is the broad case; age verification is the narrow configuration that returns only the age tier.
KYC and onboarding
One SDK covers customer KYC, business-representative verification, marketplace seller onboarding, and high-trust signup. The merchant configures which evidence is required per flow without integrating separate document, liveness, and fraud vendors.
Fraud and risk signals
Face match against the document portrait, hologram and tamper checks, device and capture-channel signals, and synthetic-identity detection. Risk signals are scored server-side and folded into the signed identity assertion the merchant receives.
Drop-in across regulated industries
The same session API powers identity flows for fintech onboarding, crypto exchange signup, marketplace seller verification, and lending applications. One signed webhook, one set of retention semantics, no reconciling four vendors when something goes wrong.
Verification inputs
Identity inputs normalized into one signed result
Identity verification varies by use case, but the integration shape stays consistent: request the evidence, let Stile verify it server-side, receive one signed assertion. Below is what Stile checks per input and what the merchant gets back.
| Input | Checked by Stile | Returned signal | Merchant receives |
|---|---|---|---|
| Document | OCR · barcode · MRZ · issuer format · hologram | document.verified | Normalized assertion, not raw extraction output |
| Selfie | Passive liveness · anti-spoof scoring | liveness.passed | Decision and audit pointer; no raw biometric |
| Face match | Document portrait matched to presenter | face_match.matched | Match result bound to the session ID |
| Fraud signals | Device · capture channel · synthetic identity | risk.score | Numeric score and category, not raw signals |
| Credential (mDL) | ISO/IEC 18013-5 signature verification | credential.verified | Only the attributes the wallet released |
How it works
How identity verification works
Three steps. Create a session, collect the configured evidence, receive a signed identity assertion.
Capture
The merchant creates a session. The hosted iframe collects the document and presenter evidence in one flow.
Verify
Document authenticity, passive liveness, and face match run server-side. The user never handles the final decision.
Signal
A signed webhook delivers the outcome. Raw PII stays in Stile; verify the signature before acting.
Privacy
Release the minimum identity needed, nothing more
Capture runs in the hosted widget and verification runs server-side. The merchant receives one signed event with the decision, the evidence summary, and an audit pointer rather than reconciling separate document, liveness, and fraud-provider responses.
What the merchant receives
The signed webhook carries the session outcome (status, type, current_method, jurisdiction, verification_result). Raw PII (name, date of birth, document number), document images, and biometric templates never leave Stile in the webhook; an authenticated evidence-bundle API is available when an investigator needs them.
Attribute disposition
- status
- returned
- type
- returned
- current_method
- returned
- jurisdiction
- returned
- verification_result
- returned
- raw_pii
- never
- document_image
- never
- biometric_template
- never
Audit trail
Proof for the identity decision that was made
HMAC-SHA256-signed webhooks plus a verifiable audit chain. Counsel and compliance can see which evidence was checked, which fraud signals were weighed, what was decided, and when the signed event was delivered.
What you can hand to compliance
Every completed identity session records the evidence captured, the fraud signals evaluated, the verification result, the timestamp, and the signed event delivered to your system. The audit pointer resolves back to the full session record without exposing raw biometrics.
Outcome
See the identity assertion your stack would receive.
Tell us your onboarding flow — we'll map the configuration.
FAQ
Identity verification, the parts buyers ask about
The compliance platform tracks the regimes that apply to identity verification: FinCEN customer identification rules, GLBA safeguards, BSA program requirements, EU eIDAS, the UK Money Laundering Regulations, and state-level KYC supplements. Stile maps each regime to the evidence requirements it imposes (document plus liveness for most fintech flows; document plus liveness plus address proof for higher-risk regimes) and returns the right verification configuration per session. Coverage changes ship through the same Stile API surface; merchants do not redeploy when a rule changes.
Identity verification is one component of a KYC program. It confirms the user is who they claim to be and that the document is genuine. KYC adds the customer-due-diligence layer on top: sanctions screening, PEP screening, source-of-funds inquiry, and ongoing monitoring. Stile ships identity verification today; the signed webhook carries the verification outcome (status, type, current_method, jurisdiction, verification_result) so downstream KYC tooling has the decision and the audit pointer. Raw PII (name, date of birth, document number) stays in Stile and is retrievable through the authenticated evidence-bundle API when an investigator needs it.
Government-issued documents from 200+ jurisdictions (passports, driver's licenses, national IDs, residence permits), plus mobile driver's licenses for the US states that issue them. The merchant configures which credential types are acceptable per flow; passport-only flows for cross-border onboarding and document-or-credential flows for high-trust marketplaces are both first-class configurations.
Yes. The session resolves the jurisdiction from the credential the user presents, applies the per-jurisdiction ruleset (which fields are required, which liveness threshold applies, which fraud signals are weighted higher), and returns a single signed-webhook result. The merchant does not pre-select a country; the SDK auto-routes.
Same session API, same signed-webhook shape. The only difference is the configured ruleset and the fields populated in the response. Age verification populates `age_tier` (e.g. min_age_21) and the jurisdiction. Identity verification populates `current_method`, `jurisdiction`, and a `verification_result` object (method, confidence, identity_verified, face_match_passed). Raw PII is never in the webhook for either flow; both bind to the same session ID and the same evidence-bundle API. See /age-verification for the narrow age-tier flow.
Get started
Stop integrating four identity vendors
Tell us the onboarding flow you're building, the credentials you accept, and the jurisdictions you operate in. Stile will map your KYC or marketplace use case to an identity verification flow your team can integrate and your compliance team can review.
