## Before you start

Access to the RiskOS™ Dashboard with the **Advanced Prefill** solution enabled.

- Your account owner or administrator can enable this for you. If you're unsure who to contact,
[reach out to support](mailto:support@socure.com) for assistance.

A basic understanding of RiskOS™ workflows and components.

- If this is your first time working with workflows, review the
[Workflow Overview](https://help.socure.com/riskos/docs/workflow-overview)
to understand inputs, enrichments, routing logic, and decisions.

## How Advanced Prefill works

Advanced Prefill is a **data disclosure gate** that runs before [Consumer Onboarding](https://help.socure.com/riskos/docs/consumer-onboarding). It determines whether verified identity data can safely be shown to the end user by evaluating device, phone, and possession signals. It does not perform KYC or fraud checks.

The workflow may:

- **ACCEPT** the request — Return prefilled identity data for the user to review and confirm.
- **REJECT** the request — Withhold identity data. The user enters information manually.
- place the evaluation **ON_HOLD** — Pause for OTP verification before reaching a final decision.

> 📘
>
> **Note**:
>
> Advanced Prefill decisions are **data disclosure decisions**, not final onboarding decisions. [Consumer Onboarding](https://help.socure.com/riskos/docs/consumer-onboarding) makes the final KYC and fraud determination after the user reviews and submits their information.

## Execution flow

Advanced Prefill runs with **conditional asynchronous steps** — the workflow pauses only when OTP verification is required.

1. ### Collect minimal input

Collect the following minimum input to begin the flow:
   - Digital Intelligence session token
   - Phone number
   - Date of birth

2. ### Call the Evaluation endpoint

The RiskOS™ Evaluation endpoint receives the input data and triggers the Advanced Prefill workflow.
The workflow orchestrates device, phone, and possession checks to determine if verified data can be disclosed.

3. ### Digital Intelligence

[Digital Intelligence](https://help.socure.com/riskos/docs/digital-intelligence) collects device, network, and behavioral telemetry to assess session risk.
   - **Reject** if there is an extremely high device or session risk signal.
   - **Proceed** if the session presents a trusted or low-risk digital profile.

**Why it's here:** Executed first to filter out risky devices and sessions before exposing any identity data.

4. ### Allow / Deny List

Checks identifiers such as email, phone, device, or IP address against trusted and fraudulent repositories.
   - **Reject** if any identifier matches a known fraudulent entry.
   - **Proceed** if the identifier is trusted or not found on any restricted list.

**Why it's here:** Placed after Digital Intelligence to filter out known bad actors before more expensive checks.

5. ### Phone Risk and SIM Swap

[Phone Risk](https://help.socure.com/riskos/docs/phone-riskscore) evaluates the phone number's legitimacy, tenure, and carrier risk. SIM Swap detects recent SIM changes on major U.S. carriers.
   - **Reject** if the phone shows extremely high risk or a recent SIM swap.
   - **Proceed** if the phone is trusted and demonstrates normal ownership behavior.

**Why it's here:** Validates the phone number before attempting possession verification.

6. ### Possession verification (SNA → OTP)

[Silent Network Authentication (SNA)](https://help.socure.com/riskos/docs/silent-network-authentication) passively verifies phone possession through carrier signals. If SNA fails or is unavailable, the workflow falls back to
[OTP](https://help.socure.com/riskos/docs/one-time-passcode-otp).
   - **Proceed** if SNA succeeds.
   - **ON_HOLD** if SNA fails — the workflow pauses until OTP verification completes.
   - **Reject** if possession verification fails or is abandoned.

**Why it's here:** Confirms control of the phone number to prevent unauthorized data disclosure.

7. ### Prefill enrichment

Retrieves verified identity data from Socure's Identity Graph based on the confirmed phone number and date of birth. The returned profile may include name, address, email, and national identifiers.
   - **Proceed** if identity data is returned.
   - **Reject** if no matching identity data is available.

**Why it's here:** Runs after possession verification to ensure data is only returned for verified phone owners.

8. ### Phone Risk re-check

Validates name–phone correlation using the identity data returned by the Prefill enrichment.
   - **Proceed** if the name on the phone record matches the prefilled identity.
   - **Reject** if there is a significant mismatch.

**Why it's here:** Final cross-check to ensure the prefilled identity belongs to the phone number owner.

9. ### Data disclosure decision

Consolidates all workflow results into a final outcome:
**ACCEPT**, **REJECT**, or **ON_HOLD** (pending OTP).

After the user reviews or enters their information, initiate a new
[Consumer Onboarding](https://help.socure.com/riskos/docs/consumer-onboarding) evaluation for full KYC and fraud checks.

## Asynchronous behavior

Advanced Prefill uses a **pause-and-resume execution model** when OTP verification is required.
- The workflow enters `ON_HOLD` when SNA fails and OTP is needed.
- There is no API to force continuation — the workflow resumes automatically when OTP succeeds, fails, or expires.
- Your integration resumes the evaluation by sending a `PATCH /api/evaluation/{eval_id}` with the OTP code.

**Consumer Onboarding must not start until Advanced Prefill reaches a terminal state** (`ACCEPT` or `REJECT`).

## Workflow components

Advanced Prefill uses standard RiskOS™ workflow components.

| Component | Purpose |
| --- | --- |
| Input | Collect minimal identity and session data |
| Enrichment | Evaluate device, phone, possession, identity |
| Rule Score Cards | Aggregate device and phone risk |
| Condition | Gate data disclosure and step-ups |
| On Hold | Pause workflow for OTP |
| Decision | Emit data disclosure outcome |

## What you can configure

Socure provides Advanced Prefill as a published workflow template. The decision logic and score thresholds are visible in your workflow and set to Socure-governed defaults that protect data disclosure integrity. The areas you can adjust directly in the Dashboard are listed in the following table.

| Area | Self-service in Dashboard | Notes |
| --- | --- | --- |
| Advanced Prefill decision logic | No | Visible in the template; defaults governed by Socure. Changes require a request. |
| Device and phone score thresholds | No | Visible in the template (for example, device and phone risk cutoffs); defaults governed by Socure. Changes require a request. |
| Consumer Onboarding routing | Yes | Route accepted, rejected, and review outcomes to your Consumer Onboarding workflow. |
| Step-up products (eCBSV, DocV) in Consumer Onboarding | Yes | Add or remove step-up enrichments in the downstream workflow. |
| Reason code handling | Yes | Map reason codes to your own routing and messaging. |
| Allow / Deny lists | Yes | Manage trusted and blocked identifiers. |

> 📘
>
> **Note**:
>
> The Advanced Prefill template exposes its rules and thresholds so you can review how the system makes decisions. To change the Socure-governed defaults, contact your Socure account manager.

## Carrier and enrichment coverage

Carrier-dependent enrichments (**SIM Swap** and **Silent Network Authentication**) require carrier approval and network participation.

| Region / Carrier type | SIM Swap | SNA | Fallback behavior |
| --- | --- | --- | --- |
| **U.S. (AT&T, Verizon, T-Mobile)** | Supported | Supported | Uses SNA first, OTP if needed |
| **U.S. MVNOs (Google Fi, Cricket)** | May not be eligible | May not be eligible | Falls back to OTP |
| **Non-U.S. carriers** | Not supported | Not supported | Uses OTP only |

When a carrier does not support SIM Swap or SNA, the workflow uses OTP to validate phone possession.

## Validation checklist

Verify these items before moving to integration:
- Advanced Prefill is enabled and provisioned by Socure
- Digital Intelligence SDK is integrated and generating valid session tokens
- API keys are generated and securely stored
- Allow / Deny lists are configured (if applicable)
- Consumer Onboarding workflow is enabled and configured
- Carrier approval is obtained for SIM Swap and SNA (if using supported U.S. carriers)
- Optional step-up products (eCBSV, Predictive DocV) are enabled for Consumer Onboarding
- Workflow is published and active in the target environment

## Best practices
- **Test end-to-end in Sandbox.** Verify that each decision path (`ACCEPT`, `REJECT`, `ON_HOLD`) triggers correctly before publishing to Production.
- **Lock verified inputs.** Keep `phone_number` and `date_of_birth` read-only after the Prefill step to prevent data inconsistency between workflows.
- **Plan for OTP fallback.** Design your UI to handle the `ON_HOLD` state. Most sessions where SNA is unavailable fall back to OTP.
- **Monitor prefill coverage.** Track the ratio of `ACCEPT` to `REJECT` decisions. A high rejection rate may indicate data coverage gaps for your user population.
- **Do not start Consumer Onboarding early.** Wait for Advanced Prefill to reach a terminal state before initiating the Consumer Onboarding evaluation.

## FAQs

Can I modify the Advanced Prefill workflow?

The logic before and including the Prefill step cannot be modified through self-service. This restriction protects the data disclosure gate. Contact your Socure account manager for changes. The Consumer Onboarding workflow that runs after Advanced Prefill is fully configurable.

Do I need carrier approval for SIM Swap and SNA?

Yes. SIM Swap and Silent Network Authentication (SNA) require carrier approval and are currently available for major U.S. carriers (AT&T, Verizon, T-Mobile). For unsupported carriers, the workflow falls back to OTP automatically.

Do I need to update my Terms and Conditions?

Yes. Mobile carriers require that references to Silent Network Authentication (SNA) and SIM-based verification are explicitly included in your Terms and Conditions for privacy compliance.

What happens if an enrichment is not provisioned?

If an enrichment is not provisioned for your account, the workflow adjusts behavior to ensure it completes. The `data_enrichments` array in the response shows a non-200 status code for skipped or failed enrichments.

## Related concepts

- [Consumer Onboarding](https://help.socure.com/riskos/docs/consumer-onboarding)
- [Workflow Overview](https://help.socure.com/riskos/docs/workflow-overview)
- [Workflow Steps](https://help.socure.com/riskos/docs/workflow-steps)
- [Evaluations](https://help.socure.com/riskos/docs/understanding-riskos#evaluations)
- [Decisions](https://help.socure.com/riskos/docs/understanding-riskos#decisions)
- [Signals & Attributes](https://help.socure.com/riskos/docs/understanding-riskos#signals--attributes)