UseCase
A UseCase is a very high-level setting designed to give you powerful control through the simplest possible API. It allows you to specify things like where the documents are scanned (remotely or in-person), whether you have a preference for reducing false rejections or false acceptances, and more. Every verification has a default UseCase, which is what determines the basic default behavior of Verify.
The idea behind this feature is to answer high level "questions" about your use case, and let us tailor the verification process to that. UseCase parameters can set behaviors that aren't otherwise controlled by other options (e.g. ManualReviewFrequency). However, what they primarily do is set other options, and these can be overriden by using the Options object.
| Check | Match Level |
|---|---|
| Photocopy Detection | Level5 |
| Screen Detection | Level5 |
| Photo Forgery Detection | Level4 |
The interactive demo above shows how two key UseCase parameters affect match levels:
- Verification Context: Determines which checks are relevant (e.g., no need for photocopy detection in-person)
- Document Verification Policy: Adjusts the overall strictness by modifying match levels
UseCase parameters
The current domain of a UseCase relates to the following things:
- Verification policies - whether you prioritize conversions or fraud prevention
- Manual review - whether you're able and want to perform manual review on edges cases, and when
- Capture conditions - how much control you have over the end users' capture process, and what kind of client side SDK you use
- Where the process happens - whether it's in-person or remotely
From that, we derive the following UseCase parameters:
VerificationPolicyManualReviewStrategyManualReviewSensitivityCaptureConditionsVerificationContext
For possible values, and more API details, see the use case reference.
Processing cropped images
By default, Verify will completely stop processing when it encounters a cropped image. This is because the extraction pipeline, and some of our fraud checks rely on having context around the document. Sending a cropped document will result in the RecommendedOutcome being Retry.
If your use case requires you to process cropped images, you can set the CaptureConditions to NoControl, implying you don't control the end users' capture process. This will allow us to tweak the pipeline (it will come with a slight latency hit), and we'll be able to process cropped images to completion.
However, a cropped image will never result in an Accept RecommendedOutcome, because it's tampered with by definition.