When you compare barcode data to OCR data, you want to know if the results indicate a potentially fraudulent form of identification. That determination is your responsibility. Intellicheck returns results. We do not return a decision. Our results are there to help guide your decision-making process:

• Barcode results are returned in idcheck
• OCR results are returned in OCR

If you request OCR matching, we return an ocr_match object with the comparison results between OCR and idcheck. In ocr_match, you'll find comparison results for more than a dozen fields, such as:

• Issuer name
• Cardholder name
• Date of birth
• Address

👍

You decide which OCR match fields are relevant to you based on your use case and business requirements.

Follow the authentication trail

To get a better idea of what the results are telling you, imagine the authentication happening as a workflow from the barcode to the OCR extraction to the front-back matching. At each step along the flow, evaluate the results to understand the risks.

Was the barcode decoded?

Start with the barcode. The barcode is fundamental. If the idcheck object processResult property is anything other than DocumentProcessOK, then in your decisioning process, consider the ID highly suspicious. For example, if processResult is DocumentUnknown, you should suspect that the ID potentially fraudulent because the barcode is not recognized. At this point, there is no need to go further and investigate the OCR and ocr_match response objects.

Was OCR successful?

Next, check the OCR object. The OCR results tell you if the front of the ID was recognized and if the text was successfully converted to data based on the submitted image.

If successful, the documentRecognized property is 1 and all or some of the text is returned in the OCR object. Keep in mind that not all text is perfectly converted to data using OCR extraction every time. Some fields might be misrepresented or empty due to poor image quality. You can still get a documentRecognized of 1 with partial results.

If documentRecognized is 0, the front of the ID was not recognized. All the OCR properties are null. If documentRecognized is 0, suspect that the ID is potentially fraudulent. At this point, there is no need to go further and investigate the ocr_match response object.

How well did OCR match the barcode?

Finally, see what matches. Matching results give insight about document consistency. But they also present a challenge because matches or mismatches can be due to poor image quality. Glare, blurriness, and dim lighting can cause OCR mismatches on an otherwise authentic ID. But mismatches can also point to discrepancies that hint at potential fraud.

As mentioned above, the ocr_match object returns more than a dozen match fields with the properties you might consider most relevant to your decision-making process, such as issuer name (isIssuerNameMatch), cardholder name (isNameMatch), and date of birth (isDobMatch).

📘

See OCR Match Details for more information about the match fields, similarity scores, and thresholds.

Conceptual flow diagram

The following diagram illustrates the authentication flow described above.

🚧

The diagram represents a theoretical business-decision process. Intellicheck provides results only, not a decision regarding authenticity.

1. Notice how the flow starts with barcode results. We assume the barcode is okay. If not, you would consider the ID invalid.
2. Next, evaluate the OCR response. Did it pass? If not, then you have a case where the barcode passed but the OCR did not, and you have no OCR data with which to compare. This could be suspicious. You should be cautious about the ID validity.
3. Finally, look at the OCR match details. You already have a good barcode and a successful OCR response. Keep that in mind when you consider the matching results:

• All matched. If all fields matched, you can be confident. In this scenario, you decide that the likelihood of an invalid ID is very low.
• Some matched. If some of the relevant fields matched but others did not, you should be cautious about the ID validity. Remember that we return OCR match results for more than a dozen fields. You decide which ones are most relevant for your use case and business requirements. For example, you might prioritize issuer, date of birth, and expiration date. Then these fields would weigh heavily in your decision. Partial matches can be caused by poor image quality. Partial matches can also hint at fraud. Review OCR Match Details for information about matching thresholds and scores for individual fields.
• All mismatched. If all of the fields mismatched, you should be suspicious about the ID validity. In this scenario, it appears that you have a driver's license with a good barcode and a recognizable front image. But all data is mismatched.

Using success to understand overall match results

We provide a sucess property at the top level of ocr_match. For all response objects that are returned by the /get-results endpoint, the success value is true if the API call was successful; false otherwise. Thus, in most cases,success is fundamentally a diagnostic property that simply reports on the status of the API request. It is not typically interpretive with respect to response values. But for ocr_match, the success property can be more than diagnostic. This section explains when you should or should not use success in your decisioning process.

👍

For most response objects returned by /get-results, the top-level success property is simply diagnostic in terms of the overall API functionality. It does not explain the response object, its properties, or their values.

How to misinterpret success for ocr_match

Before we consider how to use success for ocr_match, it's important to understand what not to do. It is possible to receive a success of true when the ocr_match object contains all null values. Why is this the case? Again, success is fundamentally diagnostic. In the case of all null values, the success of true means that we successfully routed OCR matching logic on the backend, and nothing more. It does not explain the match results.

Looking a little deeper, in the case of a success of true for all null values in ocr_match, you would expect to find that the documentRecognized property of OCR is 0, meaning that the document was not recognized. You might also notice that the OCR message property is Document unrecognized. And finally, the entire OCR response would contain null values.

Look again at step two of the conceptual flow diagram above. On the right side is a red box titled OCR Failed with a note to be suspicious about ID validity. The scenario described above illustrates what can happen if you erroneously consider only the ocr_match success property without first evaluating the OCR response. It is important to not exclusively rely on the success property of ocr_match without first considering the OCR response. Doing so could lead you down a path of authenticating a potentially inauthentic ID.

The following table summarizes this combination of processResult, documentRecognized, and success values for each of the respective response objects.

How to correctly interpret success for ocr_match

The success property acts in a special way for ocr_match. In addition to being a diagnostic response, success for ocr_match can be interpreted as an overall match result. This overall result depends on a specific set of comparison fields and default thresholds. Just keep in mind that Intellicheck established these comparison fields and thresholds, which may or may not align with your requirements.

When success is true

Assuming the idcheck processResult value is DocumentProcessOK, and the OCR documentRecognized value is 1, then the success property can be interpreted in terms of a true value. If true, then OCR match passed with the similarity_score values being greater than the similarity_threshold values for the comparison fields we selected.

📘

You can use our success result if you want to accept our thresholds and comparison fields.

Here are the comparison fields we consider along with the thresholds for each to arrive at a success value of true.

If these comparison fields are available and pass OCR match with a similarityScore greater than the similarityThreshold, then success is true.

But understand that success being true does not mean every single ocr_match field passed. It only applies to the comparison fields. For example, if all of the comparison fields matched, yet eye color did not match, success is still true because eye color is not one of the comparison fields that we use to determine a success value.

When success is false

Again, assuming the idcheck processResult value is DocumentProcessOK, and the OCR documentRecognized value is 1, then the success property for ocr_match can also be interpreted in terms of a false value. If false, then OCR match failed with the similarity_score values being less than the similarity_threshold values for the comparison fields we selected.

• success can also be false if OCR match was not attempted due to an API error. This is a diagnostic result.
• success can be false if the issuer name did not match with one-hundred-percent certainty. In this case, isIssuerNameMatch will be false.
• success can be false if any one of the comparison fields returned a mismatch, meaning the similarityScore was less than the similarityThreshold:
  • Cardholder name (isNameMatch will be false)
  • Address (isAddressMatch will be false)
  • Date of birth (isDobMatch will be false)
  • Expiration date (isExpirationDateMatch will be false)
  • Issue date (isIssueDateMatch will be false)

Summary

You can use the success property of ocr_match for a quick way to determine the overall match result, but only if certain preconditions are met:

• The idcheck processResult value is DocumentProcessOK, meaning the barcode was recognized and decoded.
• The OCR documentRecognized value is 1, meaning the front of the ID was recognized and returned OCR data (not null values).

If these two preconditions are met, then you can look at the success value of ocr_match for an overall match result based on Intellicheck comparison fields and thresholds. These fields and thresholds are provided for your convenience but may not align with your business requirements. So just keep that in mind.

• A threshold of 100 for issuer name, meaning no mismatch is allowed, even due to poor image quality. Anything less than a perfect match results in success being false.
• A threshold of 70, which provides flexibility due to poor image quality, for the following fields:
  • Cardholder name
  • Address
  • Date of birth
  • Expiration date
  • Issue date
    If any one of these fields returns a similarityScore less than 70, then success is false.

With the preconditions met, and if these fields and thresholds are acceptable for your business requirements, the ocr_match success property can be interpreted for an overall match result. If it is true, that means all six comparison fields matched at their established thresholds. If it is false, that means at least one of the comparison fields did not match at the established thresholds. All other fields outside of these six do not affect the success value, regardless of whether the comparison resulted in a match or a mismatch.