Process KYC + Fraud + Watchlist Screening Results via API

Handle Direct API evaluation responses and route users based on ACCEPT, REJECT, and REVIEW decisions in the KYC + Fraud + Watchlist flow.

How to interpret the response

After creating an evaluation, use the response to determine how your application should route the user and continue the verification flow.

Your integration should not rely on a single field. Always evaluate decision + status + tags together when determining next steps.

  • decision → High-level outcome (ACCEPT, REJECT, REVIEW)
  • status → Whether the evaluation is complete (CLOSED, ON_HOLD)
  • tags → Why the evaluation reached this decision (used for routing + UX)

For the full response schema, see the Evaluation API Reference.


Evaluation flow

RiskOS™ evaluates signals in stages:

  1. Digital Intelligence (device risk)
    High-risk signals (for example, bots, emulators, or risky networks) may result in an immediate REJECT.

  2. Identity verification (Socure Verify)
    Validates identity attributes (name, DOB, SSN, address).

  3. Fraud & risk signals
    Sigma Identity Fraud and Sigma Synthetic Fraud evaluate fraud and synthetic identity risk. Watchlist Screening checks against global sanctions, PEP, and adverse media lists.

If no blocking risks are found, the evaluation completes. Otherwise, it may:

  • Reject immediately, or
  • Pause for step-up verification (for example, Document Verification)

Decision outcomes

DecisionStatusMeaningAction
ACCEPTCLOSEDPassed all checksContinue onboarding
REJECTCLOSEDFailed a critical checkStop or route to fallback
REVIEWON_HOLDAdditional verification requiredTrigger step-up (for example, DocV)

Outcome handling

ACCEPT

The user passed all checks.

{
  "decision": "ACCEPT",
  "status": "CLOSED",
  "sub_status": "Accept",
  "tags": []
}

What to do:

  • Continue onboarding.
  • Grant access or create the account.

REVIEW

The evaluation is paused pending additional verification.

Key signals:

  • decision: "REVIEW"
  • status: "ON_HOLD"
  • eval_status: "evaluation_paused"
{
  "decision": "REVIEW",
  "status": "ON_HOLD",
  "eval_status": "evaluation_paused",
  "tags": [
    "Email Risk Step Up",
    "Phone Risk Step Up",
    "Document Verification Triggered"
  ]
}

What to do:

  • Trigger step-up verification (for example, Document Verification).
  • Use data_enrichments to retrieve the DocV URL or token.
  • Resume the flow after the user completes the additional verification.

See Handle additional verification for the full step-up implementation flow.

Common REVIEW tags

These indicate why the evaluation triggered step-up:

  • Identity mismatch:

    DOB Does Not Match Step Up, SSN Verification Step Up, First or Last Name Does Not Match Step Up, First and Last Name Possibly Reversed Step Up

  • Data risk:

    Email Risk Step Up, Phone Risk Step Up, Address Risk Step Up, Input Address State or Zip Does Not Match Address On File Step Up

  • Fraud signals:

    Sigma Synthetic Step Up, Sigma Identity Fraud Step Up, Graph Intel Step Up

  • Other:

    Digital Intel Step Up, Watchlist Review

📘

Note:

REVIEW isn't a terminal outcome. It indicates the evaluation is paused and requires additional verification before RiskOS™ returns a final decision.

REJECT

The user failed a critical check.

{
  "decision": "REJECT",
  "status": "CLOSED",
  "sub_status": "Reject",
  "tags": [
    "Sigma Identity Fraud Reject"
  ]
}

What to do:

  • Stop onboarding.
  • Route to a fallback, manual review, or decline flow.

Common REJECT tags

  • High Risk Individual
  • Sigma Identity Fraud Reject
  • Verify Reject
  • SSN Does Not Match - Reject
  • Address is Invalid or Commercial or PO box or Prison - Reject
  • Watchlist Review
📘

Note:

Watchlist Review may appear in either a REVIEW or REJECT response depending on how the workflow resolves.


Route the user

Use decision as the primary routing field, then use status and tags to refine the user experience.

  • ACCEPT → Continue onboarding
  • REJECT → Route to fallback or decline flow
  • REVIEW → Handle additional verification
switch (data.decision) {
  case "ACCEPT":
    router.push("/success");
    break;

  case "REJECT":
    router.push("/review");
    break;

  case "REVIEW":
    router.push("/additional-verification");
    break;
}