## Before you start

Make sure you have the following:

- Full 9-digit U.S. Social Security Numbers are required.
- Only U.S. Social Security Numbers are supported.
- Explicit user consent is required for each verification.
- Each consent is single-use.
- An active **Permitted Entity Certification (PEC)** is required.

To activate eCBSV, complete the following steps:

1. Complete the [SSA Financial Institution Registration](https://www.ssa.gov/dataexchange/eCBSV/).
2. Sign the **Permitted Entity Certification (PEC)**.
3. Provide Socure with your signed **PEC PDF**.
4. Provide a screenshot of your in-app consent flow.
5. Provide evidence of security controls (for example, a SOC 2 Type II summary).
6. Sign the required service agreement addendum with Socure.

Your Socure Account Manager and Solutions Consultant will guide you through this process.

## How it works

Socure connects directly to the SSA so you don’t have to. RiskOS™ submits verification requests on your behalf and returns results in a format that can be used directly within your workflows.

### eCBSV returns:

- Confirmation of whether the provided SSN matches the supplied name and date of birth
- An indicator if the SSN belongs to a deceased individual

Responses include reason codes that can be used to drive routing and decisioning logic.

### How eCBSV fits into a workflow

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

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

- Conditions
- Decision rules
- Rule score cards
- Manual review steps
- Final decisions

### Execution flow in RiskOS™

eCBSV runs synchronously as part of a RiskOS™ workflow. There is no user handoff or pause in execution once consent has been collected.

```
Input

eCBSV

Routing logic

Decision
```

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

1. **Input**  
   You call the Evaluation API with name, date of birth, SSN, and a user consent indicator.
2. **eCBSV enrichment**  
   RiskOS™ submits the verification request to the SSA and returns match results and reason codes.
3. **Routing logic**  
   The workflow evaluates match, no-match, or ambiguous responses.
4. **Decision**  
   The workflow returns a final outcome (for example, **Accept**, **Review**, or **Reject**).

### Workflow components used by eCBSV

eCBSV uses a subset of standard RiskOS™ workflow components.

| Component | Purpose | Typical input | Output / What to use next |
| --- | --- | --- | --- |
| **Input** | Start an evaluation | Name, DOB, SSN, user consent | Workflow execution begins |
| **Enrichment** | Verify identity with SSA | — | Match status, reason codes |
| **Condition** | Branch based on match results | eCBSV outputs | Route to appropriate path |
| **Decision Rule / Score Card** | Apply policy logic | eCBSV signals | Pass/fail or escalation |
| **Decision** | Emit final outcome | Routed value | Accept / Review / Reject |

## Configure eCBSV

### Add eCBSV to a workflow

1. In the RiskOS™ Dashboard, go to **Workflows** and create a new workflow or open an existing one.
2. On the workflow canvas, select the **plus (+)** icon.
3. Add an **Enrichment** step and select **eCBSV**.

### Configure inputs and routing

Common required inputs include:

- `given_name`
- `family_name`
- `dob`
- `national_id` (SSN)
- `userConsent`

You can configure routing logic to support both:

#### Upfront verification

Some organizations call eCBSV early in the workflow to validate SSA records before evaluating other signals.

**Considerations:**

- A match confirms individual field alignment with SSA records
- It does not confirm that the identity is cohesive or trustworthy
- SSA match tolerances are permissive and may allow synthetic combinations to pass

#### Step-up verification

More commonly, eCBSV is used later in the workflow to validate identities with:

- Low confidence scores
- Conflicting or anomalous signals

### 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 of the workflow before going live.

- Consent UX is implemented and shown to the user immediately before the request
- `userConsent: true` is included in all live payloads
- Consent timestamps are logged for auditing
- Permitted Entity Certification (PEC) registration is completed and active

Updated about 2 months ago.