GovDataMatch Technical Details

GovDataMatch is Incode's data verification service through AAMVA or through validation of Verifiable Credentials. During verification, the supported document data fields are validated against the data on the record held by the issuing state's DMV.

GovDataMatch is part of the overall US GovMatch offering.

GovDataMatch now runs on AAMVA's DLDV 3.0 service. This update improves the quality of the match and the detail in the response. The endpoint, the request body, the scoring model, and the provider value are unchanged.

Decisioning

The document number is the anchor for the whole check. When the issuing agency confirms the document number, the remaining submitted fields are evaluated individually and returned in ocrValidation. When it does not, no field-level results are returned and the module resolves to one of the statuses in the error table below.

Each field is returned with its own result in ocrValidation:

Not every jurisdiction supports every field. Talk to your account team to confirm coverage for the jurisdictions relevant to you.

Elements the agency cannot answer

An element resolves three ways:

• It matches the agency record
• It does not match the agency record
• The issuing agency holds no record for it

Only the first two are scored. Where the agency holds no record for an element or cannot answer it, that element is omitted from ocrValidation rather than returned as a failure, and it applies no score deduction. This behavior leads to fewer deductions overall and a shorter ocrValidation array on sessions where the agency holds a partial record.

Decisioning should be based on the status value in the overall object. The status value can be:

• OK: Data Match is successful

• FAIL: Data Match is unsuccessful

How data fields are matched

Name and address fields aren't compared character by character. The issuing agency runs several comparisons on each field and reports each one separately. Incode returns the field as a match if any comparison matched.

Comparisons include the exact value, phonetic variants, values within a small edit distance, and any alternative or former name the agency holds on record. This covers common spelling variants (STEPHEN and STEVEN match; JONHSON and JOHNSON match) as well as the many valid ways to write the same address (APT 4B, #4B, and UNIT 4B are treated as the same value; ST and STREET match).

This doesn't lower the standard. Genuinely different values still return FAIL. What it prevents is a mismatch caused only by spelling, punctuation, or formatting. Matching behavior isn't configurable.

Two things to know:

• Nicknames only match when the agency has them on record. ROBERT doesn't automatically match BOB, since the two are neither phonetically similar nor within a small edit distance.
• First and last name are stricter than other fields. Anything short of a match returns FAIL rather than being treated as unevaluated. That said, two failed name fields alone still leave the module above the pass threshold.

Standalone API

POST /omni/process/government-validation?countryCode=USA

Request Body

{
    "idNumber": "D12345678",
    "firstName": "JOHNTEST",
    "paternalLastName": "DOETEST",
    "birthDate": "03-16-1990",
    "issueDate": "01-15-2020",
    "expirationDate": "01-15-2028",
    "issuerState": "TX"
}

Response Body

{
    "valid": true,
    "statusCode": 0,
    "governmentValidation": {
        "validationStatus": {
            "value": "0",
            "status": "OK",
            "key": "ok"
        },
        "ocrValidation": [
            {
                "value": "true",
                "status": "OK",
                "key": "documentNumber"
            },
            {
                "value": "true",
                "status": "OK",
                "key": "firstName"
            },
            {
                "value": "true",
                "status": "OK",
                "key": "paternalLastName"
            },
            {
                "value": "true",
                "status": "OK",
                "key": "birthDate"
            },
            {
                "value": "true",
                "status": "OK",
                "key": "issueDate"
            },
            {
                "value": "true",
                "status": "OK",
                "key": "expirationDate"
            }
        ],
        "credentialStatus": [
            {
                "status": "OK",
                "key": "nonCommercialDriverLicenseStatus"
            },
            {
                "status": "OK",
                "key": "indefiniteExpiration"
            }
        ],
        "ocrValidationOverall": {
            "value": "100.0",
            "status": "OK"
        },
        "overall": {
            "value": "100.0",
            "status": "OK"
        },
        "provider": "GOVDATAMATCH"
    }
}

Response Details

The response for GovDataMatch is contained within the governmentValidation object.

This object contains the following fields:

StatusValue key/value pairs

This object contains the following fields:

Credential status

The issuing agency reports verdicts on certain credential attributes. There is a credentialStatus array on the governmentValidation object if the session collected one of the attributes:

• nonCommercialDriverLicenseStatus. Whether the holder has a current, valid base driving privilege for standard passenger vehicles such as cars, vans, pickups, and SUVs. This attribute says nothing about commercial driver licenses; no CDL information is carried at any point, and a holder may also hold a CDL. Not every jurisdiction participates; where one doesn't, the status is UNKNOWN, not FAIL. Participation is expanding over time.

• indefiniteExpiration. Whether the credential is one of those issued with no expiration date. A small number of jurisdictions do this, in some cases only above a given age. When a credential is submitted as indefinite, the agency confirms that against its record and the verdict is returned both here and as the expirationDate row in ocrValidation. An expiration date and an indefinite indicator are mutually exclusive, so a credential carries one or the other, never both.

Each entry has a key and a status of OK, FAIL, or UNKNOWN. Verdicts are reported separately from ocrValidation because they describe the credential rather than verify a submitted value, so they don't affect ocrValidationOverall or overall.

Error Codes

If these errors appear for a legitimate user, or if the errors persist, submit a support ticket through http://support.incode.com/ for further investigation.