## Overview

When the Consumer Onboarding workflow cannot auto-approve or auto-reject an applicant, it routes the evaluation through one or more step-up or review paths. This page covers how your integration detects, handles, and completes these flows.

## Decision routing

Every Consumer Onboarding evaluation produces a decision that determines the next action in your integration.

| Decision | Meaning | Your action |
| --- | --- | --- |
| `ACCEPT` | Low risk — all checks passed | Continue onboarding |
| `REJECT` | High risk — definitive fraud or compliance failure | Deny the application or route to a fallback |
| `REVIEW` | Elevated risk — step-up verification or manual review required | Detect the step-up type and launch the appropriate flow |
| `RESUBMIT` | Recoverable failure — retry input or document capture | Prompt the consumer to resubmit and re-evaluate |

> **Note:** `ACCEPT`, `REJECT`, and `REVIEW` are the standard RiskOS™ decisions. `RESUBMIT` is a custom decision configured for this Consumer Onboarding workflow and may not be present in other workflows. Confirm which decisions your workflow returns before handling them in your integration.

When the decision is `REVIEW`, inspect `tags`, `review_queues`, and `eval_status` to determine which step-up path the workflow selected.

## Escalation paths

Consumer Onboarding uses progressive verification: the workflow applies the least-friction step-up that matches the risk signal.

```
Low
Extreme
Elevated digital risk
Identity uncertainty
Elevated identity or fraud risk
Watchlist match
Inconclusive
Pass
Fail
Inconclusive
Evaluation submitted
Risk level
ACCEPT
REJECT
OTP step-up
eCBSV step-up
Predictive DocV step-up
Compliance review queue
Manual review queue
Result
```

### One-Time Passcode (OTP)

The workflow uses phone possession verification as part of onboarding. Digital Intelligence and phone risk signals influence how the workflow evaluates phone possession and downstream escalation risk.

- **Trigger**: Phone or digital risk signals indicate that the workflow should confirm possession of the claimed phone number.
- **Behavior**: The workflow sends a One-Time Passcode (OTP) to the consumer's phone number.
- **Outcomes**: Verified (proceed), failed/abandoned (reject).
- **Sync/Async**: The evaluation handles OTP synchronously within the flow.

For OTP configuration, see [One-Time Passcode (OTP)](https://help.socure.com/riskos/docs/one-time-passcode-otp).

### eCBSV

When identity mismatches or synthetic fraud signals require authoritative validation, the workflow steps up to eCBSV.

- **Trigger**: Sigma Synthetic or Verify Plus signals suggest identity uncertainty.
- **Behavior**: Validates SSN, name, and date of birth directly with the Social Security Administration.
- **Outcomes**: Confirmed (proceed), mismatch (reject or review).
- **Requirement**: The applicant must provide consent. US-only.

For eCBSV details, see [eCBSV](https://help.socure.com/riskos/docs/ecbsv).

### Predictive DocV step-up

When fraud risk is elevated but not conclusive, the workflow triggers document verification. This is an **asynchronous** step-up — the evaluation pauses until the consumer completes document capture.

- **Trigger**: Fraud suite signals indicate high (but not definitive) risk.
- **Behavior**: RiskOS™ pauses the evaluation and requests a government-issued ID and selfie.
- **Outcomes**: pass (the evaluation continues to any remaining fraud and compliance checks), `REJECT` (forgery/mismatch/liveness failure), `RESUBMIT` (poor quality), `REVIEW` (inconclusive). A passing document verification doesn't by itself produce a final `ACCEPT` — the workflow still completes its remaining steps before decisioning.

#### Detect the step-up signal

Check for both conditions in the evaluation response:

- `eval_status` is `"evaluation_paused"` or `status` is `"ON_HOLD"`.
- `data_enrichments` includes an object where `enrichment_provider` is `"SocureDocRequest"`.

#### Extract handoff assets

Locate the `SocureDocRequest` object and extract from `response.data`:

| Field | Purpose |
| --- | --- |
| `docvTransactionToken` | **Required.** Initialize the DocV SDK with this value. |
| `url` | **Optional.** Direct mobile redirect to the Capture App (Web SDK and Hosted Flows). |
| `qrCode` | **Optional.** Base64 PNG for desktop-to-mobile handoff (Web SDK only). |

JSON

```json
{
  "eval_id": "500c6b88-9f5c-4d62-9422-163a59a343fe",
  "decision": "REVIEW",
  "status": "ON_HOLD",
  "eval_status": "evaluation_paused",
  "data_enrichments": [
    {
      "enrichment_provider": "SocureDocRequest",
      "response": {
        "data": {
          "docvTransactionToken": "70c6a4bc-f646-4c6a-94c1-9cd428e356ef",
          "url": "https://verify.socure.com/#/dv/70c6a4bc-f646-4c6a-94c1-9cd428e356ef"
        }
      }
    }
  ]
}
```

#### Complete the handoff

1. **Persist** the `eval_id` and `docvTransactionToken` for later correlation with the webhook result.
2. **Return** the token to your client-side application.
3. **Launch** the [DocV SDK](https://help.socure.com/riskos/docs/docv-sdks) or [Hosted Flow](https://help.socure.com/riskos/docs/hosted-flows) to present the document capture UI.

> **No resubmit:** Treat DocV as a one-time step-up. If the step-up fails, RiskOS™ completes the evaluation and delivers the final decision (typically `REJECT`) via webhook. Route the user to your fallback flow.

#### Receive the final decision

After document capture completes, RiskOS™ resumes the evaluation asynchronously. The final result arrives via the `evaluation_completed` [webhook event](https://help.socure.com/riskos/docs/webhooks).

JSON

```json
{
  "event_type": "evaluation_completed",
  "event_id": "3b31289c-2d4a-4107-80bc-dda63031d5a0",
  "event_at": "2025-07-17T01:20:01Z",
  "data": {
    "eval_id": "11111111-2222-3333-4444-555555555555",
    "decision": "ACCEPT",
    "status": "CLOSED",
    "eval_status": "evaluation_completed"
  }
}
```

Use the `eval_id` to correlate the webhook with the original evaluation. Route the user based on the final `decision`:

- `ACCEPT` → Continue onboarding
- `REJECT` → Route to fallback or denial flow

For webhook configuration, see [Webhooks](https://help.socure.com/riskos/docs/webhooks).
For DocV webhook details, see [DocV Webhooks](https://help.socure.com/riskos/docs/docv-receive-results).

### Watchlist and compliance review

When the Watchlist enrichment detects potential sanctions, PEP, or adverse media matches, the evaluation routes to a compliance review queue.

- **Trigger**: Global Watchlist returns potential matches.
- **Behavior**: The workflow tags the evaluation (for example, "Watchlist Review") and routes it to a configured review queue (for example, "Compliance").
- **Resolution**: A compliance analyst reviews the match in the RiskOS™ Dashboard and issues a final decision.

### Manual review

When risk signals are inconclusive across multiple enrichments, the evaluation routes to manual review.

- **Trigger**: Conflicting or borderline signals that don't meet auto-approve or auto-reject thresholds.
- **Behavior**: The workflow routes the evaluation to a configured review queue in the RiskOS™ Dashboard.
- **Resolution**: An analyst reviews enrichment results, reason codes, and tags, then issues a final decision.

## Progressive verification

Consumer Onboarding applies step-ups progressively. Early, low-friction checks reduce the population that reaches high-friction steps:

1. **Digital Intelligence** filters bots and risky devices.
2. **Allow/Deny lists** filter known entities.
3. **Phone Risk + OTP** verify phone possession.
4. **Verify Plus + Sigma Synthetic** confirm baseline identity.
5. **eCBSV** provides authoritative SSN validation for uncertain cases.
6. **Fraud enrichments** aggregate multi-signal fraud risk.
7. **DocV** applies biometric verification for high-risk cases.
8. **First-Party Fraud + Watchlist** complete post-verification compliance.

Each step narrows the funnel. The workflow minimizes the number of evaluations that require high-friction verification steps such as Predictive DocV or manual review.

## Operational recommendations

- **Staff review queues for expected volume.** Monitor review queue depth in the RiskOS™ Dashboard and adjust analyst capacity based on the review-to-total evaluation ratio.
- **Set SLAs for manual review resolution.** Unresolved reviews create a poor consumer experience. Define target resolution times for each review queue.
- **Handle DocV step-up timeouts.** If a consumer doesn't complete document capture within a reasonable window, route them to a fallback flow rather than leaving the evaluation indefinitely paused.
- **Monitor escalation rates.** If a disproportionate number of evaluations route to step-up or review, revisit your workflow configuration — threshold tuning or enrichment ordering may reduce unnecessary escalations.
- **Log all routing signals.** Persist `tags`, `review_queues`, `reason codes`, and `eval_status` transitions for audit and analytics.

## Common issues

Excessive evaluations routing to review

If a high percentage of evaluations route to `REVIEW`, check your workflow's routing conditions and thresholds. Common causes include overly sensitive reason code lists, missing enrichments that would provide disambiguating signals, or misconfigured conditions.

DocV step-up not triggering

Verify that Predictive DocV is enabled in your workflow and that the `docv` configuration object is included in your evaluation request. Check that the fraud suite enrichments are returning signals that would trigger the DocV condition.

Webhook not received after DocV completion

Confirm that your webhook endpoint is registered in the RiskOS™ Dashboard under **Developer Workbench > Webhooks**. Verify that the endpoint is reachable from Socure infrastructure and returns a 2xx response. Check the webhook delivery logs in the Dashboard for failed deliveries.

Evaluation stuck in paused state

If an evaluation remains in `evaluation_paused` for an extended period, the consumer likely did not complete the DocV step-up. Implement a timeout in your integration to detect stale paused evaluations and route the consumer to a fallback flow.

Unexpected REJECT after step-up

A `REJECT` after DocV typically indicates document forgery, liveness failure, or a data mismatch between the document and the submitted PII. Review the `documentVerification` enrichment response for reason codes that explain the rejection.

## FAQs

Can I customize which step-up path is triggered?

Yes. Step-up routing uses conditions and rules in your workflow configuration. You can adjust thresholds, add conditions, or reorder enrichments to change when DocV, eCBSV, or OTP runs. See [Configure the Workflow](https://help.socure.com/riskos/docs/configure-consumer-onboarding-workflow).

What happens if the consumer fails the DocV step-up?

RiskOS™ completes the evaluation and delivers the final decision via webhook. Typically, a failed DocV step-up results in a `REJECT` decision. Your integration should route the consumer to a fallback or manual process.

Can a single evaluation trigger multiple step-ups?

The workflow may apply multiple sequential checks (for example, OTP then DocV), but each step-up resolves before the next is triggered. The evaluation pauses only once for asynchronous steps like DocV.

How do I distinguish a DocV step-up from a compliance review?

A DocV step-up sets `eval_status` to `"evaluation_paused"` and includes a `SocureDocRequest` enrichment. A compliance review sets `decision` to `"REVIEW"` with `eval_status` as `"evaluation_completed"` and routes to a review queue (visible in `review_queues`).