Documentation
ThirdFactor Obsidian
Native identity, KYC, AML and onboarding — one hosted flow, client SDKs, server libraries, and a full REST API.
Obsidian is ThirdFactor's multi-tenant identity platform. It runs the whole verification journey — document capture, passive & active liveness, face match, NFC ePassport reads, AML/PEP screening and onboarding — behind one hosted flow, four native client SDKs, server libraries, and a REST API. No external verification vendor required.
Quickstart
Verify your first user in under 10 minutes.
SDKs
Python server plus Web, iOS, Android and Flutter clients.
Hosted flow
A no-code verification link; zero client code.
API reference
Sessions, applications, lists, webhooks.
How it works
Create a session (server-side)
Your backend calls POST /v3/session/ with your secret API key and gets a
hosted verification url.
Send the user through verification
Redirect to the url, or hand it to a native SDK. The flow runs the modules
your workflow enables — the server enforces them; they can't be skipped
client-side.
Receive the decision
A signed webhook delivers the authoritative decision
(approved · declined · manual_review). Or poll
GET /v3/session/<id>/decision/.
Every request — session creation, decision reads, tools — goes through the same tenant-scoped API key. There is no separate "verification vendor" credential to provision: the KYC engine, the AML screening, and the hosted UI all live inside your Obsidian deployment.
Ways to integrate
Hosted link
Redirect users to a hosted URL. No client code at all.
Native SDK
Embed the flow in your app; unlock NFC chip reading on mobile.
API + webhooks
Wire verification into your own onboarding backend.
Choose your integration path
All three paths run the identical server-side engine and the identical
hosted capture UI — /verify/<session_token>. The difference is entirely in
delivery: how the URL reaches the applicant, and whether your app gets
lifecycle events or a redirect.
| Hosted link | Native SDK | Direct API + webhooks | |
|---|---|---|---|
| Setup time | Minutes — one POST, one redirect | Under an hour — add a package, call verify() | Same as hosted link, plus your own webhook receiver |
| Client code required | ✅ None | ⚠️ A few lines (open flow, handle result) | ✅ None on the client — server-to-server only |
| NFC chip reading | ❌ Falls back to manual review | ✅ iOS / Android / Flutter only | ➖ Depends on which delivery method you pair it with |
| Lifecycle events in your app | ❌ Only a callback_url redirect | ✅ ready / completed / error / close over the bridge | ✅ Async via signed webhook |
| Where the result lands | Query params on callback_url (UX signal only) | SDK resolves one VerificationResult (UX signal only) | Webhook to your backend (authoritative) |
| Best for | Emailed/SMS links, QR codes, fastest MVP | In-app verification that feels native; mobile passport chip reads | Onboarding backends, core-banking integrations, custom UX around the result |
Tip
The client-side result — from a callback_url redirect or an SDK's
VerificationResult — is always a UX signal, never the source of truth.
Grant access or move money only after your backend confirms the decision from
the signed webhook or GET /v3/session/<id>/decision/. See
Webhooks.
What you can verify
| Module | What it does |
|---|---|
| Document verification | OCR, MRZ, barcode, authenticity & tamper checks across passports and local IDs. |
| Liveness | Passive, colour-flash, or 3D-action — server-enforced. |
| Face match | 1:1 selfie ↔ document, plus 1:N face search. |
| NFC | Reads the ePassport/eID chip on mobile and passively authenticates it. |
| AML / PEP | Sanctions, PEP and watchlist screening (OpenSanctions + custom lists). |
| Proof of address | Address document capture + extraction. |
These map to workflow feature keys — ID_VERIFICATION, LIVENESS,
FACE_MATCH, NFC_VERIFICATION, AML_SCREENING, PROOF_OF_ADDRESS, and a
longer tail (AGE_ESTIMATION, DOCUMENT_AI, IP_ANALYSIS,
EMAIL_VERIFICATION, PHONE_VERIFICATION, and more) — configured per
workflow in Console → Config → KYC Workflows. See the full
module catalog.
Common use cases
The right module mix depends on your risk model and regulatory obligations — this is general guidance on what integrators in each space typically enable, not a fixed requirement.
| Industry | Typical need | Modules usually enabled |
|---|---|---|
| Fintech onboarding | Fast, low-friction account opening | Document, Liveness, Face match |
| Banking / regulated KYC | Full identity assurance + sanctions checks | Document, Liveness, Face match, AML/PEP, Proof of address |
| Marketplace seller verification | Confirm the seller is a real, matched person | Document, Face match, AML/PEP |
| Crypto exchange onboarding | Strong identity binding + ongoing screening | Document, Liveness, Face match, NFC, AML/PEP |
| Telecom SIM registration | Government-mandated subscriber identity | Document, Face match, Proof of address |
| Gig-economy driver verification | Repeatable identity + liveness re-checks | Document, Liveness, Face match |
Info
NFC is the strongest anti-spoofing signal available (it authenticates the chip cryptographically rather than trusting document images) but it requires a mobile SDK — it is not available through a browser-only hosted link. See SDKs → NFC.
Tip
New here? Start with the Quickstart, then pick an integration path in SDKs or the Hosted flow.
For AI tools
This site publishes an /llms.txt index and a full
/llms-full.txt dump so you can feed the docs straight into an
LLM. See AI context.