## Before you start

Make sure you have the following:

Access to the RiskOS™ Dashboard with the **Prefill** enrichment 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.

> 📘  
> **Note:**  
> Prefill accelerates form-fills with verified identity data, while Advanced Prefill adds real-time risk intelligence to stop fraud and maximize conversion. For details on Advanced Prefill setup, refer to the [Advanced Prefill Solution Guide](https://help.socure.com/riskos/docs/onboarding-with-advanced-prefill).

## How it works

Socure Prefill is an identity enrichment available in RiskOS™. It evaluates provided PII and returns best-matched identity attributes to pre-populate forms and reduce user effort.

Prefill helps you:

- Reduce onboarding friction
- Improve form completion rates
- Normalize identity data early in the workflow
- Support downstream verification and risk evaluation

Prefill returns structured identity attributes that can be surfaced directly to the user interface or passed downstream to other workflow steps.

### How Prefill fits into a workflow

In RiskOS™, workflows are built by connecting reusable components. Prefill is added as an **Enrichment** step.

Once the enrichment runs, its outputs are available to downstream workflow components, including:

- Conditions
- Decision rules
- Manual review steps
- Final decisions

For more detail on these components, see [Workflow Steps](https://help.socure.com/riskos/docs/workflow-steps).

### Execution flow in RiskOS™

Prefill runs synchronously as part of a RiskOS™ workflow. There is no user handoff or pause in execution.

```
Input

Prefill

Routing logic

Decision
```

At a high level, the execution flow looks like this:

1. **Input**  
You call the Evaluation API with available PII attributes.

2. **Prefill enrichment**  
RiskOS™ evaluates the input and returns best-matched identity attributes.

3. **Routing logic**  
The workflow evaluates whether Prefill results are present.

4. **Decision**  
The workflow proceeds based on configured outcomes (for example, **Accept**, **Resubmit**, or continue evaluation).

### Workflow components used by Prefill

Prefill uses a subset of standard RiskOS™ workflow components.

| Component | Purpose | Typical input | Output / What to use next |
| --- | --- | --- | --- |
| **Input** | Start an evaluation | Partial identity attributes | Workflow execution begins |
| **Enrichment** | Resolve identity attributes | — | Prefilled identity data |
| **Condition** | Branch based on Prefill result | Prefill response presence | Route to next step |
| **Decision** | Emit workflow outcome | Routed value | Accept / Resubmit |

## Configure Prefill

### Add Prefill to a workflow

1. In the RiskOS™ Dashboard, go to **Workflows** and create a new workflow or open an existing one.
2. Add an **Input** step (custom input configuration may require assistance from Socure).
3. Add an **Enrichment** step and select **Socure Prefill**.

> 👍  
> **Tip**:  
> In international markets, consider pairing Prefill with **Phone Risk** to improve confidence when verifying identities across fragmented data sources.

### Configure routing and decisions

Use a **Condition** step to evaluate whether Prefill results are returned.

A common configuration:

- Condition: `socure_prefill_response` **is set**
- Outcomes:
  - **Accept**: Prefill successful
  - **Resubmit**: Prefill unavailable or incomplete

### Save and publish

Once your workflow is configured, publish it to go live.

## Workflow testing checklist

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

**Name**

Accepts 1–2 character names

Allows Unicode and foreign characters

Handles applications containing multiple names

**Address**

Parsed to a standard schema

Validated with an address provider (for example, USPS or Loqate)

Applies regionally aware rules for global address formats

**SSN / ITIN**

Supports last four digits or full SSN, with fallback to ITIN where applicable

**Phone number**

Validated in E.164 format

**Email**

RFC 5322–compliant format

Inbox deliverability validated

Updated 3 months ago
