Configure an Age Assurance Workflow

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.

• Input: phone number (optional name)
• OTP runs only when an identity is found. See One-Time Passcode (OTP).

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.

Yes

No hit or no input

Yes

No

Evaluation request received

Run next passive method

Threshold result returned?

Return final decision (ACCEPT / REJECT)

Another passive method available?

Active verification (selfie or document)

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.