Selfie Intelligence Setup

Configure a RiskOS™ workflow for Selfie Intelligence to match consumer selfies against government-issued ID photos using facial biometric analysis.

RiskOS™ Setup: Selfie Intelligence

Use this guide to assemble a RiskOS™ workflow for the Selfie Intelligence flow—what steps to add, what each step produces, and how to handle errors and resubmits.

The workflow follows the same shape as a standard Document Verification flow, with the flow-specific differences in the following sections.


What's different for this flow

  • What the consumer captures: a live selfie used for facial biometric analysis. Depending on your configured flow, the selfie is captured on its own or alongside a government-issued ID for face matching.
  • Liveness and trust signals: use this flow for age checks, liveness, and trust-and-safety use cases.
  • Configure the flow: select the Selfie Intelligence flow server-side through your Capture App flow configuration (config.use_case_key) or workflow setup. See Selfie Intelligence for the consumer experience and Create an Evaluation for request fields.

For the exact enrichment-object schema this flow returns, see the API Reference.


Before You Start

Make sure you have the following:

Access to the RiskOS™ Dashboard with the Predictive DocV enrichment enabled.
  • Your account owner or administrator can enable this for you. If you're unsure who to contact, contact support for assistance.
A published Capture App flow for your DocV flow type.
A basic understanding of RiskOS™ workflows and enrichment steps.

Execution Flow

Predictive DocV runs as an enrichment step in a RiskOS™ workflow. Because document capture happens on the consumer's device, the workflow pauses at the Document Request step and resumes automatically once capture finishes.

flowchart LR
    A[Input] --> B[Document Request]
    B -. user handoff .-> C[Capture App]
    C --> D[Document Verification]
    D --> E[Conditional Decision Logic]
    E --> F[Decision]
  1. Input — You call the Evaluation API with PII and optional DocV config.
  2. Document Request — The workflow pauses and returns a URL / QR / token (or sends SMS if enabled) for user handoff to the DocV Capture App.
  3. Document Verification — After the consumer completes capture, the workflow resumes, verifies the images, and returns DocV results.
  4. Image Request (optional but recommended) — Retrieves captured images and attaches them to the case in RiskOS™.
  5. Conditional Decision Logic — Routes based on the DocV decision, reason codes, document type, and other signals.
  6. Decision — Emits the final outcome (accept, reject, resubmit, review, or cancel).
📘

Note:

After Document Request, the workflow stays paused until the end user acts (opens the link/QR/SMS and completes capture) or the Document Request expires. There is no API to “force-continue” — RiskOS™ automatically resumes at Document Verification once capture finishes or the session expires.


Add DocV to a Workflow

  1. In the RiskOS™ Dashboard, go to Workflows and create a new workflow or open an existing one.
  2. On the workflow canvas, select the plus (+) icon.
  3. Add a Document Request enrichment step, then add a Document Verification enrichment step.
  4. (Recommended) Add an Image Request enrichment step to attach captured images to the case.
  5. Add Conditional Decision Logic and a Decision step to route on the DocV outputs.

After the enrichment is added, its outputs are available to all downstream workflow components.

📘

Note:

If your account has multiple DocV flows, there is typically an enrichment step for each flow (for example, Socure Document Request - Default Flow, Socure Document Request - No Selfie).


Required and Optional Inputs

DocV evaluates the consumer information provided through your workflow. Providing complete and accurate inputs improves extraction matching and verification confidence.

Required Inputs

  • data.individual.given_name — Consumer's first/given name
  • data.individual.family_name — Consumer's last/family name
  • data.individual.phone_number — Phone number in E.164 format
  • data.individual.address.country — Country code in ISO 3166-1 alpha-2 format

Optional Supporting Inputs

When available, include these fields to improve match accuracy and verification confidence:

  • data.individual.date_of_birth
  • data.individual.email
  • data.individual.address.line_1
  • data.individual.address.locality
  • data.individual.address.major_admin_division
  • data.individual.address.postal_code
  • data.individual.docv.config — Capture App behavior (language, send_message, redirect, document_type, use_case_key)

Omitting optional fields does not prevent execution, but extracted documentData is compared to input PII, so richer inputs strengthen the result.


Workflow Components Used by DocV

ComponentPurposeTypical inputOutput
InputStart an evaluationPII (name/DOB/address/phone), docv.config (language, send_message, etc.)Evaluation created; workflow begins
Document RequestCreate capture session & pauseURL / QR Code / docvTransactionToken (or SMS sent)
Document VerificationVerify uploaded imagesDocV decision, reasonCodes, documentData
Image Request (rec.)Attach images to the case (dashboard + API download)referenceId from DocV responseImages available in RiskOS™ & via download endpoint
ConditionApply your rulesDocV decision, reason codes, document type/countryRoute to final Decision step
DecisionEmit final outcomeRouted valueaccept / reject / resubmit / review / cancel

Common Decision Patterns

DocV returns a module decision plus reason codes rather than a numeric risk score. Use documentVerification.decision.value in conditions and decision rules to route evaluations. The following patterns are common starting points — adjust them to match your organization's fraud policy and risk tolerance.

Decision-Based Routing

ConditionSuggested ActionRationale
documentVerification.decision.value = acceptContinueDocument verified — proceed to the next workflow step
documentVerification.decision.value = reviewREVIEWInconclusive signals — route to manual review
documentVerification.decision.value = resubmitResubmitImage quality or usability issue — start a new evaluation
documentVerification.decision.value = rejectREJECTVerification failed or fraud signals present

Attribute-Based Routing

PatternSuggested Action
Disallowed documentType or unsupported issuing countryREJECT or REVIEW
Reason codes indicate glare, blur, or low image qualityResubmit
Expired document or consumer under your minimum ageREJECT per policy
Accepted document type and country with a clean accept decisionContinue

Error Handling

Errors can occur on the Document Request and Document Verification enrichment steps. Configure error handling in the workflow for these fields:

  • socure_doc_request_error is set
  • socure_docv_error is set

Common configurations:

  • On error, route to resubmit and add integration logic to initiate a new evaluation request.
  • On error, route to cancel and add integration logic to troubleshoot and initiate a new evaluation request.
  • Tag the case (for example, docv_error, docv_request_error, docv_verification_error) for filtering and reporting.

Resubmit Handling

A resubmit decision typically means a captured image prevented verification — a quality issue or a disallowed ID type, not necessarily fraud. Start a new evaluation so the consumer receives a fresh DocV transaction to recapture their images.

Recommendations:

  • Tailor the consumer messaging based on the returned reasonCodes (for example, use a different ID type, retake in brighter light).
  • Limit the number of retry attempts to avoid endless loops.
  • For streamlined re-attempt flows or policy nuances, contact your Solutions Consultant team.

Save and Publish

Once your workflow is configured, publish it to go live. After publishing, capture the workflow identifier you pass as workflow on the Evaluation API request.


Workflow Testing Checklist

Use this checklist to confirm accuracy, resilience, and completeness before going live.

PII inputs are collected and passed consistently
Country codes use the ISO 3166-1 alpha-2 format
The Document Request handoff (URL / QR / SMS) is surfaced to the consumer
Workflow routing on the DocV decision aligns with your fraud policy and risk tolerance
Error, resubmit, and review paths are clearly defined
The Image Request step is included so reviewers can view captured images

Related Enrichments

EnrichmentCombination pattern
Selfie IntelligenceAdd a live selfie for age, liveness, and trust checks
Selfie ReverificationRe-authenticate a returning consumer against a prior DocV headshot
Secondary Document CaptureCollect supporting documents such as proof of address
Digital IntelligenceLayer device and network signals onto the document decision

Related Concepts


Helpful Links



Did this page help you?