User Guides
Home

Configure an Age Assurance Workflow

Understand how an Age Assurance workflow orchestrates passive and active methods in a waterfall, and how routing conditions decide each step at runtime.

How Age Assurance works

Age Assurance is a configurable workflow that confirms whether a user meets an age threshold. It starts with passive, low-friction signals and escalates to active verification only when required.

Each method produces one of two outcomes:

  • A threshold result — isSuccess: true with Boolean threshold flags such as age18Plus, age21Plus, and age25Plus.
  • A no-result outcome — the method found no usable data, and the evaluation falls through to the next method.

Socure remains neutral on regulatory policy. Your workflow defines the state rules, thresholds, and escalation paths that apply to your business during implementation.


Available methods

An Age Assurance workflow can combine passive and active methods, or use a single method on its own.

Passive methods

Passive methods resolve an age threshold from existing identity signals and require no photo or document capture.

  1. Device-based assurance

    RiskOS™ matches a device to a historical identity in Socure's Identity Graph and infers an age threshold. Because it needs no user input, device-based assurance is typically the first method in a waterfall when jurisdiction rules allow it.


    • Input: device session token, captured by the Digital Intelligence SDK and passed in the request
    • Returns a result when the device is associated with a known identity.

  2. Phone-based assurance

    RiskOS™ resolves an age threshold from an identity linked to the phone number. A one-time passcode (OTP) can confirm the user controls the phone. Typically used when a device signal is unavailable.


  3. Email-based assurance

    RiskOS™ resolves an age threshold from an identity linked to the email address, with an optional OTP possession check. Typically used as an additional passive fallback.


    • Input: email address (optional name)
    • OTP runs only when an identity is found.

Active methods

Active methods estimate or read an age from a capture the user provides through the Predictive DocV Capture App. They run only when a passive method can't resolve age or a jurisdiction requires a capture. Both include liveness and injection checks.

  1. Selfie-based age estimation

    RiskOS™ estimates an age from a selfie and returns a threshold result with an accept, reject, or resubmit decision. Typically used where a document is not required.


    • Input: selfie image with consent

  2. Document + selfie verification

    RiskOS™ reads the age from a verified government document, with or without a selfie, and returns a threshold result with an accept, reject, or resubmit decision. Typically used where a jurisdiction requires a government document.


    • Input: government document (± selfie)
    • The date of birth is used internally and is not returned to your application.

How the waterfall works

A waterfall runs methods in sequence and escalates to the next only when a method returns no hit or has no input:

  • Workflows generally begin with passive methods.
  • Passive methods execute in the order configured for your workflow.
  • A successful threshold result ends the evaluation and returns a decision.
  • A no hit — or no matching input — falls through to the next method.
  • Active verification occurs only when required — when no passive method resolves age, or a jurisdiction mandates a capture.
flowchart TB
    A["Evaluation request received"] --> B["Run next passive method"]
    B --> C{"Threshold result returned?"}
    C -->|Yes| Z["Return final decision (ACCEPT / REJECT)"]
    C -->|No hit or no input| D{"Another passive method available?"}
    D -->|Yes| B
    D -->|No| E["Active verification (selfie or document)"]
    E --> Z

You aren't limited to a waterfall — you can cherry-pick a single method or run only the ones a use case needs. The exact sequence depends on the workflow configured during your implementation. Common patterns include:

  • Passive-only — device, phone, and email with no active fallback, for jurisdictions that accept passive assurance.
  • Passive with active fallback — escalate to a selfie or document when no passive method returns a result.
  • Active-only — a single selfie or document step, for jurisdictions that mandate a capture.

How routing works

Between steps, the workflow evaluates routing conditions — rules that read the request and prior results at runtime and decide which step runs next. Conditions evaluate several kinds of input.

Request inputs

Conditions branch on whether a request input is present or on its value — for example, whether a device signal, phone number, or email is available — to route to the matching method.

Method results

After a method runs, a condition reads its result — for example, whether isSuccess is true and the required threshold flag (such as age18Plus) is met — to end the evaluation, fall through to the next passive method, or escalate to an active method.

Jurisdiction rules

Conditions can read the user's location or state to apply the rules that govern your business in each jurisdiction — for example, allowing a passive-only flow in one state and requiring a document capture in another.

Customer-specific business rules

Custom fields you include in the evaluation request can steer routing to match your own business logic — for example, forcing a passive-only path or selecting document over selfie. Socure configures how these fields influence routing during your implementation, so use only the fields defined for your workflow.

💡

Tip:

Because conditions evaluate inputs and results at runtime, the same workflow can respond differently to each request — applying a jurisdiction rule or escalating to an active method based on what the request contains.


Related

Updated 2 days ago

Did this page help you?