FAQs

Verify (kyc) performs field-level identity validation across supported global markets.

Verify Plus (kycplus) is available for U.S. identities and returns expanded identity resolution results, including matched identity attributes and source attribution, when provisioned.

Verify Plus requires a combination of identity inputs such as name, date of birth, national ID (or last four digits where applicable), address, phone, or email.

Providing multiple corroborating identity inputs improves match confidence and coverage. Required inputs depend on workflow configuration and provisioning.

No. Verify Plus is limited to U.S. identities. For international workflows, use Verify (kyc) where supported.

RiskOS™ attempts to resolve identity using the strongest combination of inputs available based on workflow configuration.

Commonly used input combinations include:

• National ID (where permitted)
• Name + date of birth
• Name + phone
• Name + address
• Date of birth + phone

Providing additional identity inputs generally improves resolution quality, but required fields vary by workflow and region.

If required inputs are missing or do not meet formatting requirements, certain modules (for example, Verify Plus) may not run.

Malformed fields can result in enrichment errors or cause workflows to follow alternate routing paths based on configuration.

Yes. Inputs should be UTF-8 encoded and consistently normalized.

Unescaped control characters or inconsistent formatting may result in validation or matching issues.

Verify and Verify Plus return per-field validation results that indicate whether submitted inputs met configured match criteria.

These values are used internally by RiskOS™ workflows to determine routing and outcomes and should not be treated as probabilistic risk scores or hard-coded thresholds.

Reason codes provide additional context associated with an evaluation outcome. They are informational and are already reflected in the final decision.

Definitions and detailed interpretation are available in the RiskOS™ Dashboard and may vary by workflow and provisioning.

Source attribution indicates the categories of data that contributed to the identity resolution process (for example, credit or government data).

It does not expose individual data sources or weighting logic.

If no identity record meets the configured resolution criteria, a matched entity may not be returned.

Verify that submitted inputs are complete, accurate, and formatted correctly, and review workflow routing behavior in the RiskOS™ Dashboard.

Common next steps include:

• Retry with normalized inputs (consistent casing, spacing, and formatting)
• Provide additional identity inputs when available
• Route to secondary verification methods such as Document Verification or manual review, based on your workflow design

You can submit a new evaluation request with the same inputs.

In production environments, repeated retries with unchanged input are discouraged. Use the Sandbox environment to validate test cases and workflow behavior.

• Use eval_id to trace execution in the RiskOS™ Dashboard and logs
• Review enrichment execution status and confirm required inputs were present
• Inspect reason codes, workflow tags, and routing outcomes to understand how the evaluation was processed
• Confirm feature-gated modules (for example, Verify Plus) are provisioned and enabled for the workflow

Escalate when:

• An expected enrichment does not run despite sufficient input
• Outcomes are inconsistent with workflow configuration
• Expected test cases produce unexpected routing results

When escalating, provide:

• eval_id
• referenceId (if applicable)
• Workflow name
• Request and response payloads (handled per your data-handling policies)
• Reproduction steps or logs, if available

No. Verify Plus is limited to U.S. identities. For international coverage, use Verify (kyc) where supported.

No. Verify and Verify Plus do not perform document or biometric verification.

Use Socure Predictive Document Verification for document and facial biometric workflows.

No. PEP and sanctions screening are handled by the Watchlist module.

Source freshness varies by data category and provisioning.

You can inspect contributing source categories via sourceAttribution, but individual source timestamps are not exposed.