Skip to main content
Version: v3

Configure based on scenarios

The examples below show how different constraint profiles map to specific Verify configurations. They are illustrative—your configuration will depend on your risk tolerance, user motivation, and deployment context.

In-person, staff-assisted verification​

Constraints:

  • Staff are physically present during verification, eliminating screen and photocopy attacks
  • High false rejection cost: friction damages relationships with high-value or loyal customers
  • Fraud is unsophisticated and low-cost per incident
  • Manual intervention is available when a document is rejected

Industries: hotels, casinos, car rental, hospitality, age-gated venues

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "HighConversion",
      "verificationContext": "InPerson",
      "manualReviewStrategy": "Never"
    }
  }
}

verificationContext: InPerson disables screenPresenceSensitivity, photocopySensitivity, and generativeAiSensitivity by itself, so there is nothing left to switch off by hand. Those are exactly the attack vectors that staff presence rules out.

verificationPolicy: HighConversion relaxes what remains: portraitForgerySensitivity drops to Level1 and dataMatchSensitivity to Level4. It also raises imageAssessment.imageQualitySensitivity to Level6, so a poor capture is more likely to come back as a Retry that staff can act on than as a rejection.

manualReviewStrategy: Never keeps the verdict to Accept or Reject, because staff resolve edge cases on the spot rather than through a review queue.

High-conversion remote at physical locations​

Constraints:

  • App-based onboarding, but used at physical locations (malls, venues, transit hubs)
  • Low fraud risk and low fraud cost
  • High false rejection cost: a lost user costs more than the fraud it would have prevented
  • User motivation is low; any friction risks abandonment
  • Physical deployment makes printed photocopy attacks implausible in practice

Industries: micro-rental services, shared mobility (bikes, scooters), low-value asset tracking, vending

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "HighConversion",
      "verificationContext": "Remote",
      "manualReviewStrategy": "Never"
    },
    "settings": {
      "photocopySensitivity": "Disabled"
    }
  }
}

verificationContext: Remote keeps the liveness checks running.

photocopySensitivity: Disabled removes the photocopy check, which is not a realistic attack vector at physical locations.

Balanced remote verification​

Constraints:

  • Deployed remotely
  • Low to moderate fraud risk and cost per incident
  • False rejections carry a moderate business cost
  • Users are moderately motivated

Industries: credit unions, community banks, lower-risk account opening, membership services

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "Balanced",
      "verificationContext": "Remote",
      "manualReviewStrategy": "RejectedAndAccepted"
    }
  }
}
tip

All three values set here are the defaults, so sending no configuration at all behaves identically. Spelling them out is optional and, in this case, illustrative.

Accept expired documents​

Some regulations require accepting documents past their expiry date, others require rejecting them. rejectExpiredDocuments decides which happens. Set it explicitly rather than relying on the default:

configuration.json
{
  "verification": {
    "settings": {
      "rejectExpiredDocuments": false
    }
  }
}

High-assurance remote fraud prevention​

Constraints:

  • Deployed remotely
  • High fraud risk: fraudsters use fake documents to open accounts at scale
  • High fraud cost per incident; losses cannot be recovered through legal means
  • Users are motivated enough to tolerate moderate friction
  • False rejections are acceptable when they route to manual review

Industries: consumer lending, buy now pay later, fintech credit, short-term loans

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "HighAssurance",
      "verificationContext": "Remote",
      "manualReviewStrategy": "RejectedOnly"
    }
  }
}

manualReviewStrategy: RejectedOnly sends documents that are on the verge of rejection to review, so a borderline case becomes a human decision instead of a lost customer.

If you need the fraud checks stricter than the defaults, set the sensitivities you care about explicitly:

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "HighAssurance",
      "verificationContext": "Remote",
      "manualReviewStrategy": "RejectedOnly"
    },
    "settings": {
      "screenPresenceSensitivity": "Level8",
      "photocopySensitivity": "Level8",
      "portraitForgerySensitivity": "Level8",
      "generativeAiSensitivity": "Level8"
    }
  }
}

Very high-assurance remote KYC​

Constraints:

  • Deployed remotely in a regulated industry with mandatory KYC
  • High fraud risk: account takeover and multi-account abuse are active threats
  • High fraud cost per incident
  • Users are highly motivated to complete onboarding (financial or access incentive)
  • False rejections are low-cost because motivated users retry without support intervention
  • A support team is available to review borderline cases

Industries: crypto exchanges, regulated investment platforms, online gambling, neobanks

configuration.json
{
  "verification": {
    "useCase": {
      "verificationPolicy": "HighAssurance",
      "verificationContext": "Remote",
      "manualReviewStrategy": "AcceptedOnly"
    },
    "settings": {
      "screenPresenceSensitivity": "Level8",
      "photocopySensitivity": "Level8",
      "portraitForgerySensitivity": "Level8",
      "generativeAiSensitivity": "Level8",
      "imageQualityRetryPolicy": "RetryBadQualityAlways"
    }
  }
}

manualReviewStrategy: AcceptedOnly routes borderline accepted cases to manual review, catching fraud that Verify could not decisively reject. Those cases come back with a Review verdict. Users who were falsely rejected will typically retry on their own.

imageQualityRetryPolicy: RetryBadQualityAlways asks for a new image whenever quality issues are detected, rather than reaching a verdict on an image that might be hiding tampering. Highly motivated users tolerate the extra capture attempt, and it keeps ambiguous images out of the review queue.

See also​

Last updated on