Verdicts and thresholds — Veritus manual

What you do with each verdict is up to you. Here's what we recommend and what each verdict actually means in our engine.

The three verdicts

allow	Veritus believes this is a legitimate signup. Default action: accept it. Score is below your form's allow threshold.
review	Veritus is uncertain. Default action: create the account but flag it for human review before granting full access. Score is between thresholds.
block	Veritus believes this is fraud. Default action: refuse the signup. Score is above review threshold, OR a hard-block code (IP_TOR) fired, OR a block rule matched.

Recommended actions per verdict

On allow

Create the account normally
Optionally send a welcome email confirming the signup

On review

Two reasonable patterns:

Soft path: create the account but mark it unverified. Block paid features and contacts until a human approves.
Hard path: refuse the signup immediately and send the user to a manual verification flow (email-confirm + ID upload).

The widget supports both: pass onReview: () => false to stop submission and show a manual-review notice; pass onReview: () => true to submit anyway with the _veritus_review=1 hidden flag for your backend.

On block

Refuse the signup with a generic "we can't process this signup" message — don't reveal why (don't help fraudsters tune their attacks)
Offer a support contact for legitimate users who get blocked by mistake (false positives are real)
Log the request_id; if a user complains, they can reference it and you (or Veritus) can investigate

Tuning thresholds

Default thresholds (30 / 70) are tuned to be conservative for the v1 model. If you see too many false positives, raise the thresholds slightly. If you see fraud slipping through, lower them.

Per-form thresholds let you have stricter rules for high-value flows (paid trial signup) and lax ones for low-stakes ones (newsletter). Set them on the form detail page.

Overrides

If a user contacts you saying they were wrongly blocked, you can ask us to override the verdict on that specific check. Currently override is admin-only; we plan a self-service version where you can mark false positives directly from the check detail page. Until then: drop us the request_id and we'll handle it.