RiskOS™ Dashboard Setup

Learn how to set up Socure Deceased Check in the RiskOS™ Dashboard to confirm deceased status.

Set up Deceased Check in the RiskOS™ Dashboard

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 for assistance.

A basic understanding of RiskOS™ workflows and components.
  • If this is your first time working with workflows, review the 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.


Execution flow in RiskOS™

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

flowchart LR
    A[Input]
    B[Deceased Check]
    C[Routing logic]
    D[Decision]

    A --> B --> C --> D

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.

ComponentPurposeTypical inputOutput / What to use next
InputStart an evaluationName, DOB, national IDWorkflow execution begins
EnrichmentCheck deceased indicatorsDeceased signals, reason codes
ConditionBranch based on signalsDeceased Check outputsRoute to appropriate path
Decision Rule / Score CardApply policy logicDeceased Check signalsPass/fail or escalation
DecisionEmit final outcomeRouted valueAccept / 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.