Configure a Consumer Onboarding Workflow
Before you start
Access to the RiskOS™ Dashboard with the Consumer Onboarding solution 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 Consumer Onboarding works
Consumer Onboarding is a configurable onboarding workflow that evaluates identity, fraud, and compliance signals within a unified onboarding workflow while escalating higher-risk users to additional verification steps only when required.
The workflow may:
- ACCEPT the applicant
- REJECT the applicant
- route the applicant to REVIEW
- request RESUBMISSION (a custom decision configured for this workflow; not all workflows return it)
- escalate the applicant to additional verification steps such as OTP, eCBSV, or Predictive DocV before a final decision is reached.
Execution flow
Consumer Onboarding runs synchronously, with conditional asynchronous steps (OTP, Predictive DocV) only when required.
Data collection
Collect the following minimum input to begin the flow:
- Digital Intelligence session token
- First name
- Last name
- Date of birth
- Last 4 of SSN
- Address
- Phone number
Call the Evaluation endpoint
The RiskOS™ Evaluation endpoint receives the input data and triggers the Consumer Onboarding workflow. The workflow orchestrates all enrichment and decision steps — across identity verification, fraud detection, and compliance screening — to produce a single decision output with traceable reasoning.
Digital Intelligence
Digital Intelligence collects device, network, and behavioral telemetry to compute helper variables for downstream risk scoring.
- Reject if there is an extremely high digital intelligence risk signal.
- Step-Up if a high digital intelligence risk signal is detected.
- Proceed if the session presents a trusted or low-risk digital profile.
Why it's here: Executed first to correlate device behavior with the applicant's identity and seed telemetry for subsequent fraud and compliance evaluations.
Allow / Deny List
Checks identifiers such as email, device ID, phone, or IP address against trusted and fraudulent repositories.
- Reject if any identifier matches a known fraudulent entry.
- Proceed if the identifier is trusted or not found on any restricted list.
Why it's here: Placed immediately after Digital Intelligence to filter out known bad actors before calling more computationally expensive services.
Phone Risk
Phone Risk analyzes the phone number's legitimacy, tenure, and exposure to risks such as SIM swaps, spoofing, or carrier anomalies.
- Reject if the phone shows extremely high risk.
- Proceed if the phone is trusted and demonstrates normal ownership behavior.
Why it's here: Used as an early ownership signal to verify the phone's authenticity before deeper KYC and risk checks occur.
Possession verification
OTP verifies possession of the claimed phone number as part of the onboarding flow.
- Step-Up to OTP when phone or digital risk signals indicate that possession should be confirmed.
- Proceed if phone possession is successfully verified.
- Reject if possession verification fails or is abandoned.
Why it's here: Confirms control of the phone number to prevent account creation using spoofed or stolen credentials.
Verify Plus + Sigma Synthetic (KYC / CIP)
Performs identity verification and synthetic fraud detection in tandem.
- Verify Plus validates name, date of birth, SSN, and address against authoritative data sources.
- Sigma Synthetic identifies patterns suggesting fabricated or stitched identities.
Why it's here: Executed early to confirm baseline identity legitimacy before invoking high-assurance checks like eCBSV or Document Verification.
eCBSV (Authoritative Step-Up)
eCBSV validates SSN, name, and date of birth directly with the Social Security Administration (SSA).
- Step-Up when synthetic or identity mismatches indicate a need for authoritative verification.
- Proceed when identity information aligns across all sources.
Why it's here: Provides the highest identity assurance, particularly for thin-file or new-to-country populations. Requires applicant consent.
Socure Fraud Suite
Combines signals from Phone Risk, Email Risk, Address Risk, Sigma Identity Fraud, Sigma Synthetic, and Graph Intelligence to evaluate third-party, synthetic, and networked fraud risk.
- Reject if any source indicates extremely high fraud or synthetic identity risk.
- Step-Up to Predictive DocV if high but not definitive fraud risk is detected.
- Proceed if all signals indicate a low or trusted risk level.
Why it's here: Identifies bad actors mid-sequence and determines whether higher-friction verification is necessary.
Predictive DocV Step-Up
Predictive DocV validates government-issued IDs and biometric selfies.
- Reject if document forgery, mismatch, or liveness failure is confirmed.
- Resubmit if document quality is insufficient.
- Manual Review if authenticity cannot be automatically verified.
- Proceed if the document and selfie match with high confidence. The evaluation continues to any remaining checks rather than accepting immediately.
Why it's here: Introduces targeted friction only for uncertain or high-risk cases.
Optional First-Party Fraud evaluation
Optional First-Party Fraud evaluation assesses verified identities for behavioral indicators such as dispute abuse or bust-out risk.
- Reject if the applicant exhibits extremely high first-party fraud indicators.
- Step-Up for manual review if elevated but inconclusive risk signals are present.
Why it's here: Conducted after verification to prevent downstream losses from genuine users acting in bad faith.
Watchlist Plus screening
Watchlist Plus screens the applicant against global sanctions, PEP, and adverse media databases.
- Step-Up for compliance review when potential watchlist matches are detected.
- Proceed if no relevant matches are found.
Why it's here: Final compliance checkpoint before decisioning to ensure AML and regulatory requirements are satisfied.
Final decision
Consolidates workflow results into a final outcome: ACCEPT, REVIEW, REJECT, or RESUBMIT, with reason codes and audit logs.
The workflow may also escalate applicants to additional verification steps such as OTP, eCBSV, or Predictive DocV before a final decision is reached.
Workflow components
Consumer Onboarding uses standard RiskOS™ workflow components.
| Component | Purpose |
|---|---|
| Input | Collect identity and session data |
| Enrichment | Run identity, fraud, and compliance checks |
| Rule Score Cards | Aggregate multi-signal risk |
| Condition | Route based on thresholds and conflicts |
| Manual Review | Human review for edge cases |
| Decision | Emit final outcome |
Configure Consumer Onboarding
Enable required enrichments
Your Socure account team provisions a standard Consumer Onboarding workflow that includes:
- Digital Intelligence
- Phone Risk
- OTP (possession verification)
- Email Risk
- Address Risk
- Verify Plus
- Sigma Synthetic Fraud
- Sigma Identity Fraud + Graph Intelligence
- First-Party Fraud
- Watchlist Plus
- eCBSV (optional, consent-gated)
- Predictive DocV (optional step-up)
Design your risk and friction strategy
Consumer Onboarding is designed to:
- Allow low-risk users to pass with minimal friction
- Apply step-ups only when signals are incomplete or conflicting
- Escalate to high-assurance verification for high-risk cases
Typical strategies include:
- Rejecting on extreme digital or fraud risk
- Stepping up to eCBSV or DocV for uncertain identity resolution
- Routing ambiguous cases to manual review
Configure routing and reason code lists
Reason codes drive all routing behavior. Each product must have its own configured reason code lists.
Examples:
- Verify Plus: Reject, Step-Up, Resubmit
- Sigma Synthetic / Identity Fraud: Reject and Step-Up
- Predictive DocV: Reject, Review, Resubmit
- First-Party Fraud: Review and Reject
- Watchlist: Review
Proper configuration ensures consistent routing, accurate case labeling, and clean downstream reporting.
Configure Allow / Deny lists
Optionally configure known trusted or fraudulent identifiers:
- Emails
- Phone numbers
- Devices
- IP addresses
These lists are evaluated early in the workflow.
Save and publish
Once configuration is complete, publish the workflow to go live.
Validation checklist
Verify these items before moving to integration:
- All required enrichments are enabled and provisioned
- Enrichment ordering matches the execution flow above
- Reason code lists are configured for each enrichment
- Review paths are configured for ambiguous cases
- Fallback routing exists for enrichment failures
- Escalation paths (DocV, eCBSV, OTP) are connected
- Allow / Deny lists are populated (if applicable)
- Workflow is published and active in the target environment
Best practices
- Order enrichments by cost and signal strength. Run inexpensive, high-signal checks (Digital Intelligence, Allow/Deny) before expensive ones (eCBSV, DocV).
- Avoid redundant routing rules. Each enrichment should have a clear, non-overlapping responsibility in the routing chain.
- Configure explicit fallback paths. If an enrichment times out or returns an error, the workflow should route to review rather than silently proceeding.
- Test routing in Sandbox. Verify that each routing branch (Accept, Step-Up, Review, Reject) triggers correctly with test personas before publishing to Production.
- Keep reason code lists aligned with downstream actions. Every reason code that triggers a step-up or review should have a corresponding handling path in your integration.
FAQs
Can I customize which enrichments are included?
Yes. Your Socure account team can add, remove, or reorder enrichments in the Consumer Onboarding workflow. You can also adjust routing logic and conditions in the RiskOS™ Dashboard.
What happens if an enrichment is not provisioned?
If an enrichment is not provisioned for your account, the workflow skips it and continues. The data_enrichments array in the response shows a non-200 status code for skipped or failed enrichments.
Can I run Consumer Onboarding with fewer PII fields?
Some enrichments require specific PII fields to produce results. Providing fewer inputs may reduce match accuracy or cause individual enrichments to return incomplete data. Consult the enrichment documentation for field requirements.