RiskOS™ Dashboard Setup

Learn how to set up Socure Verify or Verify Plus in the RiskOS™ Dashboard to confirm consumer identities.

Set up Verify or Verify Plus in the RiskOS™ Dashboard

Before you start

Make sure you have the following:

Access to the RiskOS™ Dashboard with the Verify or Verify Plus 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 Verify and Verify Plus are identity verification enrichments available in RiskOS™. They check identity inputs like name, date of birth, and national ID against authoritative sources to return a decision.

Both products return:

Verify
  • socureId: A consistent identifier that follows the user across sessions, products, and teams

  • reasonCodes: Structured insights about identity patterns contributing to the decision and how it aligns with your risk posture

  • fieldValidations: Field-level results that show which inputs (e.g. name, DOB) passed or failed verification

  • nationalId: US ONLY: When only the last 4 of the national ID are collected, we'll return the full 9 so you have the complete version on file in accordance with FinCEN standards.

Verify Plus
  • socureId: A consistent identifier that follows the user across sessions, products, and teams

  • reasonCodes: Structured insights about identity patterns contributing to the decision and how it aligns with your risk posture

  • fieldValidations: Field-level results that show which inputs (e.g. name, DOB) passed or failed verification

  • sourceAttribution: Identifies which authoritative sources contributed to the decision (e.g. credit bureau, government, utility data etc.)

  • bestMatchedEntity: Returns the closest matching identity record, including resolved identity attributes available to your account.


Feature flags and data eligibility

Some datasets used in Verify and Verify Plus require additional configuration or eligibility steps. These features are controlled by Socure's account team.

One example is the eCBSV service, a U.S. Social Security Administration (SSA) integration that verifies a person’s name, date of birth, and SSN against SSA records.

To use eCBSV:

  • Your organization must complete a registration and approval process with Socure and SSA.
  • A special consent disclosure and provisioning step must be completed before this service is active.
  • Your API request must include consent to trigger the eCBSV lookup.

Until all requirements are met, this data source won’t be active in your workflow - even if the Verify or Verify Plus module is in place. Once provisioned, eCBSV data is included automatically in the enrichment process. It can improve match coverage, but it does not alter the structure of the response. Learn more about eCBSV requirements and registration steps.


How Verify and Verify Plus fit into a workflow

In RiskOS™, workflows are built by connecting reusable components. Verify and Verify Plus are added as Enrichment steps.

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™

Verify and Verify Plus run synchronously as part of a RiskOS™ workflow. There is no user handoff or pause in execution.

flowchart LR
    A[Input]
    B[Verify / Verify Plus]
    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. Verify / Verify Plus enrichment
    RiskOS™ evaluates the inputs against configured data sources and match tolerances.

  3. Routing logic
    The workflow evaluates decisions, field-level results, and reason codes.

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


Workflow components used by Verify and Verify Plus

Verify and Verify Plus use a subset of standard RiskOS™ workflow components.

ComponentPurposeTypical inputOutput / What to use next
InputStart an evaluationIdentity attributesWorkflow execution begins
EnrichmentVerify identityDecision, reason codes, field validations
ConditionBranch based on resultsVerify outputsRoute to appropriate path
Decision Rule / Score CardApply policy logicVerification signalsPass/fail or escalation
DecisionEmit final outcomeRouted valueAccept / Review / Reject

Configure Verify or Verify Plus

Configure match tolerances

Verify and Verify Plus include configurable match tolerances that control how strictly identity attributes are evaluated.

These settings are applied at the account level and affect all Verify evaluations.

Examples include:

Field Type

Match Options

Default Behavior

Notes

Date of Birth

9 tolerance levels: from exact to ±1 year w/ digit swaps

Configurable

If exact-only.

National ID

Exact Partial (1-char diff) Fuzzy (2-digit transposition)

Exact

If fuzzy not enabled.

Address Line 2

Exact Fuzzy (unit ignored)

Exact

House number is always exact. Direction, suffix, and city are fuzzy

📘

Note:

Use these settings to align match strictness with your policy. Default is lenient - tighten only where needed.

Exceptions:

For international workflows, partial national IDs are not accepted. The U.S. is the exception - either the last four digits or the full nine-digit SSN can be used. When only the last four are submitted, an exact match is always applied. If the full SSN is provided, your account’s match settings determine whether exact or fuzzy matching is used.


Standard match settings

Field TypeMatch OptionsDefault BehaviorNotes
Given Name (First)Fuzzy onlyFuzzyFuzziness cannot be disabled
Family Name (Last or Surname)Fuzzy onlyFuzzyFuzziness cannot be disabled
House NumberExact onlyExactMatches local postal standards
Address Line 1 (Cardinal Direction, Street Name and Street Suffix)Fuzzy onlyFuzzyMatches local postal standards
Locality (city)Fuzzy onlyFuzzyMatches local postal standards
Major Admin Division(State)Exact onlyExactMatches local postal standards
Postal Code (ZIP)Exact onlyExactMatches local postal standards
PhoneExact onlyExactNot configurable
EmailExact onlyExactNot configurable

Set match tolerances for Socure Verify and Verify Plus on the Settings > KYC tab in the RiskOS™ Dashboard.

The settings configured on this page apply to all Socure Verify evaluations for your account.


Add Verify or Verify Plus to a workflow

  1. In the RiskOS™ Dashboard, go to Workflows and create a new workflow or open an existing one.
  2. Add an Enrichment step.
  3. Select one of:
    • Verify
    • Verify Plus

Configure inputs and routing

Typical required inputs include:

  • Name
  • Date of birth
  • National ID

Optional inputs may include feature-gated sources such as eCBSV.

Common routing strategies include:

  • Blocking or failing when required inputs are missing
  • Escalating to additional verification when identity signals conflict
  • Re-prompting users to correct or complete inputs
  • Routing edge cases to manual review

Reason codes and field validations can be used to inform these routing decisions.


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:

Names support short and Unicode values

Date of birth:

Dates of birth use ISO 8601 format and reject impossible dates

Address:

Addresses follow regionally aware validation rules

National ID:

National ID handling follows regional requirements

Phone and email:

Phone and email inputs are validated and possession-confirmed
Risk signals and routing:

Conflicting or incomplete identities are detected
Edge cases route to manual review
Exception handling:

Fallback logic exists when required inputs are unavailable
Third-party failures are handled gracefully
Operational readiness:

Verification results and reason codes are visible to relevant teams
Feature flags and fallback workflows are enabled