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

# IDV & Biometrics: OCR Comparison

> A deep dive into how FrankieOne compares OCR data with user-provided information to ensure data consistency and prevent fraud.

## What is OCR Comparison?

Optical Character Recognition (OCR) is the process of extracting text data from an image, such as a driver's license or passport. The **OCR Comparison** is a critical security step within the IDV workflow where FrankieOne verifies that the data extracted from the document matches the information provided by the user or already stored on their entity profile.

The primary objective is to ensure the details on the government-issued ID match the entity profile being submitted for verification, preventing "bait-and-switch" fraud scenarios.

## How OCR Comparison Works

The comparison logic is triggered in two primary scenarios:

1. **Manual Input First**: If a user manually enters their details (e.g., name, DOB) *before* the document scan, the OCR comparison is triggered immediately after the scan to check for discrepancies.
2. **Biometrics First / Post-Verification Updates**: If the IDV process happens first, an entity is created using the initial OCR data. If the user later updates key fields (name, DOB, ID number) on their profile, the system re-runs the OCR comparison logic to check if the changes invalidate the original verification.

### The `IDV_OCR_COMPARISON` Supplementary Data

The result of this check is found within a Process Result Object (PRO) where the `supplementaryData` object has a `type` of `IDV_OCR_COMPARISON`.

<Accordion title="Example: supplementaryData for IDV-OCR-Comparison">
  ```json theme={null}
  "supplementaryData": {
    "type": "IDV_OCR_COMPARISON",
    "outcomeRaw": "suspected",
    "resultMap": {
      "last_name_match": { "resultNormalized": "clear" },
      "date_of_birth_match": { "resultNormalized": "clear" }
    },
    "mismatchMap": {
      "first_name_match": {
        "originalData": "Jon",
        "reviewedData": "John",
        "resultNormalized": "suspected"
      }
    },
    "ocrResultId": "pro_01J...",
    "comparisonSource": "ENTITY"
  }
  ```
</Accordion>

**Key Fields:**

* `resultMap`: An object showing which fields **matched successfully**.
* `mismatchMap`: An object that highlights the specific fields that **did not match**. This is crucial for debugging `SUSPECTED` results, as it shows the discrepancy (e.g., original "Jon" vs. OCR "John").
* `comparisonSource`: Indicates what the OCR data was compared against. This will be `ENTITY` (for existing entity data) or `OCR_UPDATE` (for data updated post-scan). \[cite: 2975-2979]
* `ocrResultId`: The ID of the `IDV_OCR` Process Result Object that this comparison is based on.

***

## Matching Logic and Fuzziness

To account for minor OCR inaccuracies or common typos, the comparison does not always require an exact match. FrankieOne uses the **Levenshtein distance** algorithm to measure the difference between the user-provided string and the OCR-extracted string.

This "fuzziness" is configurable. The default configuration allows for small discrepancies before a field is flagged as `SUSPECTED`.

| Field              | Default Levenshtein Distance |
| :----------------- | :--------------------------- |
| First Name         | 2                            |
| Last Name          | 2                            |
| Date of Birth      | 1                            |
| Document ID Number | 2                            |

There is also a `compare_ocr_max_mismatch_levenshtein_distance` which, by default, allows for up to 2 characters to be mismatched across all fields before the overall result is marked as `SUSPECTED`.

***

## Result Invalidation

A key security feature of the OCR comparison is the re-check that occurs if a user updates their profile information *after* the initial IDV process. This is to protect against a scenario where a fraudster:

1. Uses their real ID and face to pass an IDV check.
2. Later, changes the name, DOB, or ID number on their profile to match the details of a stolen identity.
3. Attempts to use this fraudulent profile to pass other checks like KYC or AML.

If the system detects that a change to a key field exceeds the configured Levenshtein distance (e.g., `fuzzy_logic_idv_allowed_distance_family_name`), the original OCR and IDV results will be invalidated by having their `systemStatus` changed to `STALE` or `MARKED_INVALID`.

## Best Practices

* **Check the `mismatchMap`**: When you receive an OCR comparison result of `SUSPECTED`, always inspect the `mismatchMap` to understand exactly which field caused the issue.
* **Understand Configuration**: Be aware that the definition of a "mismatch" is configurable. A `SUSPECTED` result does not necessarily mean fraud; it could be a minor OCR error that falls within your organization's acceptable risk tolerance.
* **Secure Profile Updates**: Be mindful of the result invalidation logic. If you allow users to freely edit their profile details after a successful IDV check, it may trigger an invalidation, requiring them to re-verify.

## Additional Resources

* [Interpreting Workflow Results](/docs/interpreting-workflows-v2)
* [Understanding IDV & Biometrics Results](/docs/idv-biometrics-guide-results)
* [FrankieOne API Reference](/docs/reference/whats-new)