Handling verdicts in your app

Veritus returns a verdict; your application decides what to do with it. This page covers the recommended UX for each verdict, sample copy you can use, an appeal flow for false positives, and a few patterns to avoid.

The three verdicts

Verdict	What it means	Recommended action
`allow`	Score below allow threshold (default ≤ 30). Looks like a real person.	Create the account, send your normal welcome email. No friction.
`review`	Score in the middle band (default 31–70). Suspicious but not damning.	Create the account but flag for manual review; OR require an additional verification step (SMS code, photo ID, ask-a-human).
`block`	Score above block threshold (default ≥ 71). Multiple strong fraud signals.	Don't create the account. Show a generic, non-revealing error.

Handling `allow`

Nothing special. Proceed with your normal signup flow. The user shouldn't know Veritus exists.

Handling `review`

Two common patterns:

Pattern A: soft-allow with extra friction

Create the account, but require one of: email-link verification, SMS code, ID document upload, or a delay before features unlock. Genuine users pass through; fraudsters usually drop off rather than complete the extra step.

Pattern B: hold for human review

Create the account in a pending state. Show the user a polite message: “Thanks — we'll have your account ready within a few hours”. Your team reviews and approves or rejects. Works well for low-volume, high-value products where a few hours of delay is acceptable.

Either way, fire a webhook on check.review so your team gets a notification — see Webhooks.

Handling `block`

Show a generic error

Never reveal that fraud detection rejected them. Never quote the score or reasons. Doing either of those things teaches attackers how to bypass your defences — they'll iterate (different IP, different email, different country) until they pass.

Recommended message:

We couldn't complete your signup at this time.
If you believe this is a mistake, please contact
support@yourcompany.com so we can take a closer look.

Don't auto-retry the same data

If a user retries the form with the exact same data, return the same error. If they retry with substantially different data within a short window (different email, different country, etc), treat that as suspicious itself — it's a strong signal of someone iterating to bypass.

Log enough to investigate

Store the check UUID we returned in response.id alongside any partial signup data you captured. When a user emails support claiming false positive, you (or your team) can open the check in Live scores and see exactly which signals triggered.

The appeal flow

Even with paid vendors fully enabled, false positives happen. Legitimate users on VPNs, business travellers, people on shared corporate IPs, and users with unfortunate email/IP combinations all get blocked sometimes. A clear appeal path keeps your conversion rate healthy.

For the user

They see "couldn't complete signup, contact support@..." and email you
Your support team replies asking them to verify identity via reply (a short selfie + ID, or just a clear explanation of who they are and why they're signing up)
If they respond — that's already a strong signal they're genuine
If their answer makes sense, you approve the account manually

For you (the admin)

Find the check in Live scores using the UUID the user provides, OR by searching their email
Open the check detail to see all reasons and vendor calls
If the block was wrong, click Override verdict → set to allow
This is logged in audit and fires a verdict.overridden webhook so your application can proceed with their signup

Sample blocked-signup message page

Drop-in HTML for the page you redirect to on a block. Looks like the rest of your site but tells users nothing about why:

<!DOCTYPE html>
<html><head><title>Signup error</title></head>
<body>
  <main style="max-width:520px;margin:80px auto;font-family:sans-serif">
    <h1>We couldn't complete your signup</h1>
    <p>Something went wrong while creating your account.</p>
    <p>If you believe this is in error, please email
       <a href="mailto:support@yourcompany.com">support@yourcompany.com</a>
       and we'll take a closer look.</p>
    <p style="color:#888;font-size:13px">
       Reference: <code>{{ check_id }}</code>
    </p>
  </main>
</body></html>

Including the check UUID gives your support team something to look up. They paste it in Live scores and have full context immediately.

Sample support email template

Reply to a blocked user requesting verification:

Hi [name],

Thanks for getting in touch. To get your account set up,
we'd like to verify a couple of details quickly.

Could you reply with:

  1. A brief description of your business and how you'll
     be using our product
  2. Confirmation of the country you're signing up from
  3. (Optional but speeds things up) A photo of yourself
     holding a piece of paper with today's date

This helps us protect our service from automated abuse.
We'll get your account active within one working day of
your reply.

Best,
[Your name]
[Company] Support

Things not to do

Don't tell users why they were blocked

“We blocked you because your IP looks like a VPN” — you've just taught the attacker (and shamed the legit user) which signal failed. They'll switch IP and retry, OR feel personally accused. Stick to “couldn't complete signup”.

Don't report users to authorities

Veritus produces a probabilistic score, not legal evidence. False positive rates are typically 1–5% even with all paid vendors enabled, which means out of 1,000 blocks, 10–50 are innocent people.

Reporting suspected fraud to local police or fraud authorities based on a Veritus verdict alone exposes you to:

Defamation — if the user turns out to be innocent
GDPR Article 22 violations — automated decisions with legal effects require human review and the right to contest. Reporting to authorities is a legal effect.
GDPR Article 6 violations — you need a lawful basis for sharing personal data with third parties. “An AI said so” isn't one.
Malicious communications offences (UK Communications Act 2003 s127) if any reports turn out to be false and a reasonable person would have known

Action Fraud (UK) and similar bodies explicitly require victim reports of completed crimes, not predictive accusations from a third-party SaaS. They won't accept AI-generated reports — and would block your reports if you tried to file them programmatically.

The right action if you genuinely believe someone is trying to defraud you is the same as for any other suspicious signup: silently block them, log the data, and let your fraud team handle individual cases via your own legal/compliance process.

Don't share verdicts laterally

If a user is blocked on signup, don't share that fact with other systems (CRM, marketing, support tickets) in a way that would prejudice future interactions with them. They might appeal successfully or come back later with legitimate intent. Keep the block contained to the signup decision.

Tuning to reduce false positives

If your support inbox is full of “why am I blocked?” emails:

Raise your block threshold from 70 to 80 — fewer borderline cases get blocked, more land in review
Look at Stats → Top reasons to identify which signal is over-firing
Create a rule to allowlist a known-good country or email domain that's getting caught
If a specific paid vendor is producing low-quality signal, toggle it off at vendor keys for a week and compare false positive rates