Skip to main content
A verification resolves to SUSPECTED when the document and face checks themselves succeeded, but the system attached one or more fraudTags or mismatchTags to the result. SUSPECTED never appears without at least one of those tags present — it exists specifically to carry that signal to you.
For the full list of every tag value and its plain-English meaning, see Verification Statuses → Fraud Tags and → Mismatch Tags.

​
Worked Examples

The same shape repeats every time: autoDocument/autoFace (and manualDocument/manualFace, if reviewed) come back clean, but a tag is present. Only the tag differs.

​
A Data Mismatch

You created the session with firstName: "Jon". The document reads “John”.
The document and face are genuinely valid — the flag exists purely because the name you supplied doesn’t exactly match the document.

​
An Age Policy Flag

You configured ageLimit, and the document’s date of birth puts the client under it.
The document is real and the face matches — this tag exists only to enforce a policy you configured, not to flag a fake document.

​
An AML/Watchlist Hit

AML screening (checkAml) found the client on a PEPs or sanctions list.
Nothing about the document or selfie is in question — the flag is about who the person is, screened against an external list.

​
A Duplicate Signal

checkDuplicateFaces is enabled, and this selfie matches a face from a previous verification — possibly under a different clientId.
This can mean one person opening a second account — which is sometimes abuse, and sometimes a legitimate returning user or a shared household device. The tag can’t tell you which; only your context can.

​
iDenfy Does Not Evaluate SUSPECTED

For APPROVED and DENIED, iDenfy’s automated and manual review pipeline commits to a decision on your behalf. SUSPECTED is different by design: iDenfy detects and reports the signal — the specific tag — but does not judge whether that signal disqualifies the user. Whether a name mismatch, an age flag, an AML hit, or a duplicate face should block someone depends on your risk appetite, your jurisdiction, and your product. Those are business decisions only you can make, so iDenfy leaves the result open rather than guessing on your behalf.

​
Build Your Own Evaluation Procedure

Because iDenfy won’t resolve SUSPECTED for you, treat evaluating it as a required part of your integration, not an edge case you’ll handle manually the first time it comes up:
  1. Read every tag your configuration can produce — Fraud Tags and Mismatch Tags — and decide, per tag, whether it should auto-approve, auto-deny, or route to manual review.
  2. Write that decision down as an internal procedure that your team (support, compliance, risk) actually follows, rather than leaving it to ad hoc judgment calls each time a case comes up.
  3. Decide who is authorized to override a SUSPECTED result, and how — see Resolving a SUSPECTED or DENIED Result for the available mechanisms.
  4. Log the decision against the scanRef for audit purposes, especially whenever a fraud tag is overridden.
Treating every SUSPECTED result as an automatic denial rejects legitimate users over cosmetic or explainable mismatches. Treating every SUSPECTED result as an automatic approval defeats the purpose of the checks. Build the procedure — don’t skip it.

​
Next Steps

Status Handling

What to do with every overall status, not just SUSPECTED.

Verification Statuses

Full definitions of every tag value.

Resolving False Positives

Clear a tag from the dashboard.

Request Update

Reactivate the token — POA, Risk Assessment, or Questionnaire cases only.

Related topics

Status HandlingData RetrievalFAQIdentification expiredIdentification cancelled