> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.idenfy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Suspected Status

> Why a verification resolves to SUSPECTED, worked examples of which tags cause it, and why iDenfy does not decide how to resolve it for you.

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.

<Tip>
  For the full list of every tag value and its plain-English meaning, see [Verification Statuses → Fraud Tags](/guides/dashboard/kyc/verification-statuses#fraud-tags) and [→ Mismatch Tags](/guides/dashboard/kyc/verification-statuses#mismatch-tags).
</Tip>

## 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".

```json theme={"system"}
{
  "status": {
    "overall": "SUSPECTED",
    "mismatchTags": ["NAME"],
    "fraudTags": [],
    "autoDocument": "DOC_VALIDATED",
    "autoFace": "FACE_MATCH"
  },
  "scanRef": "d2714c8a-...",
  "clientId": "user-123"
}
```

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.

```json theme={"system"}
{
  "status": {
    "overall": "SUSPECTED",
    "mismatchTags": ["UNDER_AGE"],
    "fraudTags": [],
    "autoDocument": "DOC_VALIDATED",
    "autoFace": "FACE_MATCH"
  }
}
```

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.

```json theme={"system"}
{
  "status": {
    "overall": "SUSPECTED",
    "fraudTags": ["AML_SUSPECTION"],
    "mismatchTags": [],
    "autoDocument": "DOC_VALIDATED",
    "autoFace": "FACE_MATCH"
  }
}
```

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`.

```json theme={"system"}
{
  "status": {
    "overall": "SUSPECTED",
    "fraudTags": ["DUPLICATE_FACE"],
    "mismatchTags": [],
    "autoDocument": "DOC_VALIDATED",
    "autoFace": "FACE_MATCH"
  }
}
```

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](/guides/dashboard/kyc/verification-statuses#fraud-tags) and [Mismatch Tags](/guides/dashboard/kyc/verification-statuses#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](/kyc/status-handling#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.

<Warning>
  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.
</Warning>

## Next Steps

<CardGroup cols={2}>
  <Card title="Status Handling" icon="route" href="/kyc/status-handling">
    What to do with every overall status, not just SUSPECTED.
  </Card>

  <Card title="Verification Statuses" icon="circle-dot" href="/guides/dashboard/kyc/verification-statuses">
    Full definitions of every tag value.
  </Card>

  <Card title="Resolving False Positives" icon="tag" href="/guides/dashboard/kyc/resolving-false-positives-removing-mismatch-tags">
    Clear a tag from the dashboard.
  </Card>

  <Card title="Request Update" icon="pen" href="/kyc/request-update">
    Reactivate the token — POA, Risk Assessment, or Questionnaire cases only.
  </Card>
</CardGroup>


## Related topics

- [Status Handling](/kyc/status-handling.md)
- [Data Retrieval](/kyc/data-retrieval.md)
- [FAQ](/resources/faq.md)
- [Identification expired](/api-reference/webhooks/identification-expired.md)
- [Identification cancelled](/api-reference/webhooks/identification-cancelled.md)