KYC modules

Obsidian ships ThirdFactor Verify, a built-in, standards-based KYC engine: document verification, passive / colour-flash / 3D-action / gesture liveness, 1:1 face match, AML screening, proof of address, document AI, NFC chip reads, and agent video calls. No external verification SDK and no third-party verification credentials are involved — heavy inference runs on your own deployment's inference service.

Modules are the building blocks of a workflow (built in Console → Config → KYC Workflows). A session runs one workflow's enabled modules once. Each module has its own configuration, its own result on the session, and its own credit rate (set per tenant/module — there is no fixed public price).

Where each module runs

Not every module is applicant-facing. Three execution surfaces exist:

• Hosted flow — the applicant captures evidence inside the hosted WebView / iframe (document photos, selfie, OTP). Every client SDK supports these identically.
• Server-side — no applicant capture; the engine runs the check in the background from data already on the session.
• Native-only — needs a device radio the WebView cannot reach (NFC). Present in the iOS / Android / Flutter SDKs; on web it falls back to a server-side review.

Capability comparison

Every module maps to a ModuleResult with a status of approved, declined, in_review, or not_started. The table below adds what each module typically declines or reviews on, so you can see at a glance which checks carry real fraud-detection weight versus which ones just capture data.

Which modules do I need?

There is no universal answer — it depends on your regulatory obligations and fraud risk — but most integrations converge on one of three tiers. Use this as a starting point, then tune per jurisdiction with your compliance team.

Reading module results

Per-module outcomes come back on GET /v3/session/<id>/ and, in summary form, in decision_v3 on GET /v3/session/<id>/decision/. Each result carries a status (approved / declined / in_review / not_started), an optional score, warnings, and a data blob. The evidence checklist (/checklist/) tells you what was captured; the timeline (/logs/) tells you what happened and when.

{
  "session_id": "6f0e2b7a-…",
  "status": "in_review",
  "decision": "review",
  "decision_v3": {
    "id_verifications": [{ "node_id": "ID_VERIFICATION", "status": "approved", "score": 92.0, "warnings": [], "data": { "detected_type": "passport" } }],
    "liveness_checks": [{ "node_id": "LIVENESS", "status": "approved", "score": 87.5, "warnings": [], "data": { "method": "PASSIVE" } }],
    "face_matches": [{ "node_id": "FACE_MATCH", "status": "in_review", "score": 61.2, "warnings": ["similarity_below_minimum"], "data": {} }],
    "aml_screenings": [{ "node_id": "AML_SCREENING", "status": "approved", "score": 100, "warnings": [], "data": { "risk_level": "clear" } }],
    "nfc_verifications": [],
    "poa_verifications": [],
    "reviews": []
  },
  "reason": "similarity_below_minimum"
}

Every decision_v3 array key maps 1:1 to a feature key: id_verifications, liveness_checks, face_matches, aml_screenings, nfc_verifications, poa_verifications, phone_verifications, email_verifications, ip_analyses, database_validations, questionnaire_responses. Each entry carries node_id (so you can tell repeated instances of the same module apart in a graph workflow), status, score, warnings, and data.

Standalone tools

Several module engines are also exposed as stateless one-shot utilities under /v3/tools/* — AML check, face search, signature verify/search/enroll, document extract. They create no session and carry no audit trail. See Standalone tools.

Comparing execution modes

FAQ

Related