## Before you start

Make sure you have the following:

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

## How it works

Socure Deceased Check evaluates submitted identity inputs to assess whether an identity may be associated with a deceased individual.

Deceased Check:

- Evaluates identity attributes such as name, date of birth, and national ID
- Returns structured signals indicating potential deceased status

> 📘
>
> **Note**:
>
> Deceased Check is available for **U.S. identities only**.

### How Deceased Check fits into a workflow

In RiskOS™, workflows are built by connecting reusable components. Deceased Check 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

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

### Execution flow in RiskOS™

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

```
Input

Deceased Check

Routing logic

Decision
```

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

1. **Input**

You call the Evaluation API with identity attributes.

2. **Deceased Check enrichment**

RiskOS™ evaluates the inputs against available deceased records and returns structured signals.

3. **Routing logic**

The workflow evaluates deceased indicators and reason codes.

4. **Decision**

The workflow returns a final outcome (for example, **Accept**, **Review**, or **Reject**).

### Workflow components used by Deceased Check

Deceased Check uses a subset of standard RiskOS™ workflow components.

| Component | Purpose | Typical input | Output / What to use next |
| --- | --- | --- | --- |
| **Input** | Start an evaluation | Name, DOB, national ID | Workflow execution begins |
| **Enrichment** | Check deceased indicators | — | Deceased signals, reason codes |
| **Condition** | Branch based on signals | Deceased Check outputs | Route to appropriate path |
| **Decision Rule / Score Card** | Apply policy logic | Deceased Check signals | Pass/fail or escalation |
| **Decision** | Emit final outcome | Routed value | Accept / Review / Reject |

## Configure Deceased Check

### Configure inputs

Common inputs include:

- Name
- Date of birth
- National ID (full or partial, where permitted)

Ensure inputs are correctly formatted before submission. Exact requirements may vary by workflow configuration.

### Add Deceased Check 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 **Socure Deceased Check**.

### Configure routing and decisions

Deceased Check returns signals that indicate whether an identity may be associated with a deceased individual.

Common routing strategies include:

- Referring cases for additional review
- Applying step-up verification
- Allowing the workflow to proceed when no deceased indicators are present

Definitions and detailed interpretation of returned signals are available in the RiskOS™ Dashboard.

### 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.

**Input validation**:

Identity inputs (name, date of birth, national ID) are collected and passed consistently.

Date of birth values use valid ISO 8601 format and reject impossible dates.

**Routing and decisioning**:

Workflow routing reflects your intended handling of deceased indicators.

Cases with deceased-related reason codes (for example, `R907` or `R909`) are routed appropriately.

Review or fallback paths are clearly defined.

**Operational readiness**:

Deceased Check signals and reason codes are accessible to relevant teams.

Updated 3 months ago.