---
Source: https://docs.microblink.com/verify/example-configurations
Title: Configure based on scenarios
Description: Example BlinkID Verify configurations and relevant industries and their use cases
---

# 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

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

[`verificationContext: InPerson`](./configuration.md#verification-context) 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`](./configuration.md#verification-policy) 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

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

[`verificationContext: Remote`](./configuration.md#verification-context) keeps the liveness checks running.

[`photocopySensitivity: Disabled`](./configuration.md#sensitivities) 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

```json title="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`](./configuration.md#expiration) decides which happens.
Set it explicitly rather than relying on the default:

```json title="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

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

[`manualReviewStrategy: RejectedOnly`](./configuration.md#manual-review-strategy) 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:

```json title="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

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

[`manualReviewStrategy: AcceptedOnly`](./configuration.md#manual-review-strategy) routes borderline accepted cases to manual review, catching fraud that Verify could not decisively reject.
Those cases come back with a `Review` [verdict](./response.md#pass-or-fail-a-document).
Users who were falsely rejected will typically retry on their own.

[`imageQualityRetryPolicy: RetryBadQualityAlways`](./configuration.md#image-quality-retry-policy) 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

- [Configuration](./configuration.md): what each use case and setting does.
- API reference: [cloud](/verify/api/ref/v3-cloud) and [on-prem](/on-prem/api).


Last updated on Aug 6, 2026